A lot of teams spend serious effort designing their take-home. They pick the problem, scope the time, tune the prompts. Then they schedule a 45-minute follow-up interview with one line in the brief: "talk through what they submitted." The artefact gets attention. The conversation that turns the artefact into a hiring decision gets almost none.

That's backward. The take-home is an input. The follow-up is where you actually generate signal. If you designed a perfect prompt and then walked into the follow-up without a plan, you've wasted most of what the prompt was supposed to do for you.

What the follow-up is actually for

It isn't a quiz about the code. It isn't a second pass at grading. The follow-up interview has three jobs, in rough order:

  1. Confirm the submission was actually theirs, or that they understand it deeply enough for the difference not to matter.
  2. Surface the reasoning behind choices they made, especially the ones that look unusual.
  3. Put one new constraint or disagreement in front of them to see how they reason under live pressure.

Grading the code is not on that list. You already graded the code when you read the submission. Re-litigating it in the follow-up is a way of running out the clock.

Honestly, the code usually isn't the most interesting thing about a submission anyway. What you actually want to know about a candidate — how they framed an ambiguous problem, which trade-offs they noticed, where they pushed back on their AI collaborator, what they left out and why — lives in the reasoning around the work, not in the code itself. The follow-up is where you go after that reasoning.

Pick your openings in advance

The biggest mistake interviewers make in a follow-up is starting with "walk me through your solution." That's a question the candidate has prepared for, because every follow-up opens with it. You'll get a clean, rehearsed explanation that closes off the interesting territory before you've asked anything.

Pick two or three specific openings from their submission before the meeting. Things that caught your eye. Things you disagreed with. Things that were absent. For example:

  • "In your write-up you argued that building this in-house was probably the right call over the off-the-shelf option. Tell me what would make you change your mind."
  • "You laid out the happy path in detail but didn't name a single failure mode. Is that a scope call, or did it not feel load-bearing to you?"
  • "Your chat transcript shows you pushed back on the AI's first suggestion for the schema. What made you suspicious of it?"

Specific questions produce specific answers. Generic questions produce rehearsed ones.

Introduce one live constraint

Sometime in the middle of the conversation, put a new thing in front of them. "What if the write volume was 10x what we assumed? What's the first thing that breaks, and how would you change your design?" You are not testing whether they can redesign the whole thing in ten minutes. You are testing how they update their model when reality changes.

The two failure modes here are instructive. A weaker candidate either insists their original design would still work, or panics and proposes a full rewrite. A stronger one looks at the new constraint, identifies the part of their design that's load-bearing for the new case, and reasons about that part specifically while leaving the rest alone. That kind of local reasoning is a skill that doesn't show up anywhere in a static submission.

Read the transcript out loud

Bring one specific exchange from the AI transcript into the room and ask the candidate to talk about it. "You asked the AI about rate limiting here and then ignored its suggestion. Walk me through what you were thinking."

This is the cleanest test of whether the candidate is steering the tool or being steered by it. Their answer in the room either corroborates the exchange or reveals they don't remember what they were thinking. Both are information. This is exactly the use case the transcript is designed for, and the follow-up is where it pays out.

Close with something they wrote

Before the last question, scroll back to one sentence the candidate wrote that was particularly sharp, and read it back to them. "You said 'the second option only makes sense if we're willing to absorb a latency cost on the read path.' I want to ask you about that: where does the cost actually come from?"

That closing move does two things. It tells the candidate you read their submission carefully. It also surfaces the depth of their understanding. If they wrote the sentence because it sounded good, they'll flounder. If they wrote it because they meant it, they'll run with it.

One change worth considering

If you do nothing else: stop letting interviewers open the follow-up with "walk me through your solution." Write three specific openings on the prep doc instead. That single change tends to produce more usable signal in a month than any other tweak to the take-home itself.