Technical interview questions
Thirteen technical interview questions that work across any stack — debugging method, code review judgment, estimation, trade-offs, and how candidates work with AI. Each comes with what to listen for, an example answer, and red flags. Stack trivia tells you what a candidate has memorized; these tell you how they think.
All 13 questions
Technical interview questions to ask candidates
- 01Walk me through how you'd debug a problem you've never seen before, from the moment the report lands.
- 02You're reviewing a change that works but is built the wrong way. What do you actually write in the review?
- 03Explain something technical you built to me as if I ran the sales team. You have two minutes.
- 04Pick a technical decision you made where every option had a real cost. How did you choose, and what did you knowingly give up?
- 05How do you estimate work you've never done before? Use a real example.
Technical questions about working with AI
- 06An AI assistant wrote a 300-line change for you. What does your review look like before it merges?
- 07A junior on your team ships mostly AI-generated code. How do you check they actually understand the system?
- 08Where has an AI tool made you slower or worse at technical work, not faster? Be specific.
- 09AI assistants produce working code for most routine tasks now. What should a technical interview measure instead, and how would you show it?
Scenario questions for technical judgment
- 10Production is down. A dirty workaround takes five minutes; the proper fix takes a day. Talk me through the next 24 hours.
- 11You inherit a system with no docs, no tests, and the person who built it left. What do your first two weeks look like?
- 12In a planning meeting, a stakeholder asks you to commit to a delivery date for work you haven't scoped. What do you say — in the room?
- 13Halfway through building a feature you see a much simpler approach. Finishing the current one takes three days; restarting takes four. What do you do?
Questions 1–5
Technical interview questions to ask candidates
Walk me through how you'd debug a problem you've never seen before, from the moment the report lands.
A strong answer is a repeatable method: reproduce first, shrink the search space by halves, check what changed recently, and form one hypothesis at a time — not a highlight reel of lucky guesses.
What to look for
- Reproduces before theorizing — no fix attempts on a bug they can't trigger.
- Halves the search space deliberately: which side of the system can be ruled out?
- Asks what changed recently — deploys, config, data — before reading code.
Example answerRed flags
Example answer
First I reproduce it — if I can't, that becomes the task. Then I ask what changed: last deploy, config, dependencies. From there I bisect: does the bad data exist before this step or after? One hypothesis at a time, and I write down what I've ruled out so I don't loop. Most bugs die from the writing-down part.
Red flags
- Starts proposing fixes before reproducing or even reading the report closely.
- Debugging by superstition: restarts, reverts, and re-runs with no hypothesis.
You're reviewing a change that works but is built the wrong way. What do you actually write in the review?
A strong answer separates blocking from non-blocking feedback, explains the cost of the wrong structure in concrete terms, and considers the change's context — deadline, author's level, blast radius — before demanding a rewrite.
What to look for
- Distinguishes 'must fix before merge' from 'consider next time'.
- Explains why in terms of future cost, not personal style.
- Adjusts to context: a hotfix and a foundation get different bars.
Example answerRed flags
Example answer
Works-but-wrong splits into two cases. If the structure will hurt us — say it hard-codes a dependency we're about to swap — I block, and I say what unblocking looks like. If it's just not how I'd write it, I leave a non-blocking comment and approve. Half my early reviews were style tyranny; I try not to do that anymore.
Red flags
- Every difference from their own style is a blocking comment.
- Would approve anything that works — review is a rubber stamp.
Explain something technical you built to me as if I ran the sales team. You have two minutes.
A strong answer leads with what the system does for the business, uses one everyday analogy that survives scrutiny, and drops every acronym — without becoming so vague it says nothing.
What to look for
- Leads with the business effect, not the architecture.
- One analogy, carried consistently — not three mixed metaphors.
- Checks understanding instead of performing a monologue.
Example answerRed flags
Example answer
I built the thing that decides which warehouse ships your order. Before, a person chose from a spreadsheet and got it wrong about one time in ten — wrong meaning slower delivery and higher cost. Now the system checks stock, distance, and cutoff times and picks in under a second. Sales cares because delivery promises on the website became real.
Red flags
- Retreats into jargon within the first sentence and never comes back.
- Dumbs it down to nothing — 'it makes things faster' with no substance.
Pick a technical decision you made where every option had a real cost. How did you choose, and what did you knowingly give up?
Strong candidates name the axis they optimized — speed, reliability, cost, team capacity — say plainly what they sacrificed, and can report how the trade-off aged. 'The best of both' is not an answer.
What to look for
- Names what was sacrificed as specifically as what was gained.
- The deciding factor was a constraint, not a fashion.
- Reports how the decision aged, including regrets.
Example answerRed flags
Example answer
We needed offline support and had six weeks. The clean option was a sync engine; the honest option was read-only offline with a banner. I chose read-only — we gave up editing offline, which support flagged monthly for a year. Right call anyway: the sync engine would have eaten the quarter, and 90% of offline use was lookups.
Red flags
- Presents the chosen option as costless in hindsight.
- Chose by what a big company's blog recommended, not their own constraints.
How do you estimate work you've never done before? Use a real example.
A strong answer breaks the unknown into parts, sizes the known parts, prototypes the riskiest unknown first, and gives a range with the assumptions attached — then updates the estimate when reality disagrees.
What to look for
- Decomposes until most pieces look like something they've done.
- Attacks the riskiest unknown first, before promising a date.
- Gives ranges with assumptions, and updates them out loud.
Example answerRed flags
Example answer
Asked to integrate a payment provider I'd never touched, I split it: API plumbing, our order-state changes, and webhooks. The first two I could size from past work — about a week. Webhooks were the unknown, so I spent one day spiking retries and idempotency before answering. I said two to three weeks depending on that spike. It took three.
Red flags
- Gives single-point estimates with confidence and no assumptions.
- Pads everything threefold instead of reducing the uncertainty.
Questions 6–9
Technical questions about working with AI
2026 · AIAn AI assistant wrote a 300-line change for you. What does your review look like before it merges?
A strong answer reviews AI code harder than a colleague's, and differently: checking edge cases, invented APIs, and security-sensitive lines first, because the code's confidence carries no information about its correctness.
What to look for
- Reviews AI output with more suspicion than a teammate's, not less.
- Knows the specific failure modes: plausible invented APIs, missed edge cases, silent behavior changes.
- Runs or tests the code — reading alone isn't the bar.
Example answerRed flags
Example answer
Same gate as human code — tests pass, I can explain every line — plus two AI-specific checks. I verify any API it called actually exists in our version, because it once invented a config flag that parsed fine and did nothing. And I diff behavior on edge cases, since generated code tends to nail the happy path and guess the rest.
Red flags
- Merges AI output that passes tests without reading it.
- Can't name a single AI-specific failure mode from experience.
A junior on your team ships mostly AI-generated code. How do you check they actually understand the system?
Strong answers test understanding directly — ask the junior to explain a change line by line, predict behavior on an edge case, or modify it without the tool — and treat AI use itself as normal.
What to look for
- Separates the tool question from the understanding question — AI use isn't the offense.
- Concrete probes: explain the diff, predict an edge case, extend it live.
- Builds the habit through review and pairing rather than banning the tool.
Example answerRed flags
Example answer
I don't care that the code is generated; I care whether they can defend it. In review I ask one why per change — why this data structure, what happens when the input is empty. If the answers are hollow, we pair: they drive without the assistant for an hour. That usually tells both of us the truth.
Red flags
- Response is to ban AI tools for juniors outright.
- No mechanism at all — assumes shipped code equals understanding.
Where has an AI tool made you slower or worse at technical work, not faster? Be specific.
A credible answer names a real task where the tool cost time — wrong-direction debugging suggestions, plausible but broken scaffolding, review overhead exceeding writing time — and the boundary they drew from it.
What to look for
- A specific task with the time cost named honestly.
- Diagnosed why the tool failed there, not just that it did.
- Drew a boundary they still follow, and can state it.
Example answerRed flags
Example answer
Debugging a race condition. The assistant kept offering confident fixes for the wrong cause, and I burned an afternoon evaluating them instead of instrumenting the code. Its suggestions were an anchor — each one plausible enough to check. Now for concurrency and anything timing-dependent I instrument first and ask the model questions second, if at all.
Red flags
- Claims AI tools have never cost them time — they haven't pushed the tools hard enough to know.
- The takeaway was to stop using AI entirely rather than to learn its edges.
AI assistants produce working code for most routine tasks now. What should a technical interview measure instead, and how would you show it?
Strong answers land on judgment: knowing what to build, verifying correctness, debugging the unfamiliar, and explaining trade-offs — then point to evidence of those skills in their own work rather than syntax recall.
What to look for
- Identifies judgment and verification as the scarce skills, unprompted.
- Applies it to themselves: what they'd want to be tested on.
- No resentment of the premise — they've already adapted.
Example answerRed flags
Example answer
Measure what survives the tool: can I tell correct from plausible, can I debug something no model has seen, do I know what not to build. For me, test that by handing me a broken system and watching the first twenty minutes. Syntax recall stopped being the job a while ago — reading critically became it.
Red flags
- Insists nothing has changed and interviews should stay algorithm drills.
- Argues technical skill no longer matters — judgment without fundamentals is guessing.
Questions 10–13
Scenario questions for technical judgment
Production is down. A dirty workaround takes five minutes; the proper fix takes a day. Talk me through the next 24 hours.
A strong answer ships the workaround with eyes open — flagged, time-boxed, tracked — restores service first, then makes the proper fix real work with an owner and a date, not a comment saying TODO.
What to look for
- Restores service first without hand-wringing — users before elegance.
- Marks the debt visibly: ticket, owner, date, alarm.
- Runs a blameless look at why the failure was possible.
Example answerRed flags
Example answer
Five-minute fix ships now — with a feature flag or clear marker so it can't fossilize silently. I tell whoever owns the service what I did and what it doesn't cover. Tomorrow the proper fix gets a ticket with my name and this sprint's slot, because next week it becomes archaeology. Then a short postmortem: why was this failure cheap?
Red flags
- Refuses the workaround while users are down — correctness theater.
- Ships the hack and moves on; the proper fix has no owner.
You inherit a system with no docs, no tests, and the person who built it left. What do your first two weeks look like?
Strong answers map before touching: trace the critical paths, find who depends on what, add monitoring and a test harness around the scariest parts, and change nothing until the blast radius is known.
What to look for
- Reads the system's behavior in production, not just its code.
- Finds the humans: users, downstream teams, whoever filed the last incident.
- First changes are observability and tests, not refactors.
Example answerRed flags
Example answer
Week one I don't change anything. I trace the two or three paths that matter — where money or data moves — and write down what I think each does. I find who screams when it breaks and ask them what it's really for. Week two: logging where I was blind, tests around the scariest path, then the first small change.
Red flags
- First instinct is a rewrite — before knowing what the system does.
- Plans to learn it purely by reading code, with no production signals or humans consulted.
In a planning meeting, a stakeholder asks you to commit to a delivery date for work you haven't scoped. What do you say — in the room?
A strong answer neither caves nor stonewalls: it gives the honest state, commits to a scoping deadline instead of a delivery date, and offers what can be promised today.
What to look for
- Commits to something concrete in the room — a scoping date, a range.
- Explains the cost of a guessed date in the stakeholder's terms.
- Doesn't perform certainty they don't have.
Example answerRed flags
Example answer
I'd say: I can't give you a date yet without lying to you, and a made-up date costs you more than a short wait. Here's what I can commit to now — by Thursday you'll have a scoped estimate with a range, and I'll flag the biggest risk today. Most stakeholders take that trade when it's offered plainly.
Red flags
- Names a date under pressure and plans to renegotiate later.
- Answers 'it depends' and leaves the stakeholder with nothing.
Halfway through building a feature you see a much simpler approach. Finishing the current one takes three days; restarting takes four. What do you do?
There is no universally right choice — a strong answer names the factors that decide it: maintenance cost of each version, deadline reality, who else is blocked, and sunk cost excluded from the math.
What to look for
- Sunk cost is explicitly excluded — the three days spent don't vote.
- Weighs long-term maintenance against the one-day difference.
- Consults whoever is blocked before deciding alone.
Example answerRed flags
Example answer
One day of difference buys a simpler system forever — usually I restart. But I'd check two things first: whether anyone is blocked on the original date, and whether the simple approach has been proven or just looks clean from a distance. I'd spike its riskiest assumption for two hours before throwing away working code.
Red flags
- Always finishes because of the time already spent.
- Restarts on aesthetics without testing the new approach's hard part.
Scoring rubric
| Score | Evidence anchor |
|---|---|
| 1 | Answers in memorized definitions and framework names; no debugging method, no real trade-off story, and technical explanations collapse the moment you ask why. |
| 2 | Can talk through familiar tasks but has no transferable method: debugging is trial and error, estimates are single guesses, and AI tools are either dismissed or trusted blindly. |
| 3 | A visible method for debugging and estimation, honest about one real trade-off, and reviews AI output before shipping. Explanations to non-engineers still lean on jargon. |
| 4 | Method plus judgment: reasons from constraints, separates blocking from cosmetic in review, verifies AI-generated work by habit, and can make a system make sense to the sales team. |
| 5 | You'd let them design the interview: they sharpen your own questions, name their past mistakes with numbers attached, and every answer shows taste about what matters and what doesn't. |
Frequently asked questions
How do you structure a technical interview?
Sixty minutes works as: five for context, twenty-five on two questions from the first section, fifteen on one AI and one scenario question, ten for the candidate's questions, five for scoring notes. Fewer questions, pushed deeper, beat coverage.
Should technical questions be split into difficulty tiers?
Yes — four tiers work: basic (definitions), intermediate (apply it), advanced (design under constraints), expert (failure modes and trade-offs). Ask every candidate the same opener, then climb tiers until answers thin out. Where they stop is the signal.
Do these questions work if I don't know the candidate's stack?
That's the point — they test method, not syntax. Debugging approach, estimation, and trade-off reasoning transfer across languages. For stack-specific depth, pair this set with a role page like DevOps or data engineer.
Should a technical interview include live coding?
Only if the job involves writing code under observation, which it rarely does. A take-home reviewed together, or a debugging exercise on realistic code, measures the actual work better and stresses candidates less.
Which of these work for a first-round interview?
The debugging walkthrough, the estimation question, and one AI question — all answerable by voice and hard to bluff. Kira can run that subset with every applicant before you spend an engineer's hour.