An interviewer who jumps in after a minute of silence gets a candidate who takes the hint and finishes, and a scorecard that calls them a strong problem solver on an answer half written from across the table. An interviewer who says nothing for twenty minutes watches the candidate go in circles, then writes “struggled” and calls it holding the bar.

Both failures come from help that was never planned, so I’d open any list of coding interview best practices with the help: decide the hints before the call, from the smallest nudge to the largest, and write each one down as you give it. Then the scorecard can separate what the candidate did on their own from what you did for them, and the debrief stops hiring your answer or rejecting someone you let sink.

Pick the skills before you pick the problem.

The problem is only a way to watch the skills the role needs, so choose the skills first and then pick a problem that shows them.

Pick four to six, and write down strong and weak for each one before you choose a problem. With that description written down, two interviewers can give the same code the same score. Keep it in an interview rubric for each skill, so every interviewer for the role scores against the same words.

One hour rarely shows all six, and it doesn’t have to. Take off the scorecard any skill the problem can’t show, so no interviewer is asked to rate something the round never tested.

Coding interview best practices for the first five minutes.

The opening minutes decide whether the candidate spends the hour on the problem or on working out what you want from them.

Tell the candidate the format, which is one problem built up in stages, and roughly how long each stage should take. Say which language they can use and whether they can look things up. Then tell them what you’ll do if they get stuck, so a hint arrives as part of the plan rather than as a sign that they’re failing.

Ask them to think aloud, and say why: you can score only the reasoning you can hear. A candidate who knows that will talk through a dead end instead of hiding it, and the dead end is often where the best evidence sits.

If the call is recorded, tell the candidate at the start and follow your team’s consent policy.

Build one problem in three stages.

One problem that grows beats a run of short puzzles, because the later stages show how the candidate extends code they wrote themselves, which is closer to the daily work than a fresh puzzle.

• The warm-up: a version the candidate can finish in about ten minutes, so they settle in and you see how they set up their code.
• The core: the stage that changes the requirement, where the decisions you came to score happen. Spend most of the hour here.
• The extension: a harder variation you reach only if the first two land quickly. Treat it as a bonus, and never mark anyone down for not getting there.

Write the stages down with the time you expect each to take, and use the same problem for everyone you interview for the role. Once the problem changes between candidates, their scores stop being comparable.

Decide your hints before the candidate gets stuck.

I’d plan the hints before anything else in the round, because they decide whose work the score describes.

When a candidate stalls, give them a few minutes before you say anything, because how someone gets themselves unstuck is evidence you can’t collect any other way. If they ask you for the right approach, turn the question back: “Talk me through what you’re considering.”

If they still need help, give the smallest hint on a ladder you wrote before the call, and log every hint you give. Move up a rung only when the last one didn’t help, because each rung tells the scorecard something different about whose work the next ten minutes were.

Silence works too, up to a point. A candidate who is typing and talking needs nothing from you, but one who has sat stuck for ten minutes is being tested on nerve, and the next rung is overdue.

Score each stage while the code is on screen.

Once the call ends, the code is off the screen and what remains is how the hour felt, so the scoring belongs inside the hour.

At each stage boundary, take a short pause and write a line of evidence for each skill that stage showed: what the candidate did, in their words or their code, with any hint from your log beside it. One line per skill is enough to score from.

Mark the skills you didn’t get to test, too. A blank under a skill tells the hiring manager the round never reached it, which helps them more than a middling score that guesses.

Then score each skill from those lines. I’d trust the lines over the overall impression, which tends to follow however the last stage went.

When the candidate is clearly off track.

Sometimes the warm-up shows you the candidate can’t do the coding this role needs, and there are forty minutes left on the call.

Riding out the hour on a problem they can’t finish costs them a miserable afternoon and gives you no new evidence. Keep an easier problem ready, or switch to a walk through code they’ve written before and ask about the decisions in it. They leave having shown you something, and you still collect evidence on the skills the first stage never reached.

Say plainly that you’re changing course. Candidates can tell when a round has turned, and pretending otherwise makes the rest of the call harder for both of you.

Where Metaview fits in a coding interview.

Everything above asks the interviewer to watch closely and write at the same time, and in an hour of code the writing slips first.

Shahriar Tajbakhsh, chief technology officer and co-founder of Metaview, has written about what separates a good interviewer from a bad one, and he describes his own route to the craft as reflection and system.

Reflection on a coding round needs a record of where you stepped in and what the candidate did next. Metaview’s Notetaker records the interview and writes structured notes from the transcript, and in a technical interview the recording covers the code as well as the conversation. Since the Notetaker captures every spoken word, the hint you gave and the candidate’s answer to it sit in the same record. The transcript holds your words without marking which of them was a hint or which rung it came from, so your hand-written log still tells the scorecard where the credit goes.

A team can set its own notes template for each kind of conversation, so a coding round can get a layout of its own.

The notes can also be laid out as questions and answers, which suits a round built in stages: each stage’s question, then what the candidate said under it.

When the call ends, Metaview drafts the scorecard from what was said. Put your hint log beside it before you rate anything, then submit it with your own rating on each skill.

To find the skills your coding rounds never reach, Metaview Reports queries the team’s own interview data and can show question coverage by interviewer and by role. A skill that gets no questions in round after round belongs in a different interview or off the scorecard.

Hannah Wardle, global head of recruiting at Quora, described the pressure from the recruiting side: “When you’re doing technical interviews, you feel huge pressure to make sure that you don’t miss certain things that would be really important for this candidate.”

With the round on record, an interviewer can watch the candidate for the whole hour and write only the hint log.

If your rounds run in a shared editor or on a whiteboard, a separate product update on notes for technical interviews covers how the Notetaker handles that work.

Read your hint logs before the next round.

Pull the hint logs and scorecards from one role’s recent coding rounds and read them side by side. Each check below says what to change when it comes back wrong.

• Every logged hint shows up on the scorecard, next to the skill it touched. A hint in the log and missing from the scorecard means the candidate got credit for your work, so add a line for hints to the scorecard template.
• Each skill rating has a line of the candidate’s own work under it. Where a rating has none, score at the stage boundaries instead of after the call.
• Every candidate saw the same problem. If it changed, their scores can’t be compared, so settle on one problem before the next candidate.
• Skills the round never reached are blank. A middling score with no evidence under it is a guess, so blank it and say why.

Before your next coding round, I’d write the hint ladder ahead of anything else in this post, because with it the scorecard shows the candidate’s own work and marks your help where you gave it.