Interviews & hiring

Most coding interviews fail because the two people in the room have different mental models of what is being evaluated. The candidate thinks the test is whether they can implement the data structure correctly. The interviewer thinks the test is whether the candidate can think out loud, recognise edge cases, and recover from a wrong first attempt. Both are partially right. Both are partially wrong.

The truth is closer to this. The data structure is the surface; the engineering judgment is the substance. An interviewer who has run dozens of these can tell within ten minutes whether the candidate would be useful on a real codebase, regardless of whether the final solution compiles. A candidate who understands this can stop optimising for a finished solution and start optimising for the signals the interviewer is reading.

Both posts in this topic build on that gap. The candidate-side post walks through five problem levels not because the syntax of an LRU Cache matters in the abstract, but because the problems are calibrated to expose engineering judgment under pressure. The interviewer-side post explains the rubric — what an interviewer who knows what they are doing is actually watching for, and what they are willing to overlook in service of seeing it.

The two highest-leverage moves a candidate can make before a coding interview have nothing to do with practising more problems. The first is learning to think out loud at a rate that is slower than your internal monologue. Most candidates think faster than they can speak coherently; closing that gap is the difference between an interviewer who hears reasoning and an interviewer who hears silence. Practice it on warm-up problems before you spend hours grinding new ones.

The second is rehearsing the recovery move. Every interview problem you do not solve cleanly on the first attempt will end somewhere unpleasant — a wrong assumption, a bug you cannot find, an edge case you missed. The interviewer is watching what you do at that moment. Candidates who treat the stuck moment as a failure tend to fail it. Candidates who treat it as a chance to demonstrate how they recover — restate the problem, isolate the broken assumption, propose a fallback — tend to pass even when the final code is not perfect.

Practice problems still help, but only as a vehicle for those two skills. The five-level prep post in this topic is built that way: every level adds a layer of complexity, but the deeper purpose is to give you a place to rehearse out-loud reasoning and recovery without the pressure of a real interview. Read it as a structured rehearsal plan rather than a checklist.

The first job of the interviewer is to make the test legitimate. A bad coding interview is one where the candidate can pass by luck and a strong candidate can fail by accident. Most companies have at least one of those in their pipeline. The biggest gains in interview quality come not from harder problems but from problems that produce the same signal across different candidates regardless of which interviewer is in the room.

That stability comes from three things. A well-designed problem that has multiple acceptable solutions and a clear ladder from "working" to "good" to "excellent." A rubric that names the specific behaviours each level demonstrates, so two interviewers grade the same answer the same way. And a calibration habit — the panel meets monthly to talk about specific candidates and the scores they got, surfacing the cases where one interviewer would have rated up and another rated down. None of those are dramatic. All three compound.

The interviewer-side post in this topic walks through the design choices that hold up under that scrutiny: how to pick a problem that does not collapse into a syntax test, how to write a rubric that resists the urge to score on likability, and how to structure a 60-minute slot so a candidate with a slow start can still demonstrate the things you care about. Use it as a working reference, not a one-time read.

Remote interviews have all the problems of in-person interviews plus a layer of friction the in-person version does not. The candidate is at home, on their setup, with their distractions. The interviewer is on a video call, watching a cursor in a shared editor, trying to read a person they have never met through a webcam.

Two adjustments matter. First, set up the room before the candidate joins. The link to the shared editor should be ready, the problem statement should be loaded, and the interviewer should already be in the document. Five minutes of "can you see my screen" at the start of a 45-minute interview is five minutes the candidate spends rattled. Second, narrate more than you would in person. The cues a candidate reads from facial expressions and body language do not travel well over video, so the interviewer has to be explicit: "Take a minute to think." "That looks right, what about edge cases?" "Let's move on to the next part." Without that, the candidate is interpreting silence, and silence on a webcam usually reads as disapproval whether or not it is.

ShareCode is built for this specific shape — the document is the workspace, both cursors are visible, the candidate can run code and the interviewer can see why something failed. Other shared-editor tools work too. The point is that the editor should not be the bottleneck. Whichever you choose, set it up the day before, not the morning of.

Live coding interviews are a useful test for a specific range of skills — reading and writing code under time pressure, thinking out loud, recovering from errors. They are a bad test for several others. They do not test how someone designs systems given days rather than minutes. They do not test how someone debugs an unfamiliar codebase. They do not test how someone collaborates with engineers over a longer arc than a single conversation.

Teams that interview well usually combine the live coding round with at least one of those longer-form tests. A take-home that exercises real codebase navigation. A system-design conversation where the candidate sketches an architecture against pushback. A pairing round where the candidate works alongside an engineer on a small piece of the existing product. Each test answers a different question, and the live coding round is one input among several rather than the deciding signal.

The mistake to avoid is treating the live coding interview as the test of engineering ability. It is the test of one slice. Pick the other slices deliberately and the hiring decision gets better; over-rely on the slice that is easiest to administer and the hiring decision gets noisier.

If you are preparing for interviews as a candidate, read the five-level prep post and treat it as a rehearsal plan. The point is not to memorise the solutions; the point is to use the problems as scaffolding while you practise the out-loud reasoning that interviewers are actually watching for.

If you are running interviews for your team, start with the interviewer-side playbook and use it to audit your current setup. Most teams that read it find at least one practice they had been doing on autopilot that does not hold up under scrutiny. The rest of this guide gives the framing; the playbook gives the specifics.