Stage by stage
What each round is actually scoring
A loop looks like a series of tests. It is closer to a series of witnesses, each asked to write down evidence for a small number of claims about you.
The single most useful thing I learned from interviewing others is what the interviewer is doing during the hour. They are not deciding whether to hire you. They are writing a document for people who will never meet you, and that document has a shape: a recommendation, and then evidence organised under three or four headings fixed by the company rather than by them.
This changes what good performance looks like. Anything you demonstrate that does not fit under one of those headings is, for practical purposes, invisible. Anything the interviewer cannot quote back is hard for them to defend. The candidates who do best are not the cleverest in the room; they are the ones who make the write-up easy.
The stages
A calibration call, twenty to thirty minutes. It is checking that your experience roughly matches the level being hired for, that your timeline and location work, and that you are actually interested. It is rarely a filter for engineering ability.
The one thing worth preparing: a forty-second summary of what you do now. Recruiters route candidates based on that summary, and being routed to the wrong level is a much more common failure than being rejected.
One or two coding problems in forty-five minutes, in a shared editor with no execution. The bar is lower than the onsite but the format is harsher: no whiteboard to gesture at, no room to recover from a slow start, and an interviewer who is often doing this between two meetings.
Screens are tuned for false negatives. This is not fair and it is not going to change; it means a rejection here carries much less information about you than it feels like it does.
The core of the onsite. Two rounds, each one or two problems, usually with the interviewer probing beyond the first working solution — complexity, an altered constraint, a follow-up that breaks your approach.
Scored on far more than correctness: whether you clarified the problem, whether your reasoning was audible, whether you tested your own code before being asked to, and how you behaved when something went wrong. See the coding notes.
Typically only for mid-level and above, and often the round that sets your level rather than deciding hire or no-hire. An open-ended prompt, forty-five minutes, no correct answer.
What is being scored is whether you can take an under-specified problem, make its constraints explicit, choose a structure, and be honest about what the structure costs. See the design notes.
Sometimes called behavioural, which undersells it. At senior levels this round carries real weight, and it is frequently run by the hiring manager.
It is scored on scope and ownership: how large the problems you take on are, how much of the outcome was actually yours, and whether you can describe a disagreement without making the other person a villain. See the experience notes.
At larger companies a group that never met you reads the written packet and makes the call. They are looking for consistency across rounds and for specific evidence, and they discount anything that reads as a general impression.
This is why a strong interviewer who liked you cannot always save a thin write-up, and why one clearly documented weak round can outweigh three vague good ones.
Where the decision is actually made
Not in the room. The decision is made when the packet is read, which means the useful question during any round is not am I impressing this person but what will this person be able to write down.
Concretely, that pushes you toward a few habits. State your assumptions out loud so they can be quoted. Name the complexity of what you wrote without waiting to be asked. When you change approach, say why you are changing it — an interviewer who watched you flail cannot distinguish it from an interviewer who watched you evaluate and discard an option, unless you told them which it was.
A pattern I saw repeatedly while interviewing: two candidates produce almost identical code, and one write-up says solved it while the other says recognised it as an interval problem, proposed sorting by end time, justified the greedy choice, coded it cleanly, found an off-by-one himself while tracing an example. The second one is not a better engineer. He is a better witness for himself.
Typical shape and time budget
| Stage | Length | Primary signal | Prep leverage |
|---|---|---|---|
| Recruiter | 20–30 min | Level and fit routing | Low — but cheap |
| Phone screen | 45 min | Baseline coding | High |
| Coding ×2 | 45–60 min | Problem solving, communication | High |
| System design | 45–60 min | Scope, trade-offs, level | High at senior |
| Experience | 45 min | Ownership, collaboration | Underrated |
| Committee | — | Consistency of evidence | Indirect |
How long to prepare
The honest answer is that it depends far more on how long you have been away from this format than on how good an engineer you are. Someone who interviewed two years ago needs a few weeks. Someone who has been at one company for eight years needs longer, not because they know less but because the format is genuinely unlike the job.
What I would not do again is prepare in a single block. Six weeks of an hour a day beats two weeks of three hours a day by a wide margin, for the same reason distributed practice beats cramming everywhere else it has been measured. The constraint is the calendar, so start the calendar early even if you cannot start the effort.