By Johnny Campbell
Introduction
A CV tells you which tools someone has been in the same room as. It tells you almost nothing about depth. “I’ve used Terraform” and “I’ve untangled a Terraform state conflict at two in the morning with a release blocked behind me” are the same line on paper and two entirely different people in the job. The same gap exists in every craft. A marketing ops candidate who has “managed HubSpot” may have built the lifecycle model, or may have changed the sender name on a nurture email. A finance analyst who lists “financial modelling” may have built the three-statement model the board argues over, or may have updated a tab in someone else’s. A designer who lists a design system may have defined the token structure, or may have dragged components out of it. Technical skill is depth of craft — what someone can build, diagnose and judge with their own hands — and the CV is structurally incapable of showing it.
Most interviewers assess this badly in three ways. They tool-match: the job spec says Looker, the CV says Looker, tick. They test recall rather than judgement, asking what a term stands for or how a feature is configured, which rewards recent revision and punishes the person who has been building for ten years and looks things up. Worst of all, they hand the assessment to the most technical person in the room and let them freestyle. That interviewer asks whatever interests them that morning, goes deep on their own specialism, and comes out with a strong conviction that nobody else in the process can interrogate or compare.
This page covers 25 interview questions across four capability areas: Depth of Craft, Debugging and Diagnosis, Judgement About Tools and Trade-offs, and Keeping Skills Current. All questions are behavioural, and none require the interviewer to be technical enough to grade a right answer — they require the interviewer to notice whether the story has real texture in it. Swap the craft and the structure holds: these work as well for a revenue operations hire as for a platform engineer.
Depth of Craft
What good looks like
A candidate with real depth gets more specific the further you push, not less. They can walk through something they personally built or fixed, name the exact decisions and constraints involved, and point to a part of it they would do differently today. They talk about what they typed, drew, or configured with their own hands, not what the team or the platform achieved around them.
Behavioural questions
- Walk me through the hardest thing you have personally built.
- What made it hard — the complexity of the problem, the constraints you were under, or something else?
- What part of it did you build with your own hands, versus direct or coordinate?
- What’s the one decision in it you’d defend most strongly if someone challenged it?
- What would you change if you built it again today?
- Tell me about a piece of work you would build differently if you started it again today.
- What’s different about how you’d approach it now versus then?
- What did you learn in between that changed your view?
- Is the original still in use, and if so, what’s it costing whoever maintains it?
- What’s stopped you from going back and fixing it?
- Walk me through the piece of work that best shows the top of your ability.
- What specifically makes this the one you’d point to, rather than something more recent?
- What part of it was hardest for you personally, not for the team?
- Who else could have done it, and what would they have done differently?
- What’s the ceiling on your ability that this piece of work reveals — where does your skill run out?
- Tell me about a time you were the person others came to when something in your area broke.
- What kind of problem were people bringing you, and why you specifically?
- Walk me through one specific instance — what broke, and what did you actually do?
- How did you know when you’d genuinely fixed it versus made it stop complaining for now?
- What did you do to make sure you weren’t the only one who could fix it next time?
- Describe something you shipped that you knew was not good enough.
- What was wrong with it, specifically, at the point you shipped it?
- What made you ship it anyway rather than hold it back?
- What happened after it shipped — did the flaw ever surface, and how?
- Did you go back and fix it, and if not, why not?
- Walk me through something you built that outlived your involvement with it.
- What was it, and how long has it been running since you left it?
- What did you build into it, deliberately, to make it survive without you?
- Have you heard anything about how it’s held up — what’s changed, what’s broken?
- What would you build differently now, knowing it had to outlast you?
- Tell me about a time you had to defend your work to someone who could genuinely evaluate it.
- Who was the person, and what made them qualified to actually judge it?
- What did they challenge specifically?
- What did you concede, and what did you hold your ground on?
- Did their view of the work change afterward, and how do you know?
Situational scenario
You’re three weeks into fixing a recurring problem inside something substantial you built two years ago. The person who could explain the original reasoning behind a key decision has since left. You have a workaround that would hide the symptom within a day, and a proper fix that means rebuilding part of it, with no guarantee you’ll fully reconstruct the original thinking before you do.
Walk me through how you decide between the workaround and the rebuild.
Then introduce a constraint: “Your manager tells you the workaround is fine for now because nobody else has noticed the problem yet. Does that change your decision?”
What to listen for
whether they treat "nobody's noticed" as a reason to stop or a reason the problem is more dangerous, whether they describe a concrete way to reconstruct the missing context rather than guessing, and whether they can articulate what they'd be trading away by choosing the workaround.
Debugging and Diagnosis
What good looks like
A candidate with real hands-on time can walk through a hard failure in mechanical detail: what the symptom looked like, what they ruled out, what actually turned out to be wrong, and how they knew the fix had worked. They can also describe a diagnosis that went nowhere, or a fix that worked without them fully understanding why, without inflating either into a tidier story than it was.
Behavioural questions
- Walk me through the hardest failure you have personally diagnosed.
- What was the symptom you first saw, and how far was that from the actual cause?
- What did you rule out before you found the real cause, and how did you rule it out?
- What was the moment you actually found it?
- How did you confirm the fix worked, rather than just assuming it had?
- Tell me about a time you were wrong about the cause of a problem.
- What did you think the cause was, and what evidence pointed you there?
- What told you that you were wrong?
- How much time or damage did the wrong diagnosis cost before you corrected it?
- What do you do differently now to avoid the same mistake?
- Describe a problem you could not reproduce.
- What made it so hard to reproduce — timing, environment, scale, something else?
- What did you try that didn’t work?
- Did you ever resolve it, or is it still out there?
- What did you ship or communicate given you couldn’t pin it down?
- Walk me through a time you fixed something without ever understanding why the fix worked.
- What was the fix, and how did you land on it?
- What did you try that made logical sense but didn’t work?
- Does it still bother you that you don’t know why, or have you made peace with it?
- Did you ever go back and find the real explanation?
- Tell me about a problem that turned out to sit in a system you did not own.
- How far into your own investigation were you before you realised it wasn’t yours?
- What was the actual handoff like — how did you get the owning team to take it seriously?
- Did you keep investigating in parallel, or hand it off entirely?
- What was the eventual root cause, once someone found it?
- Describe the last time you had to work inside something you had not built.
- What did you have to understand before you could touch it safely?
- What was the biggest surprise about how it actually worked versus how you expected it to?
- What did you break, if anything, while learning it?
- What did you leave behind for the next person who has to do the same?
- Walk me through a problem you eventually gave up on.
- What was the problem, and what had you tried by the point you stopped?
- What was the actual decision point where you chose to stop rather than continue?
- What did you do instead — work around it, escalate it, leave it?
- Has it come back since, and if so, what happened?
Situational scenario
A problem you thought you’d fixed last month has come back, in front of the one person whose opinion of your judgement matters most for your next promotion. Your first two hypotheses about the cause don’t hold up when you test them. You have an hour before that person needs an answer, and no guarantee the real cause is even something you have access to fix.
Walk me through the hour.
Then introduce a constraint: “At the forty-minute mark, you find something that would explain the symptom but not the timing — it doesn't quite fit. Do you report it as the cause anyway?”
What to listen for
whether they keep testing a theory that doesn't quite fit rather than reaching for the nearest plausible story, whether they distinguish what they know from what they're inferring when they report back, and whether they're honest about the parts still unexplained rather than papering over them.
Judgement About Tools and Trade-offs
What good looks like
A candidate with judgement chooses tools and approaches deliberately, including choosing the less interesting or less capable option when the situation calls for it. They can name something they argued against adopting, something they introduced that did not work out, and explain the trade-off they were weighing each time — not just the tool they preferred.
Behavioural questions
- Tell me about a time you chose the less interesting technical option.
- What was the more interesting option, and what made it appealing?
- What specifically about the situation told you the boring option was right?
- Did anyone push back on the choice, and what did you say to them?
- How did it hold up over time?
- Walk me through a tool or approach you argued against adopting.
- What was being proposed, and who was proposing it?
- What was your actual objection — cost, fit, risk, something else?
- Did you win the argument, and if not, what happened when it was adopted anyway?
- Were you right, in hindsight?
- Describe something you deliberately built badly because the situation called for it.
- What did “badly” mean specifically — what corners did you knowingly cut?
- What told you this was the right call rather than just cutting corners under pressure?
- Did anyone else know it was deliberate, or did it look like a mistake to them?
- What happened to it afterward — did it get revisited, replaced, or left alone?
- Tell me about a tool you introduced that did not work out.
- What problem were you trying to solve when you introduced it?
- What went wrong, specifically?
- How long did it take before you or someone else called it — and who called it?
- What did you do with the mess it left behind?
- Walk me through a decision you made that constrained whoever came after you.
- What was the decision, and what did you know at the time about its long-term cost?
- Did you flag the constraint to anyone, or did it surface later on its own?
- Who eventually ran into it, and how did they find out?
- Would you make the same trade-off again?
- Describe a time you disagreed with someone more senior about a technical decision.
- What was the decision, and what was their reasoning?
- What was your actual counter-argument?
- How did you raise it, given the seniority gap?
- How was it resolved, and were you right?
Situational scenario
You’re two weeks into a project when a colleague suggests switching to a more powerful tool or platform mid-stream — one you know well and privately think is overkill for what this project actually needs, but which would make the work look more impressive in a review. Switching now would cost you roughly a third of the time you have left.
Walk me through how you handle the suggestion.
Then introduce a constraint: “The colleague who suggested it is more senior than you, and tells you they'll mention in the review whether their suggestion was taken. What do you do?”
What to listen for
whether they can articulate the actual mismatch between the tool and the need rather than just a preference, whether they raise the trade-off honestly with the senior colleague rather than either capitulating or getting defensive, and whether career optics visibly factor into the technical case they make.
Keeping Skills Current
What good looks like
A candidate who keeps their craft current can point to something specific in their recent work that changed because of something they learned, not just a course they completed or a newsletter they read. They can also name an area of their field they have fallen behind on, without pretending they are on top of everything, and describe what they are doing about the gap.
Behavioural questions
- Tell me about the most recent thing you learned that changed how you work.
- What was it, and what prompted you to learn it?
- What specifically did you do differently afterward — show me the before and after?
- How long ago was this, and has it stuck, or did you drift back to the old way?
- What’s the evidence it actually improved something, rather than just felt more modern?
- Walk me through how you got good at the thing you are best at.
- What was your actual starting point, and how far is that from where you are now?
- What was the hardest part of getting good at it?
- Who or what accelerated you the most, and how?
- Are you still improving at it, or have you plateaued?
- Describe an area of your field you have fallen behind on.
- What is it, specifically, and how do you know you’ve fallen behind?
- What’s the cost of that gap to you or your work right now?
- What, if anything, are you doing about it?
- Why hasn’t it been more of a priority to close?
- Tell me about the last thing you tried to learn and could not get working.
- What was it, and what made it hard specifically?
- What did you try before you got stuck?
- Did you go back to it later, or did you abandon it?
- What would it take for you to actually get it working?
- Walk me through something you are strong at now that you were poor at two years ago.
- What did “poor” actually look like back then — give me a specific example?
- What changed — deliberate practice, a mentor, being forced into it?
- What does “strong” look like now, concretely?
- What’s the next thing you’re poor at that you’re working on?
Situational scenario
Six months ago you learned a new approach or tool that’s clearly better for a piece of work you do regularly, but adopting it properly means unwinding several habits and a fair amount of existing work built the old way. You’ve been using the new approach for new work only, and the old backlog just keeps growing under the old method.
Walk me through how you’d decide whether, and how, to go back and convert the backlog.
Then introduce a constraint: “Nobody has asked you to convert it, and there's no deadline forcing the question. What actually makes you act, if anything does?”
What to listen for
whether they have a real threshold for when the inconsistency becomes worth fixing rather than an indefinite intention, whether they weigh the cost of the old habits compounding against the cost of stopping to convert, and whether they've actually converted anything before or this is purely hypothetical.
Red flags to watch for when assessing Technical Skill
Wide CV, one deep answer. The CV lists eight tools. In interview they can describe one in real detail and go abstract on the other seven. Ask about the third and fourth tools, not the first.
Narrating the system, not their part in it. They describe what the platform does, how the architecture fits together, what the team achieved — and never name a thing they personally changed inside it. Ask what they typed, drew, or wrote.
Detail that thins under pressure. The first answer is specific, the follow-up is vaguer, the third is a principle. Real depth runs the other way.
No failure inventory. They cannot name a bug that beat them, a tool choice that went wrong, or a gap in their own knowledge. Nobody who has built anything substantial has a clean record.
Recency cliff. All the hands-on stories are three or more years old, and everything since is oversight. Fine for some roles, fatal for others — but you should know which you are buying.
Vocabulary without mechanism. They use the right terms fluently and cannot explain what happens underneath one of them when you ask.
How to Use These Questions in a Structured Interview
Choose five or six questions across all four areas rather than eight from the one that interests your most technical panellist. Write a 1/3/5 rubric before the interview. A 1 describes work at team level with no personal action and no mechanism. A 3 describes something the candidate built or fixed themselves, explained clearly, with a named outcome. A 5 describes the same plus judgement — what they traded away, what they got wrong on the way, and what they would change now. Probe for mechanism first — what specifically did you change, and how did you know it worked? — then probe for the alternative: what else did you consider, and why did you reject it? Almost every weak candidate survives the opener. Very few survive the second probe.
This competency suffers from interviewer freestyling more than any other. Senior technical interviewers often regard structure as beneath them and improvise a conversation instead, which produces confident scores nobody else in the process can compare or defend. See how Interview Intelligence solves this → by giving every interviewer the same structure and surfacing the spread in how they score, before it costs you the hire.
Frequently asked questions
What are the best interview questions for technical skill?
The ones that force a specific artefact into the room. "Walk me through the hardest failure you have personally diagnosed" and "tell me about a time you were wrong about the cause of a problem" both demand a real event with real mechanics. Avoid anything answerable with a philosophy or a tool name. A useful test: if the candidate could answer it having read the documentation rather than done the work, rewrite it.
How can a non-technical recruiter screen for technical skill?
You are not grading the answer, you are grading its texture. Ask a candidate to walk you through something they built and listen for whether the detail deepens or thins as you ask more. Strong candidates name specific decisions, constraints and dead ends, and can explain them to you without jargon. Weak ones stay at the level of the system and the team. Record the answer and let the hiring manager verify the substance.
Should we use take-home tests to assess technical skill?
Sometimes, with discipline. A take-home is fair when it is under two hours, resembles the actual job, and is followed by a live conversation about the candidate's own choices — that conversation is where the real signal is. It is unfair when it is unpaid speculative work, when it runs to a weekend, or when it filters out capable people with caring responsibilities. Never use one as the first screen.
How do you tell tool familiarity apart from real depth?
Ask about the failure modes. Anyone can describe what a tool does well; only someone who has lived in it can tell you where it breaks, what it is bad at, and what they had to work around. Then ask what they would choose instead today and why. Familiarity produces features and benefits. Depth produces caveats.
How should the bar change between junior and senior candidates?
Change the blast radius, not the standard. A junior 5 might be one thing built properly, with a clear account of what they changed and what confused them. A senior 5 should include judgement across time — decisions that constrained others, trade-offs they defended, and things they got wrong at scale. The underlying evidence is identical: what did you touch, and what happened next.