Notes on preparing for the loop

What software interviews actually measure, what preparation is worth the hours, and the parts almost everyone over-invests in.

I spent a stretch of last year on both sides of the table — preparing for a job search, and then interviewing candidates once it was over. The two experiences disagreed with each other more than I expected. Most of what I had drilled turned out not to be what I was later asked to score people on, and several things I had treated as soft filler turned out to decide outcomes.

These pages are the notes I wrote to reconcile that. They are not a curriculum and they are not a promise. They are an attempt to describe the process honestly, including the parts that are arbitrary, so that the preparation you do is aimed at the thing being measured rather than at the thing that is easiest to practise.

Five things I would tell myself at the start

• The rubric is narrower than the syllabus. Interviewers score a short list of signals. Almost nothing else you demonstrate is recorded, however impressive it was.
• Volume is the wrong axis. Two hundred problems solved once is worse preparation than sixty problems solved, abandoned for three weeks, and solved again.
• Silence is scored as confusion. The interviewer cannot see your reasoning. An unspoken correct approach and an absent one look identical on the form.
• System design is a conversation, not an answer. The candidates who do badly are usually the ones who start drawing before they know what they are building.
• Your own projects need rehearsing too. People who can explain a distributed queue routinely fumble the question of what they personally did last quarter.

None of this is a secret and none of it is clever. It is mostly a matter of pointing effort at the right target, which is harder than it sounds when the internet is full of advice written by people optimising for a different company, a different level, and a different decade.