Questions to Ask a Hiring Manager as a Software Engineer
Questions to ask a hiring manager when you are interviewing as a software engineer. This is usually the person who would hand you your work and write your review, so the list goes past the stack. It runs in six groups: the role and the team, the codebase, how code ships and who gets paged, how work is planned, how this person manages and promotes, and a few to close on.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Role
What would I be working on in my first month?
Why ask it
A named first project, or a starter ticket with a teammate attached, tells you someone has thought about your arrival. If the answer is vague, ask who plans a new engineer's first weeks, because the honest answer may be that nobody does yet.
What would a successful first 90 days look like for the engineer you hire?
Why ask it
The manager decides whether you have settled in, so this is their scorecard handed over in advance. Good answers are things you could point at: a feature shipped, a service you can deploy alone, a first on-call shift. If all you hear is 'ramped up', ask what the last hire had merged by week twelve.
Why are you hiring for this role now: did an engineer leave, or is the team growing?
Why ask it
A departure hands you someone's half-finished work and their place in the on-call rotation. New headcount means the manager argued for the seat, so ask what they promised it would deliver. Either answer is fine; the one to worry about is a manager who is not sure.
What does the stack look like, and which parts are you unhappy with?
Why ask it
You could get most of the languages and frameworks from the posting. The useful part is the piece they would replace given a free quarter: a manager who names one readily is showing you that problems get talked about in the open on this team.
What's the biggest problem on this team you haven't solved?
Why ask it
Whatever they name is what you would be walking into: an understaffed area, a rewrite nobody wants to own, a stakeholder who cannot be satisfied. Ask how long it has been the biggest problem, since a year-old answer and a month-old one describe different teams.
Who is on the team right now, and how experienced are they?
Why ask it
Get the headcount and the levels. One senior and five juniors means the same person reviews everything you write, or that you would be doing the mentoring yourself. Ask too whether anyone is a contractor or on loan from another team, since their knowledge may not stay.
Who has left this team in the last year, and why?
Why ask it
Ask it plainly and without apology; it is a normal thing to want to know. Notice whether the manager knows each person's reason or files them all under 'new opportunities'. If a layoff or a reorganization is part of the answer, ask what changed for the people who stayed.
What did last week look like for one of your engineers?
Why ask it
Last week is harder to idealize than a typical week. You want the shape of it: how many days of uninterrupted building, how much support work, what got dropped. If the manager cannot reconstruct it, they may be a long way from the team's daily work.
What is the split between building new things and keeping existing ones running?
Why ask it
Neither kind of work is the lesser one, but they suit different people and the posting rarely says which this is. If the manager offers a rough share, ask whether it is spread evenly or whether the newest hire gets the support queue.
Is the team remote, hybrid or in the office, and do you expect that to change?
Why ask it
The written rule and the manager's own habits can differ, so ask which days they come in and where the rest of the team sits. Location rules do get rewritten. If the arrangement matters to you, ask whether it would be stated in the offer.
What did the last engineer you hired find hardest about the first few months?
Why ask it
It is an onboarding question that cannot be answered by reciting the onboarding plan. Undocumented systems, slow access requests and a business domain that takes a year to learn are all common answers, and each one tells you what to ask for in your first week.
Codebase
Which of the technologies in the posting would I use every week?
Why ask it
Postings tend to collect every tool a team has touched. Sorting them into daily, occasional and legacy tells you what to study before you start, and it is the natural moment to say which ones you have not used on a real project.
What is the oldest part of the system, and what makes it hard to change?
Why ask it
Listen to the tone as much as the content. A manager who can explain why the old code is the way it is, without contempt for whoever wrote it, will probably talk about your code the same way in three years.
Do engineers here trust the test suite?
Why ask it
Coverage percentages say little 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.
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. Then ask what was last cleaned up under it, because a mechanism that has produced nothing lately is only a sentiment with a name.
How long does it take a new engineer to get the system running on their own machine?
Why ask it
An afternoon means somebody maintains the setup script. A week of chasing credentials and stale wiki pages shows how the team treats its own tooling, and fixing it is often the first job a new hire is quietly expected to take on.
Which part of the codebase would be in trouble if one particular engineer left?
Why ask it
Plenty of teams have a billing module or a build system that only one person dares touch. What you are listening for is whether the manager treats it as a risk with a plan attached, and whether you are being hired to become the second person.
What is the team migrating away from, and how far along is it?
Why ask it
If a migration is two-thirds done after two years, you would be working in the old system and the new one for the foreseeable future. Ask what is blocking the last third and whose name is on finishing it.
If usage doubled next quarter, what would break first?
Why ask it
Someone who knows the system answers quickly: the database, a nightly batch job, one overloaded queue. You also learn whether scale is a live concern here or a hypothetical, which changes how much performance work the job really involves.
Where do you stand on AI coding tools, and how much does the team use them?
Why ask it
Rules run from a ban to a mandate and differ by employer, sometimes by client contract, so ask how it works here. Worth a follow-up: whether generated code is reviewed any differently, and whether the manager's view and the team's daily habit are the same thing.
Shipping
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 each one is a place where your work would sit waiting.
How long does CI take, and how often is the main branch broken?
Why ask it
These are two numbers the manager either knows or has to guess, and the guessing is informative too. A forty-minute run and a main branch that is red most weeks add up to slow, cautious work, whatever else the team says about its culture.
Who reviews my code, and how long does a review usually sit?
Why ask it
When reviews take two days you end up with several branches in flight at once. If one person reviews everything, ask what happens to the queue when that person is on holiday.
How many times did the team ship to production last week?
Why ask it
A count from last week is harder to round up than 'we deploy continuously'. What is normal depends on the product, since a web service and embedded firmware live on different calendars, so follow up with what stops the number being higher.
How do you release a risky change: behind a flag, to a small slice of users, or to everyone at once?
Why ask it
Flags and gradual rollouts mean a mistake reaches a few users and gets switched off. Releasing to everyone makes each deploy a small bet, and teams that work that way tend to batch their changes and save them for quiet hours.
When a bug reaches customers, who hears about it first and who fixes it?
Why ask it
Follow the path from the support inbox to an engineer's screen. If bugs go back to whoever wrote the code, expect interruptions along with real ownership. If a rotation or a separate team takes them, ask how the original author ever learns what went wrong.
How does on-call work, and how many pages did the rotation get last month?
Why ask it
A page count is harder to dress up than 'the rotation is pretty quiet'. Whether on-call is paid or given back as time off differs by employer and by country, so ask how it works here, and ask whether the team gets time to fix whatever woke them.
How long does a new engineer get before carrying the pager alone?
Why ask it
A shadow shift or two, a written runbook and a named person to escalate to is a reasonable minimum. Going on the rotation in week three with none of those suggests the rotation is short of people, which is worth knowing before you become one of them.
What happens after an outage?
Why ask it
You are really asking about blame. Have them walk through the most recent one: who wrote it up, whether the write-up named a person or a cause, and whether the follow-up work was ever scheduled.
Planning
How does work get chosen, and can an engineer push back on it?
Why ask it
This is the autonomy question. Where work only ever arrives as fully specified tickets, the job is a different one from a team where engineers pick up a problem and scope it themselves. Ask for the last time someone pushed back and what happened to the ticket.
Does the team work in sprints, and what happens in a normal one?
Why ask it
Sprints, kanban or no named method at all can each work, so listen for the calendar that comes with it: how long a cycle is, which ceremonies are fixed, and who can add work once a cycle has started. That last one decides whether the plan means anything.
When do engineers first hear about a new feature?
Why ask it
If engineers are in the room early, technical constraints get to shape the product. If they hear late, you would be told what has already been promised to a customer, which is a different job with the same title.
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.
Where do estimates come from, and what happens when one turns out to be wrong?
Why ask it
Estimates made by the people doing the work behave differently from dates handed down by sales or leadership. A missed one can lead to a revised plan, a cut in scope or a few late weeks, and which of those is normal here is worth knowing before you give your first estimate.
When did the team last work evenings or a weekend to hit a date?
Why ask it
'Never' deserves a gentle follow-up, and so does 'all the time'. You are sizing up frequency and cause: one launch a year is different from a standing habit that comes from dates promised without asking engineering. Ask whether people got the time back.
What is the team expected to deliver in the next six months, and how settled is that?
Why ask it
This is the work you would be doing, so hold it up against what drew you to the role. A plan that has changed twice this quarter is not disqualifying, but ask what changed it, because that person or pressure would be setting your priorities too.
How do you and the product manager settle it when you disagree?
Why ask it
The hiring manager is usually the one arguing for engineering time, so the answer shows how much weight that argument carries. Ask for the last disagreement and who gave way. If the team has no product manager, find out who writes the requirements.
How much of what the team plans usually gets pushed out by unplanned work?
Why ask it
Urgent requests, production issues and other teams' deadlines all eat into a plan. A manager who can put a rough share on it has been watching. An answer of almost none comes from a very calm team or from nobody counting.
How many hours a week does an engineer spend in meetings?
Why ask it
Ask for the recurring ones by name and add them up yourself, since 'not many' means different things to a manager and to an engineer. Then ask whether the team protects any block of the day or week. The total matters less than whether the hours between meetings are long enough to build anything.
What do you look at to judge whether the team is doing well?
Why ask it
What shipped and whether it worked, incident trends, and what engineers say in one-to-ones are all defensible answers. Be wary of ticket counts, story points or lines of code applied to individuals, because whatever gets counted is what people start producing.
Manager
How would the engineers who report to you describe the way you manage?
Why ask it
Asking for the engineers' view makes a rehearsed line about being hands-off harder to give. Listen for a concrete habit, such as reading every design document or staying out of standup, then compare it with what an engineer says if you get to meet one.
How many people report to you, and is that number about to change?
Why ask it
A manager with twelve engineers has less time for each than one with five, and one-to-ones are often what slips. Ask as well whether a team lead is being hired underneath them, because you could end up reporting to someone you never interviewed with.
How close are you to the code these days?
Why ask it
There is no correct answer, only a fit. A manager who still reviews pull requests can judge your work first-hand but may also want to redo it. One who has not opened the repository in a year relies on what others say about you, so ask who those others are.
How often do you hold one-to-ones, and what are they for?
Why ask it
If they are status updates, the manager may have no other way of knowing what you are doing. Better answers involve obstacles, feedback in both directions and where you want to go next. How often they get cancelled says more than how often they are scheduled.
If my work were falling short, how and when would I find out?
Why ask it
You are checking that bad news arrives early and in private, well before it shows up in a written review. Ask about a time they told someone their work was off course and what that person did next. A manager with no example has been lucky or avoids the conversation.
How is an engineer's performance reviewed here, and what evidence goes into it?
Why ask it
Find out whether the manager writes the review alone or has to defend it in front of other managers, because in the second case work that people outside the team can see counts for more. Then ask what a strong engineer on the team was credited with last cycle.
What does your strongest engineer do that the others don't?
Why ask it
The answer is the manager's working definition of good, which may not match the written career ladder. If it is all speed and volume, that is what gets rewarded here. If it is unblocking other people or writing things down, you have learned what to make visible in your first months.
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 a committee outside the team has the final say. The most useful follow-up is when someone on this team was last promoted and how long that person had been waiting.
Is there a staff or principal track here, and is anyone on your team on it?
Why ask it
Plenty of companies describe a senior technical path that nobody has walked. A named person at that level who still writes code or designs is evidence it exists. If the only way past senior has been to take over a team, better to hear it now than at your third review.
What's the hardest problem the team has solved recently, and who drove it?
Why ask it
The problem tells you what counts as hard here. The name tells you more: if the manager's stories keep starring the same one or two people, ask how the next interesting piece of work will be handed out.
What has someone on your team learned on company time this year?
Why ask it
Budgets for courses and conferences are easy to list and often go unspent. An example, such as an engineer who took two weeks to learn the data pipeline or went to a conference and reported back, shows whether learning fits into the schedule at all.
Why did you join this company, and is that reason still true?
Why ask it
The joining story is usually well practiced; whether it still holds is not. A pause followed by a different, current reason is a straight answer, and whatever they name is probably the best thing about working there now.
Closing
What level are you hiring this role at, and is there room to move it?
Why ask it
Level sets the scope you are handed and the bar the remaining interviewers hold you to, and where pay is banded it sets the range as well. Companies define their levels differently, so ask how it works here and who makes the call: the manager, a committee or the recruiter.
What would make you regret hiring me six months from now?
Why ask it
It puts the failure mode on the table, and what comes back is often the doubt about your background that nobody has voiced yet. Answer it then and there if you can. Leave it out of a first screening call, where it can sound like a dare.
Before I decide on an offer, could I talk to one of your engineers without you in the room?
Why ask it
A team with nothing to hide usually makes this easy. Use the conversation to repeat two or three questions from this list and compare the answers. Reluctance proves nothing by itself, but it is fair to ask what the concern is.
What are the next steps, and how much of the decision is yours?
Why ask it
Some hiring managers choose alone, and others take a recommendation to a committee or need sign-off on level and pay. Knowing which tells you whose doubts still need answering and how long a silence should run before you follow up.
What should an engineer joining your team know that I have not asked about?
Why ask it
Keep it for the last minute or two. It gives the manager an opening to raise something they were unsure whether to mention, such as a reorganization, a lead who is leaving or a product bet that may not last. If they say there is nothing, take it and thank them for the time.
How to use these questions with a hiring manager
Practical guidance for the conversation itself
Choosing from a long list
Ten minutes at the end of an interview
Pick three: one from Role, one from Codebase or Shipping, and one from Manager. Lead with the one whose answer could end your interest in the job, because the last question on your list is the one that gets cut off.
A full round with the hiring manager
With half an hour or more, spend it on what only this person can answer: Role, Planning and Manager. Detail about CI, reviews and the pager is often better asked of the engineers on the panel, and then checked once against the manager's version.
After the offer
The blunt ones, such as who has left, the last weekend the team worked and how promotion is decided, land more easily once they have decided they want you. That is also the time to ask for a conversation with an engineer on the team.
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. A policy can be recited from memory; a story has to have happened.
Ask the same question twice, to two people
Put how decisions get made to an engineer and to the manager, then compare. Where the two answers differ is often 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 very new 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, and how many deploys went out last week.
- Pages the on-call rotation took last month, and whether on-call is paid or given back as time off.
- Recurring meeting hours per week.
- How many engineers report to the manager.
- How many engineers left this team in the last year.
What to avoid
- Do not open on compensation with the hiring manager. Where there is a recruiter, the number usually sits with them; at the offer stage, ask which parts of it the manager can influence.
- Do not ask what the job posting already answers; it spends time you do not have much of.
- Do not volunteer a critique of their architecture. Ask why it ended up that way instead, and save your opinion for when you know the constraints.
- Do not accept a description of culture without an example. Ask what happened the last time two engineers disagreed about a design.