Technical Interview Follow-Up Questions: A Five-Step Ladder for Telling Rehearsed From Real

By Pooja Goenka · Published 2026-10-21

The best follow-up questions in a technical interview are short, ask for something specific, and arrive in the same order for every candidate. Start with what the candidate personally did, then ask why it worked, what breaks it, what they rejected, and how they would know it was right. Five questions in that order separate someone who has done the work from someone who has read about it, and they give you notes you can score.

Here is the short version:

  • A first answer mostly measures preparation. Follow-ups measure experience.
  • Use a fixed ladder: ownership, mechanism, edge, alternative, verification.
  • Stop climbing when you have enough evidence for the scorecard. Five rungs on every question would be an interrogation.
  • Ask the same ladder of every candidate, or two people are not being compared on the same thing.
  • Write down what they said, in their words, before you decide what it means.

A strong first answer can fall apart on the second question, and a shaky one can come from someone who knows the system well and is nervous. Both happen in the same hour, so the second question is the one worth designing.

Why the first answer is the weak signal

Candidates prepare for the question you are most likely to ask. Common questions have common model answers, and those answers are easy to learn and to deliver fluently. Fluency is not a flaw, but it is cheap, and it looks the same whether the speaker built the thing or watched a video about it.

The follow-up is harder to rehearse because it depends on what the candidate just said. That is the whole value. A good probe makes someone leave the script and describe their own situation, and the details they reach for show what is underneath.

There is a fair objection, which is that free-form follow-ups are where interviewers drift. One candidate gets a gentle question and another gets a grilling, and the difference ends up in the notes as if it were a difference between the candidates. The fixed ladder below is my answer to that. You choose the rung, not the mood.

The ladder

Rung 1: ownership

"Which part of that did you do yourself?" "Walk me through the last time you did this, from the start."

Many answers drift into "we". That is normal and honest, because most work is shared. The question is not an accusation. You want the boundary of the candidate's own contribution, and you want a real instance rather than the general case.

A strong answer names a decision, a file, a bug or a person. A weak one stays at the level of the method: "we would typically set up a pipeline and monitor it."

Rung 2: mechanism

"Why does that work?" "What is happening underneath when you do that?"

This is the rung that separates a recited fact from an understood one. If a candidate says they added an index to speed up a query, ask what the database does differently with the index. If they say they cached a response, ask what decides when the cache entry is wrong.

You are not hunting for textbook wording. A candidate who explains it in plain, slightly clumsy language and gets the cause right is showing you more than one who produces a polished sentence with no cause in it.

Rung 3: edge

"What happens if the input is empty, or ten times larger?" "What breaks first if this runs at twice the load?"

Change one condition and see whether the model in their head still holds. People who have run something in production tend to answer with something that has happened to them. People who have not tend to answer in the abstract, or to say it would be fine.

Pick the edge from the candidate's own example. A generic edge case you reuse for everyone is easier to prepare for.

Rung 4: alternative

"What else did you consider, and why not that?" "If you did this again, what would you change?"

This shows whether a decision was a decision. "It was what we had" is an honest answer and a useful one. So is a real trade-off with a cost on each side. The warning sign is a candidate who cannot name anything they gave up, because that often means the choice was made for them or never examined.

Rung 5: verification

"How did you know it worked?" "How would you check that answer is right?"

This is the rung I would weight most, because checking your own work and other people's is a large part of any engineering job. A good answer names a test, a metric, a log line, a comparison against a known result, or a second source. A weak one is a feeling: "it looked right", "the users were happy".

If you are hiring for roles that use AI tools every day, this rung carries over directly. The same question works on an AI-written answer, and I wrote up that version in how to test whether candidates can spot mistakes in AI answers.

A worked example

Suppose the first question is "Tell me about a time you made a slow API endpoint faster." The candidate says they found a slow query and added an index, and the endpoint dropped from a few seconds to well under one.

  • Ownership: "Did you find the query, or was it flagged to you?" The candidate says they pulled the slow-query log themselves.
  • Mechanism: "What did the index change about how the database found the rows?" They explain it avoided scanning the whole table.
  • Edge: "What does that index cost on writes?" They say inserts got slightly slower, and that the table takes a lot of writes.
  • Alternative: "Was there another way?" They mention caching, and say they rejected it because the data changed too often.
  • Verification: "How did you know it was the index and not just a warm cache?" They describe running the query plan before and after, and comparing against production timings over a day.

That is five short questions and perhaps six minutes. Compare it with a candidate who answers rung 1 with "the team handled the database side" and rung 2 with "indexes just make things faster". You now have evidence on each, and the notes write themselves.

Rules that keep it fair

  • The questions can be worded to fit the answer. The rungs should not change between candidates.
  • If rungs 1 and 2 are both weak, you do not need to climb to 5. If rung 2 is strong, you can skip ahead to 4.
  • "Did you think about caching?" hands over the answer. "What else did you consider?" does not.
  • Give a few seconds before rephrasing. Many candidates answer well on the second beat.
  • If you give a hint, write down that you gave it.
  • Note what they said, then decide what it means afterwards. It keeps the scorecard honest and it makes the later debrief about evidence instead of impressions.

Nerves are not a verdict

A hesitant answer to rung 2 can mean the candidate does not know, or it can mean they have never had to say it aloud. You can tell which by whether the answer improves when you rephrase. If a different wording unlocks a good explanation, the knowledge was there. Score what they showed once they understood the question.

Where LogicWiz fits

LogicWiz Interviews has an AI interviewer, Aria, who asks a follow-up on what the candidate actually said rather than moving to the next scripted question. In an AI-led round the follow-ups are scored against your rubric as the round goes, and the result is a scored report across Technical, Reasoning, Communication and Confidence. That suits a first round where volume would otherwise force a rejection on a résumé alone. If you run the round yourself, the ladder above works on paper.

Common questions

How many follow-up questions should you ask in a technical interview?

Enough to get the evidence you need for each scorecard item, which is usually two to four per main question. Ask the same rungs of every candidate, and stop earlier when the answers are clearly strong or clearly empty.

What are good follow-up questions for a technical interview?

Short, specific ones: which part you did yourself, why it works, what happens when an input changes, what else you considered, and how you checked the result. Each one asks the candidate to describe their own work.

How do you tell a rehearsed answer from a real one?

Change something small and see whether the explanation adapts. People who did the work answer in terms of their own system, name a decision or a mistake, and can say how they verified the result. A rehearsed answer tends to restate the method in general terms.

Are follow-up questions unfair to nervous candidates?

They can be, if they are delivered as a challenge. Keep the tone curious, allow a pause, rephrase once, and score what the candidate shows after they understand the question.

Can the same follow-ups work for a fresher?

Yes, with an adjusted example. Ask about a project, an assignment or an open-source change instead of a production system. The rungs stay the same.

Back to the blog