Questions to Ask Software Engineer Interview
Questions to ask as the candidate in a software engineering interview, covering deploy speed, code review, on-call load, how technical decisions get made, and how promotions actually happen, with notes on what an evasive answer usually means.
The questions
Open any question for the note
What did the last person in this role do, and where are they now?
Why ask it
A backfill after a promotion is a different job from a backfill after someone quit inside four months. If nobody in the loop can say which happened, either they were not told or the answer is one they would rather not give, and both belong in your notes.
What would I ship first, and roughly when?
Why ask it
Forces a concrete answer about scope. If nobody can name a first project, either the role exists to fill a headcount plan rather than a need, or you would be the one choosing, and both are worth knowing before you sign.
How long does a change take to get from my laptop to production?
Why ask it
One number that summarizes build times, review queues, environments and release approvals, which is why it tells you more than any list of tools they use. Ask for the usual case and for the last time it went badly, since teams quote their best week by default.
What broke most recently, and what happened afterwards?
Why ask it
You are asking for an incident story. Whether they describe a review with follow-up work assigned, or a person who got in trouble, tells you most of what you need to know about the culture.
How much of this codebase would you rewrite if you could?
Why ask it
Every engineer has an answer to this and most enjoy giving it. The size of the number matters less than whether any of the work has time allocated to it, so follow up on that.
Who reviews my code, and how long does a review usually sit?
Why ask it
Review latency is where engineers lose whole days. If reviews commonly sit for a day or more, ask what people do while blocked, because the answer describes your future working week.
How long does CI take, and what does the test suite actually cover?
Why ask it
Ask for the pipeline duration in minutes before asking about coverage. A slow pipeline changes daily behavior far more than a low coverage figure does, and everyone on the team knows the number.
How often does someone get paged, and who was paged last week?
Why ask it
Last week is much harder to smooth over than a general policy. Frequent pages with no compensating rest is a common reason engineers leave, and it almost never appears in a job description.
How much of a typical sprint goes on bugs and maintenance rather than new work?
Why ask it
Interrupt work is the gap between the job as advertised and the job as lived. Teams that measure it will give you a number; teams that do not will say it depends, which usually means most of the sprint.
Where do requirements come from, and can an engineer push back on one?
Why ask it
This tests whether engineers here exercise judgment or work through tickets. If nobody can remember a requirement being successfully challenged, the role is closer to delivery than to engineering.
How do technical decisions get settled when two engineers disagree?
Why ask it
Listen for a mechanism: a design document, a named decision maker, a tech lead who breaks ties. If the answer is that people talk it through, ask what happened the last time talking it through did not work.
What is the office and remote arrangement, and is it written down?
Why ask it
Written policy survives a change of management and informal understanding does not. Ask who decides, whether it has changed in the past year, and what happens when a new manager wants more days on site.
How did the last promotion on this team happen?
Why ask it
One real example beats the published career ladder. If nobody on the team has been promoted, ask why, because the answer is either a young team or a blocked one.
What evidence is used when performance is evaluated here?
Why ask it
Ask what the inputs are: peer feedback, a document you write, shipped projects, a manager's recollection. Vagueness means your review will depend on how well your manager argues for you in a room you are not in.
What do people get for being on call?
Why ask it
The specifics matter: a stipend, time off after a bad night, or nothing. Being told that on-call is usually quiet is not an answer to this question, and it is worth asking again.
How is this team's budget and headcount decided, and how far ahead is it funded?
Why ask it
Uncomfortable and entirely reasonable, especially at a startup where the honest version is a runway figure. At a large company the same question surfaces whether this team is growing or quietly being wound down.
What have you tried to fix on this team that did not work?
Why ask it
Failure is much harder to script than success. A manager who can describe an attempted fix that failed is one who notices problems, and the example itself points at the team's real weakness.
Who has left the team in the last year, and why?
Why ask it
Attrition is a fact rather than an opinion, so it is harder to spin. If several people left and the explanation is that they were not the right fit, that phrase is doing a lot of work.
What would make you regret hiring someone into this role?
Why ask it
Asks for the failure mode instead of the ideal candidate, and most interviewers answer it honestly because the answer is about them. It usually names the thing this team is least able to tolerate.
What are the remaining steps, and when should I expect to hear back?
Why ask it
Closes by pinning down the process: how many rounds are left, who is in them, and by what date. A refusal to give any timeline is common, but it belongs in your notes with everything else.
Using your questions well in an engineering interview
Practical guidance for the conversation itself
Match the question to who is in the room
- The hiring manager is the person for scope, on-call, promotions, and who left.
- Peer engineers will be far more candid about review latency, deploy pain, and technical debt than any manager.
- A recruiter can answer pay bands, process, and dates, and cannot answer anything technical, so do not spend that call on architecture.
- A director or skip-level is the right person for funding, roadmap, and where this team sits in the company.
Asking without sounding like an audit
- Pick three or four questions per conversation rather than working through a list. One answer followed properly beats ten collected.
- Attach each question to something they already said. It reads as attention rather than interrogation.
- Ask for the last time something happened instead of the general policy. Specific instances are hard to answer with a slogan.
- Leave pay and vacation with the recruiter unless the interviewer raises them, and then be direct rather than coy.
Reading the answers
- Note where two interviewers contradict each other and ask the next person about it. That gap is where the real information sits.
- Enthusiasm about the product is not evidence about the team. Ask the same team question to three people and compare.
- If a routine question produces visible discomfort, that is data. One gentle follow-up is fair; a second is not.
- Write your notes immediately after each round. By the fifth conversation the answers will have merged in your memory.
Signals worth taking seriously
- Nobody can describe what you would work on in your first month.
- Deploys are described as scary, or happen on a fixed monthly date for a product that lives on the web.
- There is nobody senior on the team, and the unstated plan is for you to be that person without the title or the pay.
- Every process question is answered with we are working on that, and no owner or date is attached to any of it.