Questions to Ask Hiring Manager Software Engineer
Questions to put to the hiring manager when you are interviewing as a software engineer. They cover how code reaches production, review and CI, on-call load, how architecture decisions get made, promotion, and why people have left the team.
The questions
Open any question for the note
What would I be working on in my first month?
Why ask it
A vague answer usually means there is no onboarding plan and you will spend three weeks looking for someone to ask. A named first project, or a first ticket with a partner attached, is a good sign.
What does the stack look like, and which parts are you unhappy with?
Why ask it
The second half is the real question. Every engineer has a component they dislike, and whether they will name it to a candidate tells you if this team discusses its problems or conceals them.
How does a one-line change get from my laptop to production?
Why ask it
Asking about one small change gets you review, CI, staging, deploy and rollback as a single story. Count the manual steps, because that number is how much of your week will be spent waiting.
How long does CI take, and how often is the main branch broken?
Why ask it
Two concrete numbers that predict daily frustration better than any description of engineering culture. A forty-minute suite plus a frequently red trunk means slow, cautious, low-throughput work.
Do engineers here trust the test suite?
Why ask it
Coverage percentages are close to meaningless on their own. What matters is whether people believe a green build, because a suite nobody trusts gets skipped and then everything is verified by hand.
Who reviews my code, and how long does a review usually sit?
Why ask it
Review latency shapes what working here feels like. Two-day reviews mean you keep several branches in flight and lose track of them, and if one person reviews everything, that person is the bottleneck.
How was your last significant architecture decision made?
Why ask it
Ask for a specific one and follow the story: who wrote it up, who objected, how it was settled. That reveals whether design happens in documents, in meetings, or in whoever's pull request merges first.
How does on-call work, and how many times were you paged last month?
Why ask it
The page count is the honest measure of system health. Also ask whether on-call is compensated and whether the team gets time to fix what woke them, since that determines if the number ever improves.
How many hours a week does an engineer spend in meetings?
Why ask it
Add up the recurring ones before you accept anything. Four hours a week is ordinary; fifteen means the role is coordination with some programming attached, whatever the title says.
What is the oldest part of the system, and what makes it hard to change?
Why ask it
Every system has one, and how they describe it matters. Engineers who can explain why the old code is the way it is, without contempt for whoever wrote it, tend to be good colleagues.
How does work get chosen, and can an engineer push back on something?
Why ask it
This exposes actual autonomy. A team where work only ever arrives as fully specified tickets is a different place to spend your years than one where engineers pick up problems and scope them.
How do you decide when to pay down technical debt?
Why ask it
Look for a mechanism rather than a sentiment: a share of each cycle, a rotating maintenance slot, a rule about fixing what you touch. Without a mechanism, debt never gets paid whatever anyone intends.
What happens after an outage?
Why ask it
You are asking about blame. A team that runs blameless reviews with written follow-up actions behaves very differently under pressure from one where an incident concludes with a named individual.
When do engineers first hear about a new feature?
Why ask it
Early involvement means technical constraints shape the product. Late involvement means you will be told what has already been promised to a customer, which is a different job with the same title.
Who has left this team in the last year, and why?
Why ask it
Attrition is the strongest available signal about a team, and one of the few things a manager will answer plainly if asked plainly. Note whether they actually know why each person went.
What separates a mid-level engineer from a senior one here?
Why ask it
The gap between levels is where promotion arguments get won or lost. A manager who describes it concretely has made that argument for someone before; one who cannot has probably never tried.
How does promotion work, and who decides?
Why ask it
Ask about the process and the calendar: how often it runs, who writes the case, whether there is a quota. Vagueness here is the most reliable predictor of staying at your current level for years.
What's the hardest problem the team has solved recently, and who drove it?
Why ask it
The second half matters more. If the answer is always the same one or two names, you are learning where the interesting work goes, and it may never be routed to you.
What would make you regret hiring me six months from now?
Why ask it
Sharper than asking about expectations, because it puts the failure mode in the open. What comes back is usually the unvoiced concern about your background that nobody has raised yet.
What's the biggest problem on this team you haven't solved?
Why ask it
Managers tend to answer this one honestly, and it tells you what you would actually be walking into: an understaffed area, a rewrite nobody wants to own, a stakeholder who cannot be satisfied.
Interviewing the team, not just the job
Practical guidance for the conversation itself
Ask for stories, not policies
Every process question has a story version
Rather than asking whether they do code review, ask how long the last review sat. Rather than asking about incident process, ask what happened after the most recent outage. Policy answers were written by someone in recruiting; stories were not.
Ask the same question twice, to two people
Put how decisions get made to an engineer and to the manager, then compare. The gap between those two answers is usually the most useful thing you learn all day.
Notice what they are willing to complain about
Some complaint is healthy and means you are being spoken to like a future colleague. A team that reports no problems at all is either three months old or not being candid with you.
Numbers to leave with
- CI duration, and how often the main branch is red.
- Time from merge to production.
- Pages per on-call shift last month, and whether on-call is paid.
- Recurring meeting hours per week.
- How many engineers left this team in the last year.
What to avoid
- Do not open on compensation with the hiring manager. Ask the recruiter, who controls the number anyway.
- Do not ask what the job posting already answers; it spends time you do not have much of.
- Do not critique their architecture in the interview, even when invited to. Ask why it ended up that way instead.
- Do not accept a description of culture without an example. Ask what happened the last time two engineers disagreed about a design.