Software engineer interview questions to ask candidates

1. Walk me through the last thing you shipped to production, end to end — from the first conversation about it to users having it. What was your part at each step, and how long did the whole thing take?

   Why ask it: Opens with evidence instead of autobiography and immediately shows the scope the candidate actually operates at.

   Listen for: One named feature, their personal role at each stage (spec, review, rollout), a realistic duration, and "I" rather than "we" for the parts they owned.

2. Describe the codebase you work in most right now — language, rough size, how old it is. If you had a free month, which part would you rewrite, and why that part?

   Why ask it: Engineers who can critique their own system with specifics understand it; those who answer in generalities have been passengers in it.

   Listen for: Concrete facts (ten-year-old Rails monolith, ~400k lines, 12 engineers touching it) and a rewrite target justified by a measurable pain, like "every pricing change touches 14 files".

3. In your current job, which technical decisions do you make on your own and which do you take to someone else? Give me the most recent real example of each.

   Why ask it: Calibrates actual seniority by the decisions they're trusted with, which titles and years of experience routinely misstate.

   Listen for: Fresh examples on both sides with a sensible line between them — chose the caching approach alone, escalated the data-retention change because it touched customer contracts.

4. What specifically made you apply for this role, and what would you want to see in your first month here to know you made the right call?

   Why ask it: Filters spray-and-pray applicants and surfaces expectations about pace, autonomy, and stack that you can sanity-check against reality on the spot.

   Listen for: Something true about your product or team that isn't on the careers page, plus a checkable first-month expectation like release cadence, review culture, or time to first deploy.

1. Pick a technical design you actually wrote down in the past year — a design doc, an RFC, even a long PR description. Walk me through the options you considered, the one you chose, and the pushback you got.

   Why ask it: A real document pins the discussion to decisions they truly made, and the pushback half reveals whether they design with the team or at it.

   Listen for: At least two genuinely different options with the losing one's merits stated fairly, named reviewers, and one concrete change they made because of review.

2. Tell me about the worst production incident you've been part of in the last two years. Take me from the first alert to resolution — what did you personally do, and what changed afterward?

   Why ask it: Incidents expose debugging method and composure, and the "what changed" half shows whether they close loops or just patch and move on.

   Listen for: A timeline with tools named (logs, traces, git bisect, feature-flag rollback), a root cause deeper than "bad deploy", and a durable follow-up they added — an alert, a test, a runbook.

3. Tell me about a recent code review where you pushed back hard on a teammate's pull request. What was wrong, how did you say it, and how did it end?

   Why ask it: Review judgment is a daily senior responsibility, and this shows both their technical bar and whether they can hold it without burning the relationship.

   Listen for: A named defect class (race condition, missing migration rollback, N+1 query), pushback framed as questions or data, and an ending where someone changed their mind for stated reasons.

4. Give me one example where you deliberately shipped the quick-and-dirty solution, and one where you fought for the slower, cleaner one. How did you tell the two situations apart?

   Why ask it: This tradeoff is the daily reality of product-company engineering, and demanding one example of each defeats the single rehearsed story.

   Listen for: Decision criteria tied to blast radius and reversibility — "the hack sat behind a flag for 2% of users" — plus evidence they tracked the shortcut afterward instead of forgetting it.

5. Take a feature you use every day that looks simple — Slack's unread badge, Gmail's undo-send, a shared cart — and sketch how you'd build it: where the state lives, what breaks, and what you'd cut from version one.

   Why ask it: One deliberate hypothetical on familiar ground tests design thinking without trivia, and the cut-from-v1 clause tests product judgment alongside architecture.

   Listen for: They state assumptions before designing, surface the hard part unprompted (multi-device sync, the race between undo and send), and cut scope by user impact rather than by effort.

6. Tell me about the last bug of yours that reached production. How did it get past your tests and your reviewer, and what have you changed about how you test since?

   Why ask it: Everyone ships bugs, so the honest version is always available — this measures ownership and whether their quality practice actually updates on evidence.

   Listen for: They name the bug plainly without blaming QA or the reviewer, identify the missing test class ("nothing covered a retry hitting a stale cache"), and cite the specific check they added.

1. Tell me about the last time you and a product manager or designer wanted different things on the same feature. What did each side want, and where did it land?

   Why ask it: Scope negotiation happens weekly at a product company, and this shows whether they argue from user evidence, cave silently, or stonewall.

   Listen for: Both positions stated fairly, a concrete resolution mechanism — a prototype, a data pull, an agreed cut line — and at least one occasion where they moved their own position.

2. Who is the last engineer you helped get noticeably better, and what did you actually do? Give me one specific thing about how they work that changed.

   Why ask it: Mid-to-senior impact is partly leverage through others, and asking for one named change blocks the stock "I do code reviews and pairing" answer.

   Listen for: A specific transferred practice — taught them to bisect, got them writing test plans before code — how long it took, and how they know it stuck.

3. Walk me through the last time you realized mid-project that you were going to miss a date. When did you flag it, to whom, and what happened next?

   Why ask it: Quiet slippage is the most expensive failure mode on a product team, and the timing of the flag is the tell you can't get from references.

   Listen for: They raised it while options still existed, arrived with choices (cut scope, move the date, add help), and can say what the PM or manager actually decided.

1. Walk me through how AI coding tools fit into your week right now. What was the last task where one genuinely saved you time, and the last one where you abandoned it and did the work by hand?

   Why ask it: Asking for one win and one abandonment in the same breath gets their real workflow instead of either marketing or reflexive skepticism.

   Listen for: Named tools and a fresh example in each direction — "it wrote the migration boilerplate in minutes" versus "I turned it off halfway through refactoring our auth flow" — with reasons tied to risk or review cost.

2. When an AI assistant writes a meaningful chunk of code for you, what do you do before that code merges? Tell me about a time your checks caught something.

   Why ask it: Verification discipline is what separates AI leverage from AI-generated incidents, and the caught-something half proves the checklist is real.

   Listen for: A concrete routine — reads the full diff, writes the tests themselves, checks for invented APIs or license problems — plus one real catch, like a hallucinated library or a silent behavior change.

3. What work do you deliberately keep away from AI tools, and why those things in particular?

   Why ask it: The refusal line reveals their model of where AI output can't be trusted yet and where accountability can't be delegated.

   Listen for: Named categories with reasons — security-sensitive code, data migrations, anything they couldn't debug unaided — not the empty extremes of "I verify everything" or "nothing, it's all reviewable".

• Every story is "we": after two follow-ups you still can't name one thing the candidate personally designed, built, or fixed.
• No numbers survive contact: they claim scale or leadership but can't say how many users, requests, services, or engineers were involved.
• Every incident and bug ends with someone else at fault — QA, legacy code, vague requirements — and they can't name one test, check, or habit they changed afterward.
• Past decisions have no tradeoffs: every choice they made was "best practice" and they can't fairly state the case for the option they rejected.
• Their AI answers are slogans in either direction — "10x faster" or "I never trust it" — with no concrete example of a catch, a saved afternoon, or a task they refuse to delegate.

Skip anything about age, family plans, health, religion, nationality or other protected characteristics — those questions create legal risk and tell you nothing about the work. Hiring-interview rules vary by country and state, so check the ones that apply to you.

Asking a sharp question only pays off if you catch the whole answer. incogno transcribes the candidate's answers live on your Mac or Windows PC — no bot joins the call — and lets you ask things like "what did they say about the migration?" mid-interview, with your job description and scorecard loaded as context. See the AI interview assistant for interviewers.