How to Screen Software Engineers: 9 Questions and What to Listen For Screening Interview Template

Pick the system you know best from the last two years. What did it do, which part did you personally own, and what would you change about it if you started over?

What this assesses: Listen for the boundary between what the team shipped and what this person built. Strong answers narrow fast: they name the service, the traffic shape, the datastore, and the piece they held the pager for. Then they criticize their own design specifically, saying the schema should have been normalized differently or the queue should never have been synchronous. Weak answers stay in we, describe the product rather than the system, and have nothing they would change, which usually means they were adjacent to the work rather than in it.

Tell me about the worst production incident you were involved in. How did you find out something was wrong, and what did you do in the first fifteen minutes?

What this assesses: The detection half of this question is the more revealing half. Strong answers say an alert fired, or a dashboard was already open, or a synthetic check caught it before customers did. Then they stabilize before diagnosing: roll back the deploy, flip the flag off, drain the bad node, tell support what to say. Root cause comes after. Weak answers start with a customer email and then describe fifteen minutes of reading logs looking for the cause while the site stayed down. Someone who has never been on call will describe an incident they watched rather than one they handled, and it shows in the pronouns.

Walk me through what happens between you finishing a change and it running for users. Who reviews it, what runs automatically, how does it deploy, and how do you know it worked?

What this assesses: This one question tells you more about an engineer's real environment than any system design prompt. Strong answers walk the whole path with specifics: review expectations, what the CI suite actually covers versus what it claims to, staging or preview environments, how deploys roll out, and what they watch afterward, whether that is error rate, latency, or a business metric. Weak answers stop at I open a pull request and someone merges it. That is not disqualifying on its own, but it tells you the person has never owned the consequences of a change, and you should decide whether you can afford to teach that.

Describe a technical decision you made that turned out to be wrong. What did it cost, and how did you unwind it?

What this assesses: Look for a real decision with a real bill attached: a datastore chosen for the wrong access pattern, an abstraction built three months before it was needed, a vendor swap that ate a quarter, a migration run without a rollback path. Strong answers give the cost in weeks or dollars and describe the unwinding honestly, including the part that is still there. Weak answers pick a decision that turned out fine, or pick a decision someone else made. The polished non-answer here is that they once moved too fast and learned to slow down, which costs nothing to say.

What is in your stack today: languages, datastore, deployment. Where in it are you genuinely strong, and where would you need to ramp up on our stack?

What this assesses: Calibration matters more than coverage. Strong answers claim two or three things confidently, name the boundary of that knowledge, and are direct about gaps: comfortable in Postgres including query plans and index choices, has used Kafka but always with someone else owning the cluster, has never run anything on Kubernetes without a platform team. Weak answers list twelve technologies at the same level, or claim they pick things up quickly without naming what they would need to pick up. A candidate who cannot name a single gap either has not worked outside a narrow lane or is not telling you the truth.

Tell me about a time you had to work in code you did not write, with no documentation and nobody left who understood it. How did you get oriented?

What this assesses: Most engineering jobs are mostly this, and almost no interview asks about it. Strong answers describe a method: read the tests first, trace one real request end to end, add logging or a debugger and watch it run, use version history to find who touched it and why, change one small thing and see what breaks. They also say what they wrote down for the next person. Weak answers say they read through the codebase until they understood it, which is what people say when they have not actually had to do this under a deadline.

How do you decide whether to build something yourself or use an existing library or service? Give one example where you built and one where you bought.

What this assesses: Asking for both directions is the point, because most candidates have a reflex and this exposes it. Strong answers tie the decision to something concrete: how core it is to the product, how much of the library they would actually use, what the operational burden looks like at three in the morning, what the migration path off it is. Weak answers give a principle without an example, or produce two examples that both point the same way. Someone who has never chosen to buy will rebuild your auth layer, and someone who has never chosen to build will hand you fourteen vendors.

How do you use AI coding tools day to day, and tell me about a time you had to override what one gave you.

What this assesses: This is a judgment question, not a loyalty test. Strong answers are specific about where the tools help, usually boilerplate, tests, unfamiliar syntax, and first drafts, and then name a concrete override: an API that does not exist, a race condition in generated concurrency code, a query that worked on ten rows and collapsed on ten million, a security assumption that was quietly wrong. The signal is that they read the output and knew enough to catch it. Weak answers land at either extreme, refusing the tools on principle without a reason, or describing a workflow where generated code goes in without anyone understanding it.

What are you looking for in your next role, and what would make you turn this one down?

What this assesses: The second half is where the useful answer lives, because the first half is rehearsed. Strong answers name real constraints: compensation band, remote or hybrid expectations, on-call load, team size, whether the role is mostly maintenance, whether they will be the only person on a system. That is a candidate telling you where the offer will fall apart while it is still cheap to know. Weak answers say they are open to anything, which usually means either they have not thought about it or they have a constraint they are hiding until the offer stage.