How to Prepare for the Hiring Manager Round
The interview everyone under-prepares. It’s usually the one that decides the offer.
Everyone spends weeks grinding coding problems and reading system design primers. Then they walk into the hiring manager round having done almost no preparation, because it “isn’t technical.” That round is often the one that decides the offer.
A quick word on where this comes from. I have been on both sides of this table. I built and hired for the engineering team at ZZAZZ, so I have run these rounds and had to make the call, and I have also been the candidate sitting across from a hiring manager more than once lately. Most of what follows comes from that, not from a template.
The coding round tells the company you can code. The system design round tells them you can think at scale. The hiring manager round answers a different question, and it is the question the manager actually cares about: is this someone I want on my team for the next year, and can I trust them with real work?
The manager is the one person in the loop who has to live with the decision. A panel interviewer assesses a narrow slice and moves on. The recruiter wants the seat filled. The manager owns the outcome. If they hire wrong, they spend the next several months managing the consequences. So they are not testing you the way a panel does. They are assessing risk.
Once you see the round that way, preparation gets simpler. Almost every question is a proxy for one of three things:
Can you do the actual work at the level we need?
Do you own your work, or do you point at other people when it breaks?
Are you someone the team wants to work with?
Everything below is in service of showing those three things clearly.
Do the reading properly
Reading about the company does not mean skimming the homepage an hour before the call. The homepage is written for customers. You need the version written for engineers.
Read their engineering blog. Read the last few posts, and notice which problems they are proud of solving. Read their changelog or release notes if the product is public. Understand the business: who pays them, how they make money, who their competitors are. A payments company lives under different constraints than a developer tools company, and the manager will notice immediately whether you understand the pressures their team is actually under.
If they are a startup, know their stage and their last raise. If they are public, skim the last earnings summary. You do not need to become an analyst. You need enough context to reason out loud about why their engineering priorities look the way they do.
Learn their values, then hide them
Most companies publish a set of values. Read them. Then do the harder thing: prepare stories that demonstrate a value without naming it.
If a value is “customer obsession,” do not say “I am customer obsessed.” Tell the story where you shipped something painful and unglamorous because the customer needed it. If a value is “bias for action,” tell the story where you made a call with incomplete information and owned the result. Naming the value is what everyone does. Showing it is what separates you.
The values also tell you what the company is worried about. Companies write values in response to problems they have had. Read them as a map of what this manager will be screening for.
Understand how they hire
Before the round, find out how the loop actually works. The recruiter will usually tell you if you ask directly. Blind, Glassdoor, and LinkedIn fill in the rest.
Specifically, learn whether the hiring manager round is behavioral only or whether the manager will also probe technical depth. Some managers spend the whole hour on projects and collaboration. Others will pull one line off your resume and go deep enough to turn it into a mini technical interview. Knowing which kind of manager you are walking into changes how you prepare.
Read the job description like a spec
The JD is not marketing copy. Someone on the team wrote each line because they needed it. Read it the way you would read a spec.
Every required skill is something the team expects to use. Every “nice to have” is a gap they are hoping to fill. The verbs tell you the level: “contribute to” is a different job than “own” or “drive” or “architect.” Map your own experience against each line, and have a concrete example ready for the ones that matter most. When the manager asks whether you have done X, you want a specific story, not a yes.
Know your resume cold
You wrote it, but under pressure people fumble their own bullets. The manager will not ask about the boring lines. They will pick the shiniest claim and drill into it.
If you wrote “reduced p99 latency by 40 percent,” be ready to explain the baseline, what was actually slow, what you changed, why that worked, and what you would do differently now. If you wrote “led the migration,” be ready to say what “led” meant, how many people, what went wrong, and how you handled it. Every line on your resume is an invitation to a follow-up question. Do not put anything on there you cannot defend for five minutes.
Practice STAR, but fix the ratio
STAR is the standard structure for behavioral answers: Situation, Task, Action, Result. It works. Most people just use it badly.
The common failure is spending most of the answer setting up the situation, a little on the task, a rushed sentence on the action, and nothing on the result. Flip that. The situation needs one or two sentences of context, no more. The signal lives in the action (what you specifically did, and why) and the result (what happened, quantified if you can). Practice your stories out loud and time them. Two to three minutes each is the target. If you cannot land the story in three minutes, it is not ready.
One thing matters more than the structure: use “I,” not “we.” The manager is hiring you, not your old team. “We decided” tells them nothing about what you did. Be honest about which part was yours.
Build a story bank
You do not need a unique story for every possible question. You need six to eight strong stories that each flex to cover several questions. One hard project can answer “toughest challenge,” “an engineering trade-off,” and “a conflict,” depending on which part you emphasize. Prepare the raw material once, then aim it at whatever the manager asks.
The questions you will probably get
“Tell me about yourself.” This is not your biography. It is a ninety-second narrative: where you are now, the through-line of your career, and why you are sitting in this conversation. End by pointing at the role. This answer sets the frame for the entire round, so it is the one to practice most. Get it tight and get it natural.
“Why our company? Why this role?” The weak answer praises the mission in words that would apply to any company in the space. The strong answer connects three things: something specific about this company that you could not say about their competitor, something about the role itself, and something about you and where you are trying to go. Specificity is the whole game here. It is the proof that you did the reading and are not running a numbers game across fifty applications.
“Why are you leaving your current role?” They are checking two things: whether you are moving toward something or just running away from something, and whether you are going to badmouth them in a year the way you might badmouth your current employer right now. Keep it about what you are moving toward. Even if your current job is genuinely bad, framing the move around scope, growth, or a problem you want to work on lands far better than a list of grievances. The way you describe the place you are leaving is the clearest preview a manager gets of how you will one day describe them.
“Tell me about an engineering trade-off you made.” This is a maturity check. Nothing in engineering is free, and the manager wants to see that you know it. Pick a real decision with real tension: consistency against availability, speed against correctness, build against buy, or tech debt you took on purpose. Say what you optimized for, what you gave up, and why that was the right call in that context. The signal is not that you found a clever answer. It is that you can name the cost of your decision instead of pretending there wasn’t one.
“What is the toughest technical problem you’ve solved?” Depth and ownership. Pick something genuinely hard that you drove, not something that was merely tedious. Walk through the messy part: where you got stuck, the dead ends, how you eventually got out. Managers trust people who have been in the trenches and can describe the debugging honestly. A clean story with no struggle in it reads as either shallow or rehearsed.
“Walk me through a project you owned end to end.” This is a level-calibration question as much as anything else. The same story scores differently depending on how much of it was actually yours. A junior version describes finishing a well-scoped piece someone handed over. A senior version describes shaping the problem, making the trade-offs, pulling in the right people, and carrying it through to something that shipped and held up in production. Show the full arc, and be specific about the decisions you made rather than the tasks you completed. If you are interviewing at a senior or staff level, this is where you prove the scope, so do not shrink the story down to the coding.
“Tell me about a conflict with a coworker.” This is the highest-signal behavioral question, and the one people flub most. The manager is not asking you to prove you never have conflicts, nor to prove you always win. They want to know whether you engage with disagreement like an adult: do you separate the person from the problem, can you disagree and then commit, do you stay respectful when you are frustrated. The trap is casting yourself as the hero and the other person as the idiot. The best answers show respect for the other side, a real process for working it out, and often a moment where you changed your mind or found a better third option. Never badmouth anyone. How you talk about a past colleague is how they assume you will talk about them.
“Tell me about a time you disagreed with your manager.” Peer conflict tests your ability to work with people. This one tests whether you can manage up without either steamrolling or caving. They want to see that you can make your case with evidence, that you know when to keep pushing and when to disagree and commit, and that you can do it without turning it into a standoff. The weak answer is the one where your manager eventually saw you were right and thanked you. Real disagreement is messier than that, and a story where you pushed, lost, committed anyway, and it worked out fine often lands better than one where you won.
“Tell me about a time you failed or made a call that went wrong.” This is an accountability check, and the fake answers are easy to spot. “I cared too much and took on too much” is not a failure. Pick a real one where you owned a decision that did not work out. Say what you got wrong, what it cost, how you contained it, and what you actually changed afterward. Managers are not afraid of people who have failed. They are afraid of people who cannot see their own part in it, so own the mistake instead of spreading the blame.
“How do you handle competing priorities when everything feels urgent?” This is a judgment question dressed up as a time-management question. Anyone can say they make a list. What the manager wants is how you decide what actually matters, how you communicate the trade-offs to the people affected, and whether you push back when the load is genuinely unsustainable instead of quietly dropping things. Walk through a real moment where you had too much on your plate and had to choose. The signal is in the reasoning behind the choice, and in whether you told the people who needed to know.
“What are your strengths and weaknesses?” For the strength, pick one that matters for this role and back it with evidence, not adjectives. For the weakness, pick a real one. “I work too hard” fools no one and signals that you are not self-aware, which is the actual thing being tested. Name a genuine weakness and describe the system you built to manage it. A real limitation with a real mitigation beats a fake flaw every time.
“Where do you see yourself in five years?” The manager is checking two things: whether your trajectory fits what this role can offer, and whether you are going to leave in six months. You do not need a rigid plan, and pretending you have your whole life mapped out reads as canned. Show a direction (deeper as an IC, or toward leadership, or into a domain) that this role plausibly serves. Honest and directional beats scripted.
“How do you use AI in your work?” This one is increasingly standard, and it cuts both ways. Managers are wary of engineers who refuse to touch AI tools, and just as wary of the ones who paste whatever the model generates straight into production. Show that you use it with judgment: you reach for it where it helps, you review what it produces, and you know where it falls down. If you know how the company itself uses AI, work that in. The thing being assessed is taste, not enthusiasm.
Have real questions for them
Every hiring manager round ends with “do you have questions for me,” and that part is scored. It is your chance to show you are evaluating them too, which is exactly what a strong candidate does.
Ask things a thoughtful person would actually want to know. What does success in this role look like in six months? What is the hardest problem the team is facing right now? Why is the role open? How do decisions get made when the team disagrees? What does the manager wish someone had told them before they joined?
Save the logistics for the recruiter. Salary, equity, remote and work-from-home policy, PTO, notice period, visa, start date, leveling and title: none of that belongs in the hiring manager round. The recruiter owns those questions and expects them, so asking the manager instead burns the one conversation you get with the person deciding, and it can read as though you are negotiating a package for a job you have not been offered yet. The questions are fine. The audience is wrong.
Skip anything answered on the careers page too, and skip questions that are really just you fishing for reassurance. Good questions leave the manager thinking the conversation went both ways.
A few things that apply the whole way through
Treat the round as a conversation, not an interrogation. Managers hire people they want to talk to every day for a year, and stiff, over-rehearsed answers work against you even when the content is right.
Match the level you are interviewing for. A staff candidate should talk about scope, influence, and the calls they made, not a list of tickets they closed. If you are interviewing above your last title, show the manager the wider version of your work.
And know the red flags they are watching for, because avoiding them is half the battle: blaming other people, no ownership, vague non-answers, badmouthing a past employer, having no questions, and either obvious desperation or obvious indifference. None of those are about talent. They are about whether you are safe to bet on.
The coding rounds decide whether you can do the job. The hiring manager round decides whether they want you doing it there. Prepare for it like it matters, because it is usually the one that does.
If this helped, my book Digital Footprint for Software Engineers covers the other half of the job search: building a public presence so the right roles find you.