What does it mean when a candidate asks how often you deploy?

What does it mean when a candidate asks how often you deploy?

When a candidate asks how often a team deploys, they are running a health check on the pipeline they would live inside. The question sounds like technical curiosity. It is a quality-of-life question wearing technical clothes.

Deploying is the last step of the pipeline covered in what happens between writing code and shipping a feature: copying finished code onto the machines that serve customers. How often a team takes that step compresses a lot of information about how the team works. A candidate who has been through a few jobs has learned to read it, the same way an experienced renter learns to check the water pressure before signing a lease.

The same goes for the other questions strong candidates raise near the end of a call: code review, on-call, testing, and the vague-sounding phrase engineering culture. Each one is a probe into a specific part of daily working life. This lesson decodes each probe, and covers what happens when the client's honest answer is a bad one.

Why is deploy frequency a health metric?

Deploy frequency is a health metric because a team can only deploy often if several other things are already true. Frequent deploys are an effect, and the causes are what the candidate actually cares about.

To deploy many times a day, a team needs automated testing it trusts, because no human can manually re-check the whole product several times a day. It needs CI/CD automation doing the repetitive work. It needs small changes, because a small change is easy to review and easy to roll back if it breaks. Each deploy carries little risk, so nobody dreads it.

A team that deploys quarterly usually has the mirror image. Months of work pile up into one large release. Large releases break in complicated ways, so releases become tense events with late nights attached. Fear of the release slows everything else down, because every change waits in the queue for the next big push.

Neither number is a verdict on its own. A bank or a medical-device company can have real reasons for slower, heavily checked releases, and a candidate from that world knows it. What the candidate is listening for is whether the pace matches the company's story. A startup claiming to move fast while shipping twice a year has a gap between its pitch and its pipeline, and the candidate found it with one question.

What is a question about code review checking?

A question about code review is checking the quality bar and the way colleagues treat each other. Review is the step where a teammate reads a proposed change before it joins the shared code, so it is where a team's standards stop being a poster on the wall and become a daily practice.

The candidate has usually seen at least one of two failure modes. In the first, review exists on paper and approvals get rubber-stamped in seconds, which tells them quality is nobody's job. In the second, review is real but hostile: nitpicking, point-scoring, changes held hostage for weeks. Both failure modes make daily work miserable in different ways, and both are invisible from a job posting.

A healthy answer describes review as teaching. Senior people leave comments that explain, review turnaround is hours rather than weeks, and junior engineers say review is how they got better. A candidate who has had that wants it again, and a candidate who has had the opposite is checking whether history is about to repeat.

What is a question about on-call checking?

A question about on-call is checking two things: what happens to their nights and weekends, and whether the company fixes problems or only silences them.

On-call means carrying the pager for the live product. When monitoring raises an alert at 2am, the on-call engineer gets woken up to handle the incident. The roles that build and run this machinery are covered in what is DevOps, and what is an SRE, but on many teams every engineer takes a turn in the rotation, which is why the question comes up on screens for ordinary product roles.

The surface question is frequency: how often am I on the hook, and how often does the pager actually go off. The deeper question is about follow-through. Every alert has a cause. A healthy team spends engineering time fixing the causes, so the pager gets quieter over time. An unhealthy team is too busy shipping features to fix anything, so the same alerts fire every week and on-call becomes a recurring tax on sleep. Heavy on-call with no budget to fix the causes is one of the most reliable reasons strong engineers start looking, so a candidate probing it is often describing exactly why they are on the phone with a recruiter.

What does "engineering culture" mean when a candidate says it?

When a candidate says "engineering culture," they usually mean three specific things: autonomy, the quality bar, and how failure gets treated.

Autonomy is how much say engineers have in what gets built and how. At one end, engineers help shape the product and choose their own technical approach. At the other, work arrives as fixed orders with fixed deadlines and the engineer types what they are told. Most companies sit between the two, and the candidate wants to know where.

The quality bar is whether the team is allowed to do good work. Testing, review, and time to fix known problems all cost short-term speed, and companies differ in whether they pay that cost. An engineer who cares about craft burns out in a place that always chooses the shortcut.

Failure treatment is the sharpest of the three. In healthy engineering organizations, when production breaks, the question is what allowed the mistake through, and the fix is a better system: a missing test, a better alert, a safer deploy process. In unhealthy ones, the question is whose fault it was. Engineers who have lived through the blame version carry it with them, and a question about how the last outage was handled is them checking for scar tissue that matches their own.

What happens when the honest answers are bad?

When the honest answers are bad, the candidate will find out. The only choice is whether that happens during the process or after the start date. Deploy pain, hostile review, and a loud pager are all visible within an engineer's first month, and an engineer who feels misled about them becomes a short-tenure departure and a warm reference for nobody.

Bad answers gathered early are useful in two ways. First, they sharpen the search. A quarterly release cycle repels an engineer who loves shipping daily, and the same cycle is unremarkable to an engineer from banking or aerospace. On-call pain matters less to a candidate whose last rotation was worse. Knowing the real answers means the pipeline fills with people for whom the true version of the job is acceptable, which is the version they will actually be doing.

Second, they are a signal about the client, in exactly the way this module's guide treats candidate claims as signals. A client who knows their deploy cadence, names their on-call load honestly, and can say what they are fixing about both is a healthy account. A client who cannot answer, or answers differently every time, is telling you something about how the engineering organization runs, and about how the next three months of this search are going to feel.

A candidate asking these questions is usually a good sign in itself. It takes a few years of experience to know which answers predict a miserable job, and it takes real interest in the role to spend call time checking. The questions come from somewhere. Most often they come from the job the candidate is trying to leave.