Engineering Manager Interview Questions and Scorecard
36 interviewer questions across six competencies, each with why it is worth asking and what a strong answer sounds like, plus a seven-area scorecard and a red-flag checklist. Built for small businesses hiring without an HR department. Download as DOCX.
The first time I sat across from an engineering manager candidate, I asked mostly technical questions, because that felt like the safe ground. It was the wrong loop. The technical answers all sounded fine, and the thing that actually decided how the hire went was something I barely asked about: whether this person could tell an engineer something they did not want to hear.
An engineering manager is judged on a team, not on a commit history. So the interview has to test judgment under pressure, honesty about failure, and the willingness to have a hard conversation early instead of late. Those are all askable, as long as you decide what you are asking before the candidate walks in.
At FirstHR, we build for small businesses that hire without an HR department, where the founder often runs the whole loop personally. This page gives you 36 employer-side questions across six competencies, each with a stated reason it is worth asking and a note on what a strong answer sounds like, plus a seven-area scorecard and a red-flag checklist you can download.
TL;DR
Interview an engineering manager on six things: technical credibility, people leadership, delivery and estimation, hard conversations, hiring and onboarding, and communication with non-engineers. The highest-signal questions are a technical tradeoff they personally accepted, what they do the hour a date slips, and a full account of a time they managed someone out. Ask the same core questions of every candidate and score all seven areas from 1 to 5 before anyone debates. Download 36 questions and the scorecard as DOCX.
What to Assess in an Engineering Manager
Assess an engineering manager on whether they can make the team better, not on whether they are the best engineer in the room. The role produces its results through other people: a manager who ships everything personally has failed at the job even when the roadmap moves, because the team learned nothing and now depends on one person.
That means the interview weights differently from an engineering interview. Technical credibility still matters, because senior engineers stop listening to a manager who cannot judge a plan, but it is one competency out of six rather than the whole loop. The competencies that decide whether the hire works are the ones about people and predictability.
The most reliable way to test them is a structured interview, where every candidate answers the same questions scored on the same rubric. That matters more here than for almost any other role, because a candidate who interviews brilliantly and manages badly is common, and an unstructured conversation rewards exactly the traits that make them look good.
Tech Lead or Engineering Manager?
Decide which problem you are solving before you interview anyone, because a tech lead and an engineering manager fix different things. A tech lead owns technical direction and still writes code. A manager owns the people: hiring, one-on-ones, growth, performance, and the delivery commitment you can actually plan around.
Combining the two works up to roughly five or six engineers and then stops working, because the people side expands until either it or the technical side gets squeezed out. If your pain is architectural drift, hire or promote a lead. If the pain is that nobody handles underperformance and nobody can tell you when anything ships, you need a manager. The engineering manager job description templates cover the same split on the posting side.
Question
Points to a tech lead
Points to an engineering manager
What hurts most today?
Architecture, quality, technical direction
Delivery dates, growth, unresolved people issues
Team size
Two to five engineers
Five or more, or growing past five this year
Who runs one-on-ones now?
The founder, and it is working
Nobody, or the founder has stopped having time
Hiring plans
One hire this year at most
Several hires, or an unfilled bar for the team
Coding expectation
Still a primary contributor
Reviews and unblocks, rarely on the critical path
A Third Option: The Player Coach
Between the two sits a player coach who manages three or four engineers and still ships. It is the right answer for many small teams, and it is also the hardest role to fill, because the two halves compete for the same hours. If you go this way, say so explicitly in the interview and ask the candidate how they would split the week, then ask what they would drop first when a deadline pressures both halves. A candidate who says the management half is what gets dropped has told you something useful.
The Six Question Sets
The 36 questions below are grouped into five competencies plus a scorecard. Each set targets a different part of the role, and a strong candidate should hold up across all of them rather than only on the leadership questions they have rehearsed most.
Technical Credibility
Can they judge the work?
Whether the candidate can reason about tradeoffs, review a plan, and hold a line with senior engineers without becoming the bottleneck.
People Leadership and Growth
Will the team get stronger?
One-on-ones, career paths, and evidence they have actually developed engineers rather than inherited strong ones.
Delivery and Estimation
Can you predict anything?
Estimation under uncertainty, what they do the moment a date slips, and which numbers they watch to read team health.
Hard Conversations
Will they do the hard part?
Underperformance, conflict between engineers, and burnout. This is the work you are delegating when you hire a manager.
Hiring and Onboarding
Can they build the team?
How they decide what to hire next, how they design an interview loop, and how fast a new engineer ships something real.
Scorecard and Red Flags
Score, do not guess
A seven-area rubric with a red-flag checklist, so the decision rests on written evidence instead of the strongest impression.
Do Not Skip the Uncomfortable Set
Most interviewers spend the hour on leadership philosophy and technical background, because both are pleasant conversations. The set that separates a real manager from a senior engineer with a title is the one on underperformance, conflict, and burnout, and it is the set candidates are least prepared for. Ask at least three of those six questions of every candidate, and treat a long pause before an honest answer as a better signal than a fluent answer that avoids the specifics.
36 Questions and a Scorecard to Download
Download all six as a single Word document, or copy the sets you need. Each set lists when to use it, the questions with a stated reason for asking and notes on strong and weak answers, and space for notes. The last file is the scorecard and red-flag checklist.
Download All 6 Question Sets and the Scorecard
Five question sets by competency plus a seven-area scoring rubric with a red-flag checklist. All in one DOCX.
Set 1: Technical Credibility and Judgment
Whether the candidate can reason about a tradeoff, review a plan, and hold a technical line without becoming the bottleneck on their own team.
Technical Credibility and Judgment Questions
ENGINEERING MANAGER INTERVIEW: TECHNICAL CREDIBILITY AND JUDGMENT
Candidate: __
Interviewer: __
Date: __
WHEN TO USE THIS SET
Use this set for every engineering manager candidate. The goal is not to test
whether they can still out-code your senior engineer. It is to find out whether
they can judge a plan, review a decision, and hold a technical line with the
team. Ask two or three of these even if the rest of your loop is people focused.
QUESTIONS, WHY THEY MATTER, AND WHAT A GOOD ANSWER SOUNDS LIKE
1. Walk me through a technical decision you personally made in the last year
and the tradeoff you accepted.
Why ask it: A manager who cannot name a tradeoff cannot evaluate one, which
means every plan the team brings will get approved on confidence alone.
Strong answer: Names the constraint (deadline, cost, headcount, reliability),
the option they rejected and why, and what they knowingly gave up.
Weak answer: Describes what the team built, with no decision, no alternative
considered, and no cost acknowledged.
2. How do you stay close enough to the work to make good calls without becoming
a bottleneck?
Why ask it: There are two opposite failure modes here, and both are common:
the manager who drifts so far from the work they cannot judge it, and the one
who cannot let go and becomes the constraint on their own team.
Strong answer: A concrete habit. Reading pull requests, sitting in design
reviews, taking small non-critical tasks, pairing occasionally, and an
explicit rule that they never own critical-path work.
Weak answer: Either "I still write most of the code" or "I do not need to
understand the technical details."
3. Tell me about a system your team owned. What broke most often, and what did
you change about it?
Why ask it: It tests whether they actually engaged with the reliability of
the thing they were accountable for, or only reported on it.
Strong answer: A specific failure mode, a real diagnosis, and a change with a
measurable result: fewer incidents, faster recovery, a lower error rate.
Weak answer: A general complaint about technical debt with no incident named
and no fix described.
4. How do you decide between rewriting a system and continuing to patch it?
Why ask it: This is the most expensive judgment call in engineering, and the
owner feels the result of it directly in the roadmap and the budget.
Strong answer: A framing rather than a rule. Cost of change today, risk of
the rewrite, whether the business actually needs the behavior to change, and
a preference for incremental replacement over a big-bang rewrite.
Weak answer: An absolute position in either direction, defended in the
abstract without reference to the business.
5. What does code review and engineering standards look like on a team of six?
Why ask it: On a small team, written standards are the cheapest way to raise
quality, and heavyweight process copied from a large company kills speed.
Strong answer: Lightweight and written down. A short checklist, an expected
review turnaround, and automated linting and tests so human review can focus
on design instead of formatting.
Weak answer: A process built for hundreds of engineers, or no standards at
all because "we all know how we work."
6. Describe a time you disagreed with an engineer on your team about an
approach. How did it end?
Why ask it: It shows whether they win arguments by authority, by evidence, or
whether they avoid them entirely.
Strong answer: They made the case, genuinely invited the counter-case, can
name a time they changed their own mind, and closed with a decision and an
owner. Bonus if they write decisions down.
Weak answer: Every disagreement resolves in the manager's favor, or conflict
gets deferred until it resolves itself.
NOTES
[Capture the specific systems, decisions, and tradeoffs the candidate named.]
Set 2: People Leadership, One-on-Ones, and Growth
One-on-one cadence, how they read growth, career paths on a small team, and what they do in their first 30 days with a team they inherited.
People Leadership, One-on-Ones, and Growth Questions
ENGINEERING MANAGER INTERVIEW: PEOPLE LEADERSHIP AND GROWTH
Candidate: __
Interviewer: __
Date: __
WHEN TO USE THIS SET
Use this set for every candidate, and weight it heavily if you are hiring your
first engineering manager. The reason you are adding this layer is almost always
that nobody currently owns the people side of the team: one-on-ones, growth,
retention. These questions test whether the candidate has actually done it.
QUESTIONS, WHY THEY MATTER, AND WHAT A GOOD ANSWER SOUNDS LIKE
1. Walk me through how you run a one-on-one. What do you cover, and how often?
Why ask it: One-on-ones are where retention problems either surface early or
stay hidden until a resignation letter arrives.
Strong answer: A regular cadence, usually weekly or every two weeks, a
running agenda the engineer contributes to, career topics kept separate from
status updates, and notes carried forward between sessions.
Weak answer: "We talk when there is something to talk about," or a one-on-one
that is a status report with a different name.
2. How do you know whether an engineer on your team is actually growing?
Why ask it: The main output of an engineering manager is a stronger team a
year from now, so they need a way to see growth that is not a gut feeling.
Strong answer: Concrete signals. The scope of work they can take unsupervised,
the quality of their design documents, whether teammates seek them out, and
whether the same class of review comment has stopped appearing.
Weak answer: "They seem happy," or a count of tickets closed.
3. Tell me about someone who grew significantly under you. What did you actually
do for them?
Why ask it: It separates managers who develop people from managers who
inherited strong people and did not get in the way.
Strong answer: Specific interventions. A stretch project with support behind
it, visibility brokered with leadership, coaching on a named weakness, and a
clear account of where that person is now.
Weak answer: Takes credit for someone's trajectory without naming a single
thing they did to cause it.
4. How do you handle an engineer who is technically strong but hard to work
with?
Why ask it: This is the most common real people problem on a small
engineering team, and the one that quietly drives good engineers out.
Strong answer: Addresses it early and directly, with specific behavioral
feedback, a clear stated expectation, and an honest willingness to lose the
person if the behavior does not change. Names the cost to everyone else.
Weak answer: Tolerates the behavior because the output is good, or jumps to
termination without ever having given the feedback.
5. How would you build a career ladder for a team of six engineers?
Why ask it: Small companies rarely have one, and engineers leave over the
absence of a visible path more often than over pay alone.
Strong answer: Something proportionate. Three or four levels, expectations in
plain language, and only promises the company can actually keep. A strong
candidate warns against copying a large company's ladder wholesale.
Weak answer: Either a heavyweight competency framework or a flat "we are too
small to need that."
6. What would you do in your first 30 days with a team you did not build?
Why ask it: Nearly every engineering manager hire inherits a team, and the
first month sets whether the team trusts them.
Strong answer: Listen first. One-on-ones with everyone, reading the code and
the incident history, finding out what the team already believes is broken,
then changing one or two things with the team's input rather than over it.
Weak answer: Arrives with a reorganization plan written before day one.
NOTES
[Capture names, specific interventions, and outcomes the candidate described.]
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
Hard conversations and conflict Score: [ 1 2 3 4 5 ]
Evidence: __
Hiring, onboarding, and team building Score: [ 1 2 3 4 5 ]
Evidence: __
Communication with non-engineers Score: [ 1 2 3 4 5 ]
Evidence: __
Fit for a team of your size and stage Score: [ 1 2 3 4 5 ]
Evidence: __
RED FLAGS TO WATCH FOR
[ ] Cannot name a single technical tradeoff they personally accepted
[ ] Has never given difficult feedback, and presents that as a strength
[ ] Every story ends with the candidate being right
[ ] Describes engineers as resources, headcount, or capacity throughout
[ ] Measures individual engineers by ticket count or lines of code
[ ] Would reorganize the team before speaking to anyone on it
[ ] Only ever managed inside one very large company and cannot adapt the process
[ ] Cannot explain a technical decision in language a non-engineer follows
[ ] Vague about why they left the last two roles
[ ] Wants to be the top individual contributor rather than the manager
SUMMARY
Total score: ______ / 35
Overall recommendation: [ ] Strong yes [ ] Yes [ ] No [ ] Strong no
Key strengths: __
Key concerns: __
Reference checks to run: __
Interviewer signature: __
Note: every interviewer scores independently before the group discusses, so the
loudest or most senior voice does not anchor the decision. Compare written
evidence first, then talk.
Ten Questions Worth Asking Every Candidate
If you only have an hour, these ten cover the most ground. Each one is here because it produces evidence you can score rather than an opinion you can only agree with, and each has a note on what a good answer contains.
Question
Why it is worth asking
What a good answer contains
Walk me through a technical decision you made and the tradeoff you accepted
A manager who cannot name a tradeoff cannot evaluate one
The constraint, the rejected option, and what they gave up
How do you stay technical without becoming the bottleneck?
Catches both failure modes at once
A concrete habit plus a rule about critical-path work
Walk me through how you run a one-on-one
Where retention problems surface early or stay hidden
A cadence, a shared agenda, and notes carried forward
How do you know an engineer is growing?
The main output of the role is a stronger team
Observable signals, not happiness or ticket counts
A committed date is going to slip. What do you do?
Predicts how they will treat you when things go wrong
Early escalation with options and a recommendation
Tell me about a time you managed someone out
Forces a process instead of a philosophy
Written expectations, feedback, support, documentation
Two engineers cannot work together. What do you do?
The most common tax on a small team
Separate conversations, then a shared standard, then follow-up
What would you do in your first 30 days here?
Almost every manager hire inherits a team
Listening first, then one or two changes with the team
How would you design an interview loop for a senior engineer?
You are hiring someone who will hire for you
Structured stages, a work sample, written scoring
Tell me about a project that failed. What was your part?
Ownership under failure predicts future behavior
A specific share of blame and a changed practice
Ask each of these of every candidate you interview for the role. The comparison between two answers to the same question is worth more than any single answer, and it is the thing an unstructured conversation cannot give you.
What a Strong Answer Sounds Like
A strong answer is specific, includes something that went wrong, and names a decision the candidate personally made. A weak answer describes what a good manager should do in general. The difference is usually visible within two sentences, and the four examples below show it on the highest-signal questions.
A committed release date is going to slip. What do you do?
Strong answer: Raises it the moment they know rather than at the deadline, brings options instead of only bad news (cut scope, move the date, accept a named risk), and states a recommendation. The owner is never surprised on the day.
Weak answer: Waits to see whether the team can recover it, then asks for weekend work before putting scope or the date on the table.
Tell me about a time you managed someone out.
Strong answer: Describes a sequence: expectations in writing, specific and timely feedback, a defined period to improve with real support, documentation kept as they went, and a prompt, respectful decision. The person was not surprised.
Weak answer: Says they have never had to, and offers that as a strength, or tells a story in which the person found out on the day it happened.
How do you know whether an engineer on your team is growing?
Strong answer: Names observable signals: the scope they can take unsupervised, the quality of their design documents, whether teammates seek them out, and whether the same class of review comment has stopped appearing.
Weak answer: Falls back on how happy the person seems, or counts closed tickets and story points as a measure of an individual engineer.
How do you stay technical without becoming the bottleneck?
Strong answer: A specific habit with a boundary attached: reads pull requests, joins design reviews, occasionally pairs, takes small non-critical tasks, and never owns anything on the critical path.
Weak answer: Either still writes most of the code and calls it leading from the front, or says the technical detail is no longer their concern at all.
The most useful follow-up in the whole interview is some version of what happened next. Strong candidates have the outcome ready, including the parts that did not work. Weaker ones retreat into what they would normally do, which is a signal in itself.
Follow-Ups, Signals, and Red Flags
The prepared question opens the topic; the follow-up is where the evidence comes from. Push for the named system, the actual date, the real conversation. Then watch for the patterns that separate a manager from a senior engineer who interviews well.
Signals worth chasing
Names a tradeoff they personally accepted
Can describe a full underperformance sequence
Changed their own mind at least once
Delivery signals
Estimates in ranges with stated assumptions
Escalates a slip early, with options attached
Watches flow metrics, not individual output
Communication signals
Explains a technical call in plain language
Says what they got wrong without prompting
Answers the question you actually asked
Red flags
Every story ends with the candidate right
Calls engineers headcount or capacity
Would reorganize before talking to anyone
None of these red flags is disqualifying alone. Two or three together usually are, particularly the combination of never having given hard feedback with stories in which the candidate is always right. For more general warning signs across any hire, see the guide to interview red flags.
Interviewing When You Are Not an Engineer
You can run this interview without being an engineer, because the technical depth is the smaller half of the role. What you cannot do is skip the technical signal entirely, so buy it deliberately: put one senior engineer or a trusted advisor in a single stage with a defined question to answer, instead of handing them the loop.
You are not an engineer, and you are the one running the interview
Plenty of owners hiring an engineering manager cannot personally grade a technical answer, and that is fine, because the technical depth is the smaller half of this role. What you can evaluate, better than most engineers can, is whether the candidate explains a technical decision in language you follow, whether they name tradeoffs instead of certainties, and whether their stories about people are specific. Ask the question, listen against the good-answer notes in each set, and score it. If you want a technical check as well, bring one senior engineer into a single stage with a defined signal, rather than handing the whole loop to them.
This is the first management layer the team has ever had
When a small company hires its first engineering manager, the team usually reported to the founder and liked it that way, so the new manager arrives as an unrequested layer. That changes what you should interview for: the first 30 days matter more than the five-year plan, and a candidate who arrives with a reorganization already drafted is a risk rather than a decisive leader. Weight the questions about inheriting a team, about one-on-ones, and about earning technical credibility. Ask directly how they would win over a senior engineer who wanted the job themselves, because that person exists on most teams.
A bad manager hire costs more than a bad engineer hire
An engineer who does not work out costs you their salary and some rework. A manager who does not work out can cost you the engineers who report to them, and those departures arrive months later when they are hardest to trace back. That asymmetry is the entire argument for structure: the same questions for every candidate, written scores before anyone debates, and real reference checks with people who reported to the candidate, not only people they reported to. After you choose someone, FirstHR handles the people side of making it official: the offer for e-signature, the new hire paperwork, an onboarding workflow, and the signed documents stored on the employee profile. FirstHR is an onboarding and HR platform, not a project tracker or a code hosting service, so pair it with those. Applicant tracking is coming soon to FirstHR.
Score all seven areas from 1 to 5 immediately after each interview, while the answers are still exact, and write one line of evidence next to every number. A score without evidence attached is a gut feeling wearing a number, and it will not survive the discussion.
Scoring area
What a 5 looks like
What a 2 looks like
Technical credibility
Names real tradeoffs and their cost
Approves plans without a question
People leadership
Specific growth stories with outcomes
Generic philosophy, no names
Delivery and predictability
Ranges, assumptions, early escalation
Confident dates, late bad news
Hard conversations
A full sequence, documentation included
Has never had to, presented as a strength
Hiring and onboarding
Structured loop and a real ramp plan
Gut feel and a wish list of technologies
Communication
Explains a decision in plain language
Cannot answer without jargon
Fit for your size
Adapts process to a team of six
Only knows one very large company's process
If more than one person interviews, everyone scores alone before the group talks. Where the founder and the senior engineer disagree sharply on the same candidate, that gap is the most useful thing in the room, so surface it rather than averaging it away. A standard evaluation form keeps the notes comparable across stages.
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
A fair interview and an accurate interview are the same interview. Asking every candidate the same job-related questions keeps you inside federal anti-discrimination rules, reduces bias, and produces better evidence at the same time. This is the part most question lists leave out entirely.
Ask about the job, not the person
Federal anti-discrimination law, enforced by the EEOC, prohibits basing a hiring decision on protected characteristics, and questions that probe them create risk even when they are asked as small talk. Avoid age, race, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. Engineering manager interviews have their own traps: asking when someone graduated is an age proxy, asking whether they can keep up with a young team is worse, and asking about visa history rather than simple work authorization is a national-origin problem. Keep every question tied to leading engineers and shipping software. Every question in these sets is written to stay on the job. This is general information, not legal advice.
Ask every candidate the same core questions
A structured interview, where each candidate answers the same questions and is scored against the same rubric, predicts on-the-job performance far better than a free-flowing conversation, and it makes a decision much harder to challenge afterward. This matters more for a manager hire than almost any other, because a charismatic candidate can interview far better than they manage, and rapport is exactly what an unstructured conversation rewards. Write the questions before you meet anyone, ask them in the same order, and score them the same way. The sets and scorecard on this page exist to make that the path of least resistance.
Score independently, then discuss
When more than one person interviews, each interviewer fills in the scorecard alone before the group talks. Without that rule, the most senior voice in the room anchors everyone else, which is how strong candidates get talked out of and weak ones get talked into. Compare written evidence first, then discuss the gaps. For an engineering manager hire this is particularly important, because the founder and the senior engineers on the panel are usually weighting completely different things, and the disagreement is the useful part. A seven-area rubric filled in independently turns that into a structured conversation instead of an argument.
Keep technical exercises job-related
If you use a technical exercise or a work sample as part of the loop, keep it clearly related to the work the manager will actually oversee, apply it to every candidate for the role, and keep the scoring consistent. Selection procedures that screen candidates out are subject to the same fairness expectations as interview questions, and an exercise that has little to do with the job is both weaker evidence and harder to defend. For a manager role, a written plan for a realistic scenario (a slipping project, an underperforming engineer, a rewrite decision) is usually a better sample than a coding test. This is general information, not legal advice.
Structure Beats Rapport, Especially for Manager Hires
A structured interview, where every candidate answers the same questions against the same rubric, predicts on-the-job performance more reliably than a free-flowing conversation, and asking the same job-related questions of everyone also keeps you within the EEOC's rules against basing decisions on protected characteristics. For a manager hire the gap is wider than usual, because charisma is exactly what an unstructured hour rewards.
If your loop includes a written exercise or a work sample, keep it clearly job-related and score it the same way for everyone; the EEOC guidance on employment tests and selection procedures treats any screening step as a selection procedure. Avoid the small-talk traps about age, graduation year, family plans, or origin. This is general information, not legal advice, and specifics on what not to ask are in the guide to illegal interview questions.
Engineering Manager Pay
There is no federal occupation titled software engineering manager, so benchmark against the two that come closest. According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), architectural and engineering managers had a median annual wage of $171,270, and computer and information systems managers had a median of $175,140.
Percentile
Architectural and engineering managers
Computer and information systems managers
10th percentile
$120,810
$107,550
25th percentile
$139,360
$138,060
Median
$171,270
$175,140
75th percentile
$212,500
$220,730
90th percentile
$262,760
$297,510
Two Occupations, Two Very Different Outlooks
The Bureau of Labor Statistics projects employment of architectural and engineering managers to grow 4 percent from 2024 to 2034, with about 14,500 openings a year, while computer and information systems managers are projected to grow 15 percent over the same period, with about 55,600 openings a year. If you are hiring on the software side, expect a tighter market and a shorter decision window.
A small business hiring its first engineering manager usually lands between the 25th percentile and the median, and should budget separately for the cost of a miss, which at this level dwarfs the salary difference between a good hire and a cheap one. Benchmark to your local market, your field, and the size of the team the person will actually run.
From Interview to Onboarding
The interview is one step. Once you choose someone, the work shifts to reference checks with people who reported to the candidate, a clear offer letter, and a structured first 90 days, which matters more for a manager than for an individual contributor because their mistakes compound through other people.
Prepare the question set
Pick the sets that match the role and ask the same core questions of every candidate, so the comparison is fair rather than impressionistic.
Score on the rubric
Each interviewer scores the seven areas independently with a line of evidence, then the group compares written notes before discussing.
Check references properly
Talk to people who reported to the candidate, not only their former managers, and ask about feedback, conflict, and growth.
Send the offer
Confirm the role, scope, compensation, and start date in writing, with e-signature so the record is clean from day one.
Onboard for the first 90 days
Give the new manager a structured ramp: who they meet, what they own by when, and what you expect them not to change yet.
FirstHR connects the offer, the paperwork, the e-signatures, and the onboarding workflow in one place, and stores the signed documents and interview records on the employee profile, so a small business can run hiring through onboarding from a single system. Applicant tracking is coming soon to FirstHR. For the manager-specific ramp, see the guide to leadership onboarding.
One more thing worth doing in the first month: agree in writing on what the new manager should not change yet. It protects the team from a reorganization nobody asked for, and it gives the manager cover to say no while they earn credibility. More question kits for other roles live in the hiring templates library. Applicant tracking is coming soon to FirstHR.
Key Takeaways
Assess an engineering manager on six competencies: technical credibility, people leadership, delivery, hard conversations, hiring, and communication with non-engineers.
Technical depth matters for judging work, not for doing it; a manager on the critical path becomes the bottleneck their own team routes around.
The highest-signal questions are a tradeoff they personally accepted, what they do the hour a date slips, and a full account of managing someone out.
Decide whether you need a tech lead or a manager before you interview, because a small team in architectural pain does not need a management layer.
Ask the same core questions of every candidate and keep every question tied to the job, which is both the fairer and the more accurate approach.
Score all seven areas from 1 to 5 with written evidence, independently, before anyone in the group starts arguing for a candidate.
Frequently Asked Questions
What questions should I ask an engineering manager candidate?
Ask across six areas: technical credibility, people leadership, delivery and estimation, hard conversations, hiring and onboarding, and communication with non-engineers. The highest-yield questions are: walk me through a technical decision you made and the tradeoff you accepted; how do you run a one-on-one; a committed date is going to slip, what do you do; tell me about a time you managed someone out; how do you know an engineer is growing; and what would you do in your first 30 days with a team you did not build. Every one of these asks for a specific past example rather than a philosophy, which is the difference between an answer you can score and an answer you can only admire. This page groups 36 such questions into six downloadable sets, each with notes on what a strong answer sounds like.
How technical does an engineering manager need to be?
Technical enough to judge the work, not technical enough to do all of it. A manager who cannot reason about a tradeoff will approve every plan the team brings on confidence alone, and senior engineers stop taking them seriously within a quarter. A manager who cannot stop writing critical-path code becomes the bottleneck their own team routes around. The practical test in an interview is whether the candidate can describe a technical decision they personally made, name what they gave up, and explain it in language a non-engineer follows. On a small team the bar is usually higher than at a large company, because there is no staff engineer to lean on and the manager may still review code. Ask for the specific decision, not for a self-rating.
What is the difference between a tech lead and an engineering manager?
A tech lead owns technical direction and usually still writes code, while an engineering manager owns the people: hiring, one-on-ones, growth, performance, and the delivery commitment. Some small companies combine them, which works up to roughly five or six engineers and stops working after that, because the people work expands until the technical work gets squeezed out or the reverse. If your team is small and the pain is architectural, a tech lead or a senior engineer is often the better hire. If the pain is that nobody runs one-on-ones, nobody handles underperformance, and nobody can tell you when anything will ship, you need a manager. Decide which problem you are solving before you write the job description, because the interview questions differ accordingly.
How do I interview an engineering manager if I am not technical?
Focus on what you can evaluate directly and buy the technical signal separately. You can judge whether a candidate explains a decision in language you follow, whether they name tradeoffs rather than certainties, whether their stories about people are specific enough to be true, and whether they escalate bad news early. Those are the traits that determine whether this hire works for you. For the technical half, bring one senior engineer, a trusted advisor, or a contractor into a single stage with a defined question to answer, rather than handing them the whole loop. Use the good-answer notes in each question set as your reference while you listen. You are not grading the engineering; you are grading the judgment and the honesty around it.
How many interview rounds should an engineering manager hire have?
Three to four stages is enough for most small businesses, and more than five starts costing you candidates. A practical loop is a short screening conversation, a deep interview on people leadership and hard conversations, a technical and delivery conversation with a senior engineer or an advisor, and a final conversation with the founder about scope, expectations, and the first 90 days. Add a written work sample only if it replaces a stage rather than adding one: a short plan for a realistic scenario, such as a slipping project or an underperforming engineer, tells you more than a coding exercise for this role. Score every stage on the same rubric so the stages combine into a decision instead of a series of impressions.
Should I promote a senior engineer or hire an engineering manager externally?
Promoting works when the person actually wants the job, has already been doing parts of it informally, and the team respects them. It fails when management is treated as the only available promotion, because you lose your best engineer and gain a reluctant manager. Hiring externally brings experience with the things a first-time manager has never done, such as running an underperformance process, but the new manager arrives without credibility and has to earn it. A practical middle path is to interview both, using the same questions and the same scorecard, and to be explicit with the internal candidate about what happens if they are not selected. Whichever way you go, the questions on this page apply equally, because you should test the same competencies in both.
What are the biggest red flags in an engineering manager interview?
The clearest red flags are: cannot name a technical tradeoff they personally accepted, has never given difficult feedback and offers that as a strength, tells stories in which they are always right, describes engineers as headcount or capacity, proposes to measure individuals by ticket count or lines of code, and would reorganize an inherited team before speaking to anyone on it. Two more matter at a small company: a candidate whose entire experience is inside a very large company and who cannot describe how they would adapt the process, and one who clearly wants to be the strongest individual contributor rather than the manager. None of these is automatically disqualifying on its own, but two or three together usually are. The downloadable scorecard includes this checklist.
How much does an engineering manager cost to hire?
Pay depends on the field and the market. According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), architectural and engineering managers had a median annual wage of $171,270, with the 25th percentile at $139,360 and the 75th at $212,500. Computer and information systems managers, the closest federal occupation for a software engineering manager, had a median of $175,140, a 25th percentile of $138,060, and a 75th percentile of $220,730. There is no separate federal occupation titled software engineering manager, so treat both as benchmarks rather than exact matches. A small business hiring its first manager usually lands between the 25th percentile and the median, and should also budget for the cost of a miss, which at this level is much larger than the salary. This is general information, not financial advice.
