Software Engineer interview questions.

What a good answer looks like: Clear I-vs-we separation ("the team built the platform; I owned the ingestion pipeline"), the user-visible outcome, and unprompted specifics — stack, scale, the gnarliest part. This answer seeds the whole interview: strong candidates give you three threads to pull; padded CVs produce answers that stay at press-release altitude.

Red flags: Can't isolate their own contribution; describes the project only in "we" terms; no numbers or concrete details anywhere.

What a good answer looks like: A real fork in the road with the rejected option steelmanned: what they chose, what it cost, and under what conditions the other choice would have been right. Engineers who remember the road not taken were actually at the wheel; those who only remember the destination were passengers.

Follow-up to ask: Knowing what you know now, would you make the same call?

What a good answer looks like: A current, honest workflow: which AI tools they use (or deliberately don't), what they delegate (boilerplate, tests, unfamiliar APIs) versus what they always verify (security-sensitive code, data migrations, anything they couldn't explain in review). The red line should be "never merge what I can't explain" in some form.

Red flags: Either pole — "AI writes most of my code and it's fine" with no verification story, or performative refusal to use any tooling paired with slow output.

What a good answer looks like: Specific wants that this job can be checked against (ownership breadth, product stage, stack, team size) and evidence they read about the company for five minutes. Mercenary honesty is fine; the signal is whether their wants and your reality actually intersect — mismatches found here save everyone a loop.

What a good answer looks like: Real incident texture: the alert or customer report, the wrong first hypothesis, the diagnostic steps, the fix, and the follow-through (postmortem, alarms added, the class of bug eliminated). Owning their own confusion during the incident is a strength signal, not a weakness — that's what debugging under pressure actually feels like.

Red flags: Has never been near a production issue despite years of claimed experience; story ends at "we restarted it" with no root cause or prevention.

Follow-up to ask: What monitoring or guardrail exists today because of that incident?

What a good answer looks like: A disagreement conducted with evidence (prototype, benchmark, written doc) and a clean ending either way — including "I was overruled, committed to their approach, and here's what happened." Disagree-and-commit told honestly is a senior signal; so is admitting the time they were simply wrong.

What a good answer looks like: Early transparency as reflex: they raised it the day the estimate broke, came with options (cut scope, ship the risky half behind a flag, move the date), and renegotiated rather than going quiet and hoping. The going-quiet pattern is the single most expensive engineer failure mode — this question smokes it out.

What a good answer looks like: Self-awareness with context: what the mess was, the pressure that produced it (deadline, ignorance at the time), its consequences, and whether they went back for it. Engineers who can laugh at their old code while explaining the constraint that produced it tend to write honest code review comments too.

What a good answer looks like: Stabilize-then-improve sequencing: read the code and trace one request end to end, get it running locally, add the smallest safety net first (a smoke test, a staging deploy, backups verified), and only then refactor. Grade restraint — candidates who start with "rewrite it" fail the question; production archaeology is the job.

Follow-up to ask: The business needs a feature shipped in that same two weeks. How does your plan change?

What a good answer looks like: Quantify, don't posture: make the risk concrete (which users, what corruption, what recovery costs), offer a safer variant or a guardrail, and escalate honestly if overruled on real data risk. The answer should show they treat "flag bad requirements" as part of the role — while staying a partner, not a blocker.

What a good answer looks like: Review craft: separate must-fix from preference, move from the PR comments to a synchronous conversation, anchor on shared goals ("when we add X next quarter, this couples us to Y"), and know when to concede or escalate to a design discussion. Empathy plus a spine — either alone fails the question.

What a good answer looks like: A coherent tour they can zoom on: boxes and arrows out loud, why each major choice (queue here, cache there), real numbers where they exist, and an honest nastiest-failure-mode with its mitigation. Depth test: pick any component and ask "why not the alternative?" — genuine builders answer instantly with trade-offs.

Follow-up to ask: If traffic grew 10x next month, what breaks first?

What a good answer looks like: A risk-based philosophy made concrete: what they covered (core logic, the scary edge cases, a happy-path integration test), what they consciously skipped, and how CI enforced it. Grade honesty about the gap between espoused philosophy and what last week's PR actually contained — thoughtful imperfection beats recited dogma.

What a good answer looks like: Real register-switching: the engineer version has precise mechanism; the customer version drops jargon, leads with what it means for them, and survives a "so what?" follow-up. Engineers who can only do one register cost you in incident comms, PR descriptions, and cross-team work.

What a good answer looks like: A genuine reversal with a mechanism: what they believed, the evidence or experience that broke it, and the nuance of the new position (usually "it depends, and here's the boundary"). Candidates with no revised opinions either aren't paying attention or aren't being honest — both matter in a fast-moving stack.

What a good answer looks like: A concrete verification ritual: read the generated code line by line, check it against official docs, write or run a test that would fail if the AI hallucinated, and treat security-sensitive or data-mutating code as always-verify. The principle you're listening for: speed from AI, accountability stays with the engineer.