Interviewing well interview questions
14 questions across 5 sections, in the order you would learn them. Every answer here is one that works — but an answer you have read is not an answer you can give, so use Test yourself and say it out loud first.
Communicating while you work
Read the section that teaches thisIf this comes up in an interview
Tell me about a technically difficult project.
Lead with the problem and why it mattered, not the stack. Name one hard decision, the alternative you rejected and why. Include a number that shows you measured. Finish with what you would do differently, which reads as judgement rather than doubt.
Tell me about a time you were wrong.
Pick something genuinely wrong with a real consequence, say how you found out, what you did immediately, and what changed afterwards so it could not recur. Avoid the disguised strength, which every interviewer recognises instantly.
What do you do when you are stuck in an interview?
Say so, state what has been ruled out and why, and propose the next thing to try. Interviewers expect candidates to get stuck; they are assessing how you behave when it happens.
Preparing stories and practising for real
Read the section that teaches thisIf this comes up in an interview
Tell me about a time you were wrong about a technical decision.
Pick a real one where the decision mattered. Say what you believed and why it was reasonable at the time, what evidence showed you were wrong, what you did about it, and what you do differently now. The learning is the point of the answer.
Then they push further
What would you do differently if you faced that decision today?
Name a concrete change in how you decide, such as prototyping before committing, or setting a measurable check that would have caught it earlier. A general 'I would be more careful' scores poorly.
What gets marked up. Strong answers own the mistake without excuses, show the evidence that changed their mind, and end with a specific change in behaviour.
Walk me through a project you are proud of.
Two sentences of context, then the hardest problem and how you solved it, your decisions and the alternatives you rejected, and the result with numbers. Be ready to go deep on any part, because the interviewer will choose one.
The coding round where the spec keeps changing
Read the section that teaches thisIf this comes up in an interview
How do you write the first version of a problem you know will get harder, without over-engineering it?
Spend only on extensibility that costs a line rather than a structure: inject the clock or the store, key the state even when there is one key, and keep the decision in one method. Refuse anything that needs explaining, such as a strategy interface with one implementation. Then say the assumptions out loud so the interviewer can correct the ones the later levels will break.
Then they push further
The next requirement contradicts your design. Do you refactor or special-case it?
Refactor when the alternative is a second branch duplicating an existing one, or a flag threaded through several methods, because the level after this will then have to be written twice. Special-case it when the change is additive, or when there is not enough time left, and say out loud that time is the reason.
How do you avoid breaking the earlier levels as you add to them?
Write a small test per level as you finish it, using an injected clock so it does not sleep. Re-running them after each change takes seconds and is the only thing that tells you the third requirement did not break the first.
What gets marked up. Strong answers give a concrete budget for what extensibility is worth buying early, name the hidden dependency they would inject, and treat refactoring as an announced decision rather than something done silently.
Design a rate limiter that supports several limits per user at once.
Keep one allow(key) entry point and key the state by key and rule. Check every rule before consuming any budget, so a call rejected by the hourly rule does not spend the per-second one. That all-or-nothing pass is the part that has a bug in most implementations.
Then they push further
Now make it safe under concurrent callers.
The read-check-write inside allow is the race, so the lock goes around the whole of it rather than around each dictionary access. If the state moves out of process, the same operation has to become atomic in the store instead, which is why it was worth keeping in one method.
You are twenty minutes in and realise the design will not take the next requirement. What do you do?
Say so, immediately, with the reason and a time estimate: what the requirement contradicts, what the restructure is, and roughly how long it takes. Then do it. Recognising it early and out loud is read as judgement; discovering it silently at the last level is read as not having noticed.
Being drilled on your own work
Read the section that teaches thisIf this comes up in an interview
Walk me through the piece of work you are proudest of, and be ready for me to stop you.
Two sentences of context, then the decision you owned, the alternative you rejected and the evidence that settled it, then a number, then what went wrong and what you would change. Say explicitly which parts were yours and which were a colleague's, before being asked.
Then they push further
What did you personally do, as opposed to the team?
Name your part exactly and name what other people owned. Precision here costs nothing and buys credibility for everything else; vague ownership is found by the next question and the recovery is worse than the admission would have been.
What would you do differently?
Give one concrete change in how you would decide, not a resolution to be more careful. The strongest version names something you would do earlier, such as agreeing the evaluation set with the people who use the system before tuning anything.
Why didn't you just do it the other way?
If you considered it, give the reason and the evidence, and concede if theirs is better. If you did not, say so and then reason about it out loud: what it would have avoided, what it would have cost, and whether it was probably the better call.
What gets marked up. Strong answers are specific about personal ownership, name a rejected alternative unprompted, include at least one measured number, and treat a failure as a fact rather than a confession.
Tell me about something in your work that did not work.
State what happened, what it cost, how you found out, what you did immediately, and the change that means it cannot recur. Keep the tone flat. Minimising and performing remorse both read as avoiding the technical content, which is what the question is actually after.
How do you decide which project to present when you are asked for your best work?
The one where you made real decisions, not the one with the most recognisable name attached. The questions are about why you chose an approach and what you rejected, and you only have answers for choices you made. A small owned project beats a large one you were adjacent to.
The rounds that are not about code
Read the section that teaches thisIf this comes up in an interview
What do you think the most serious risk from this technology is, and what would change your mind?
Give a specific position with the reasons you hold it, then answer the second half honestly, because it is the half most candidates have nothing for. Name the evidence that would move you. What is assessed is that the position is yours and survives being pushed on, not which position it is.
Then they push further
Where do you disagree with us?
Give an actual disagreement, specifically, about something you have read. Agreeing with everything reads as not having engaged or as managing the room. Concede a point if the interviewer supplies one you had not considered; that is not losing the exchange.
Then why work here at all, if you think that?
The honest reconciliation, whatever it is. This is the consistency check: the answer has to fit what you said in the screen about why you applied, and what you will say in a design round about shipping carefully.
What gets marked up. Strong answers are specific, consistent with the rest of the loop, and hold under two or three exchanges of pushback while conceding individual points. Performed alarm and blanket dismissal both fail.
Are we allowed to use an AI assistant in this interview?
Ask this of the recruiter before the loop, in writing, for each round, because the rules differ by company and by round within one company. Asking on the day is fine but late; assuming in either direction is the actual risk.
Then they push further
You are told to use one and the interviewer is watching. What does good look like?
State the intent before each prompt, ask for the specific piece you have decided on rather than the whole problem, read the output and say what you are checking, and catch the thing it got wrong. Saying when you are not using it, and why, counts for as much as using it well.
How do you prepare for a values round when you do not know what they want to hear?
You are not meant to. Read what the organisation has published, form an actual response including the parts you disagree with, and work out what would change your mind. Then say the same thing in every round of the loop, because the answers are compared in the debrief.
These are the questions for one topic. The whole question bank covers every topic on the site.