Questions to Ask Interviewer Software Engineer
Questions for software engineering interviews, aimed at the things you cannot learn from the job posting: deploy frequency, on-call load, review turnaround, who decides what gets built, and how much of the week goes on maintenance.
The questions
Open any question for the note
What would I be working on in the first month?
Why ask it
An answer with a named service or ticket queue means someone planned for the hire. "We will see where you fit best" often means several weeks of reading code with no owner assigned to you.
How long does it take to get a small change from my laptop to production?
Why ask it
The single most informative question you can ask an engineering team. An hour is a completely different job from three weeks, and the answer tells you about testing, review, and release process at once.
How old is the codebase, and how many people touch it?
Why ask it
Age plus contributor count predicts how much of your time goes to coordination rather than code. A ten-year-old system with forty contributors means most of your work is negotiation.
What does on-call look like, and how often does it page overnight?
Why ask it
Ask for the number of pages in the last rotation, not the policy. An engineer who knows the figure is on a team that tracks it; one who laughs and says it varies has probably had a bad month.
How are code reviews done, and what is the usual turnaround?
Why ask it
Review latency sets the pace of everything else. A day or more means engineers keep several branches in flight, which is where most integration pain comes from.
What is the test suite like, and how long does CI take?
Why ask it
A slow or flaky suite is a daily tax you will pay from day one. Ask whether people trust the tests, which is a different question from whether tests exist.
How much of the team's time goes to new work versus maintenance?
Why ask it
Postings advertise the new work. If the honest split is thirty to seventy, you want to hear that now rather than discover it in your second sprint.
How does the team decide what to build?
Why ask it
You are looking for who holds the roadmap and how it changes. Frequent reprioritisation mid-sprint is the most common cause of engineers feeling their work is wasted.
Who writes the specs, and how much input do engineers have?
Why ask it
Teams where engineers see requirements only as finished tickets build the wrong thing more often, and there is no route to say so before the work starts.
What is the most frustrating part of the current system?
Why ask it
Every engineer has an answer, and it is usually delivered with feeling. A refusal to name anything is less reassuring than a candid complaint.
How does the team settle a disagreement about architecture?
Why ask it
Look for a mechanism: a design document, a review forum, a named decision maker. Teams that settle it by seniority or by whoever writes the code first will show it in the codebase.
How does work on technical debt get funded, and who approves it?
Why ask it
Everyone says debt matters. The distinguishing detail is whether there is allocated time or a mechanism to raise it, or whether it happens only when something breaks.
How do new engineers get up to speed here?
Why ask it
Documentation, pairing, a starter project, or nothing. The answer predicts how long you will feel unproductive, which is also how long you will feel uneasy.
How is engineering performance assessed?
Why ask it
Ask what evidence is used. Systems built on peer review, shipped work, or written self-assessment behave very differently from ones based on a manager's impression.
What does the level above this one require?
Why ask it
A team that can describe the next level in behaviours rather than years has a working ladder. Vagueness here usually means promotion depends on your manager's advocacy alone.
How do engineering, product, and design work together week to week?
Why ask it
The number of handoffs and meetings is what determines how much uninterrupted time you get. Ask about the standing meetings by name.
What is expected in terms of hours and availability outside work?
Why ask it
Separate the on-call answer from the ordinary-week answer. Occasional launch pressure is normal; an expectation of evening responsiveness without a rotation is not.
How many engineers have left this team in the last year, and where did they go?
Why ask it
The second half softens the question and produces better information. Departures to bigger roles read very differently from a cluster of exits within a couple of months.
What did the last significant incident look like, and what changed afterwards?
Why ask it
The response tells you whether the team runs blameless reviews and follows through on actions, or whether incidents are absorbed and forgotten.
What would make you say a new hire had done well after six months?
Why ask it
Concrete answers, such as shipped a feature end to end, took an on-call shift, or improved something nobody asked them to, tell you what is rewarded here. Abstract answers tell you nothing is measured.
Interviewing the engineering team back
Practical guidance for the conversation itself
Match the question to who is in the room
Ask engineers about the code
Deploy time, review turnaround, CI duration, on-call pages, and the worst part of the system. These are answered honestly by peers and vaguely by anyone further from the keyboard.
Ask the manager about the work
Roadmap ownership, the new-versus-maintenance split, how debt gets funded, and what the next level requires. These sit with the manager, and their precision tells you how the team is run.
Ask the recruiter about the process
Band, level, stages, and timelines. Using an engineer's time on compensation questions wastes the one slot where you could have learned about the codebase.
Answers worth weighting heavily
- Deploy frequency and lead time. Teams that ship daily have solved a lot of problems that slower teams still have.
- Whether anyone can state on-call page volume from memory.
- Whether engineers are named in the roadmap process or only receive its output.
- A specific, unflattering complaint about the current system. Candour here usually correlates with candour elsewhere.
- Whether the last incident produced changes that actually shipped.
Common pitfalls
Asking about the stack and stopping there
The list of languages is usually in the posting. How changes get reviewed, tested, and released tells you far more about what the job feels like.
Accepting "we care about quality"
Follow up with a mechanism question: how much time was spent on debt last quarter, and who approved it. The absence of a mechanism is the answer.
Skipping the on-call question to seem keen
It is a normal question and interviewers expect it. Finding out after you accept is how people end up in rotations they would have declined.