Every question you ask in an interview exists on a spectrum. On one end: "Tell me about a time you disagreed with a coworker." The candidate has an answer for this. The answer has been tuned over the last four interview loops they sat in. It is optimised to fit the question. You will learn approximately nothing.
On the other end: "Show me how you'd explain our onboarding flow to a product manager who disagrees that it has a retention problem." The candidate has never been asked this, because nobody has ever heard of your onboarding flow. They have to build the answer in front of you, using whatever they actually know about product managers, onboarding flows, and disagreement.
That end of the spectrum is where the signal lives. Here's how to stay on it.
Why rehearsed answers quietly erode signal
By the time a candidate has sat through two or three loops, questions like "tell me about a hard bug you fixed" have usually picked up a pretty polished answer. They've told that story several times, refined which details to emphasise, and learned which audiences respond to which beats. The answer you're hearing isn't fabricated. It's just not being computed in front of you.
What a question like that tends to measure, in practice, is the candidate's ability to tell a rehearsed story well. That's a real skill, and for some roles it's one of the top skills. For most engineering roles, it's a skill they'll rarely be asked to use again once they're hired.
The issue isn't the topic of the question. It's that the candidate has a pre-computed answer. The thing worth doing as an interviewer is nudging the conversation toward questions that force a live computation.
Three patterns that resist rehearsal
Anchor to something the candidate has never seen. A take-home describing a system the candidate doesn't know (yours, a made-up one, a case study) is un-rehearsable by construction. This is most of the signal in a structured interview-prep exercise — the candidate can't have practised on your specific prompt, because your prompt exists only in your company.
Ask for disagreement with a claim. "Here's a design doc that proposes X. I want the three reasons this might be wrong." is a question that cannot be usefully rehearsed, because the candidate doesn't know what the design doc says until they read it. Listen for how specifically they disagree and how they rank the weaknesses.
Ask them to teach something back. "Walk me through how the thing you just built handles the failure case we discussed earlier." This only works if you introduced the failure case live, which means the candidate can't have prepared for it. You're testing whether they can hold a new constraint in their head and reason from it. If they can, they can probably work on your team.
Turning a bad question into a good one
Let's say you're hiring a distributed systems engineer. There are many different challenge statements and prompts you use, but not all of them provide you with a solid signal.
Bad: "What's your experience with distributed systems?"
Medium: "Describe a distributed system you've worked on and the tradeoffs you made."
Good: "Here's a sketch of a system where two services need to agree on a value. The current design uses last-writer-wins. Tell me when that's a defensible choice and when it isn't."
The bad version is answered by "I worked on distributed systems for two years." The medium version is answered by a rehearsed story about distributed systems. The good version forces the candidate to reason in front of you about a specific scenario. The same reasoning skill they'd use on your actual job.
One question worth retiring
"Tell me about a time you failed" is probably worth retiring from the loop. The question used to do real work. By now, though, most candidates above the junior level have two or three pre-written answers ready for it, ranked by which weakness feels safest to volunteer. What the question ends up surfacing is mostly which of those pre-written answers the candidate decided to lead with.
A cleaner replacement is usually a concrete, unfamiliar situation the candidate can reason about in front of you. Reasoning here doesn't mean arriving at the right answer. What matters is whether their thought process could plausibly lead somewhere useful, or whether they've latched on to the wrong part of the problem entirely. A candidate heading in a sensible direction without quite finishing the thought is usually a stronger signal than one producing a confident wrong answer quickly. Either the thinking is pointing somewhere, or it isn't, and that's the version of the signal worth showing up for.