HM Round

The hiring-manager round is a conversation about the work you can own and the judgment you bring to a team. For a senior engineer, explaining how you made a difficult technical decision matters alongside how you collaborated. A friendly conversation still needs evidence.

Formats vary. Atlassian's engineering handbook describes a manager interview covering past projects, technical challenges, collaboration, and career direction. Amazon's senior-engineer preparation combines technical competence with examples of decisions, successes, and failures. Confirm your own round's scope with the recruiter; “HM round” does not guarantee a purely behavioral interview.

What the manager needs to decide

Prepare to make these decisions assessable:

Question behind the conversation	Evidence you can provide
Can you own work at this level?	The boundary you owned, decisions you made, dependencies you coordinated, and what you operated afterward.
Do you exercise technical judgment?	A real constraint, viable alternatives, the failure you anticipated, and the cost you accepted.
Can others work effectively with you?	How disagreement changed a decision, how you communicated risk, and how you helped someone become more independent.
Will the role suit your direction?	Work you want more responsibility for, relevant experience, and questions about the team's actual needs.

GitLab's senior backend responsibilities, for example, include technical complexity, influence on team goals, code review, and mentorship. A senior answer needs more than a list of tickets completed or people coordinated.

Keep your introduction short: current scope, one relevant accomplishment, and the responsibility you want next. Connect motivation to the opening. “I've owned an API through rollout and incidents; I want broader responsibility for its data lifecycle” gives the manager something to examine. Check whether that responsibility actually exists on the team.

Make one project inspectable

Choose a project where you remember the decisions, including the inconvenient details. Prepare the user problem, initial state, constraints, alternatives, your contribution, rollout, and outcome. Know where your ownership ended. Credit the person who designed the part you only integrated.

STAR means situation, task, action, and result. Use it to organize an answer; spend most of the time on actions and their reasons. You do not need to announce four headings. Start with a brief overview and leave room for the interviewer to choose a technical branch.

Consider this weak answer:

“I led a reporting redesign. We moved to queues, improved scalability, and reduced failures by 93%.”

The interviewer cannot tell what failed, whether a queue helped, or what “led” means. Here is an illustrative revision with invented numbers, not an employer's script or experience to claim:

“Large exports timed out and users restarted them, repeating expensive database work. I owned the backend export path; another engineer owned the status UI. We had three weeks and shared database capacity with interactive requests.

“I compared raising timeouts, optimizing the existing query, and asynchronous exports. Query tuning reduced scan cost but still left large exports tied to request lifetime. We chose durable jobs, bounded worker concurrency, and a status endpoint, accepting more operational work and delayed downloads.

“I wrote the proposal and job lifecycle, paired on retry handling, and coordinated a staged rollout with support. We checked file counts and totals against the agreed source snapshot and watched interactive latency alongside export failures.

“In comparable seven-day windows, failed export jobs fell from 6% of 1,000 jobs to 0.4% of 1,000. That's 60 versus four failures. It doesn't establish a revenue impact. We still had a slow completion tail for the largest tenant, so I left that limitation visible and prioritized fairer scheduling.”

The revision exposes decisions that can be challenged. Prepare for follow-ups such as:

• “Why wasn't the query fix enough?” Explain what remained slow after measurement and which requirement asynchronous execution addressed. Distinguish making a request return sooner from completing an export sooner.
• “What if a worker dies halfway through?” Describe the actual retry boundary, checkpoint or restart strategy, and how incomplete files stay unavailable. Explain how retries preserve the promised snapshot; do not invent exactly-once execution.
• “How do you know the rollout caused the improvement?” Define a failed job, denominator, tenant mix, observation window, and other changes. Matched windows support a comparison; they do not eliminate every confounder.
• “Which decision was yours?” Name what you proposed, implemented, reviewed, or approved. Distinguish your actions from the team's result.

For a frontend project, the same depth might involve stale-response races, browser performance across device classes, accessibility, or a migration's compatibility boundary. Explain a mechanism and its consequence rather than reciting framework names.

Use truthful evidence even when exact metrics are unavailable: an incident timeline, removed manual step, adoption record, review outcome, or support-ticket pattern. Label estimates and explain their basis. Describe confidential work at an appropriate abstraction without sharing private artifacts.

Show judgment when the outcome was difficult

Prepare an example where reasonable people disagreed. Explain the other person's concern well enough that their position makes sense. Then show how you influenced the decision without relying on authority: a small experiment, a written comparison, stakeholder input, or a reversible rollout.

In the export example, product might favor a timeout increase to meet a customer deadline while you favor durable jobs. A useful answer identifies the shared goal, the risk of repeated database work, and the evidence used to choose a first release. State who made the final decision. If it went against your recommendation, explain how you supported execution and what evidence would justify revisiting it. Escalate unresolved material risks through the appropriate owner; silently accepting them is not collaboration.

A failed-decision answer needs your mistaken assumption and its consequence. “We initially sized concurrency from single-job tests; parallel exports saturated the shared pool. I recommended that setting. We reduced concurrency, added a representative load test, and changed the rollout gate” shows ownership and a changed practice. “The other team didn't test properly” leaves your judgment unexamined. This is another hypothetical example; use a real decision from your work.

For ambiguity and prioritization, describe what you clarified before committing: whose problem mattered, what success meant, what could be deferred, and who accepted the residual risk. For mentoring, show increasing autonomy: what the engineer could handle independently afterward and how your support changed. Counting pairing sessions alone says little about their growth.

Assess the role and practice the conversation

Reserve time for questions that affect your own decision. Choose a few and follow up on specifics:

• “What would successful ownership look like after three and six months? Which decisions would I make independently?”
• “What constraint is limiting the team now: capacity, architecture, unclear requirements, or dependencies? Can you describe a recent example?”
• “Who owns production incidents and on-call? What happens to planned work after an incident?”
• “How did the team resolve its last significant technical disagreement? How do senior engineers help others grow here?”

Close by connecting one demonstrated strength to a stated team need, clarifying any open concern, and confirming next steps. Avoid promising outcomes before understanding the system.

Practice from evidence, not memorized paragraphs. Pick three real examples: a delivered project, a disagreement or ambiguous priority, and a failed decision. Spend ten minutes checking dates, contributions, and outcomes against your notes. Give a two-minute overview of each, then ask a partner to probe one technical choice and one impact claim. Revise every sentence you cannot substantiate. Keep a one-page reminder of decisions, evidence, and limitations so the next practice tests recall and reasoning rather than a script.