Hiring-manager round on impact and collaboration

The hiring-manager round is a separate conversation from the culture round. The culture round asks how you act on values; the hiring manager asks whether you'd succeed on their team, at the level they're hiring for. Expect questions about:

• Impact: the most significant thing you've done, what changed because of it, and how much of it was you.
• Working with non-engineers: researchers, product, policy, legal, sales, customers. At an AI lab, engineers work closely with researchers, so expect "tell me about working with someone whose priorities were different from yours."
• Mentorship and leadership: how you've grown others, and how you lead without authority.
• Roadmap influence: a time you changed what the team worked on, not just how.
• Fit: what you want next, how you like to work, what kind of manager brings out your best work.

The manager is also selling the team. Leave time for your questions; they're part of the evaluation.

Managers calibrate level from scope. For every story, they're asking three questions:

1. How big was the problem? One feature, one team's system, several teams, the company.
2. How much of the outcome was you? Did you identify the problem, design the solution, lead the people, or execute a piece?
3. Would it happen without you? Things that would have happened anyway, slower, count less than things that wouldn't have happened at all.

Pick stories whose scope matches the level you want, and make your part explicit.

Pull them from your story bank.

"I was the infrastructure engineer embedded with a research team training ranking models. The researchers wanted to change the training data mix almost daily; each change meant a pipeline rebuild that took me about a day. I was becoming the bottleneck, and they were frustrated. Their goal was iteration speed; mine was keeping the pipeline correct and reproducible.

I spent a week sitting in on their experiment reviews to see what they actually changed. About 80% of the changes were mixture weights and filters, not new data sources. So I made those parameters config: a YAML file they could edit, validated by a schema, with each run recording the exact config hash. New sources still came through me.

Their turnaround on a data change went from about a day to under an hour. Over the next quarter they ran roughly 3× as many experiments, and because every run had a config hash, we could reproduce any result, which mattered when one surprising result turned out to come from a filter typo.

What I learned: watch what the other team does before deciding what they need."

"Our org had planned two quarters building a new feature store. Looking at our incident data, I found that 60% of our production model issues in the past year came from training/serving skew in features, not from missing features. A new store wouldn't fix that; it would add a third place where features were computed.

I didn't ask to cancel the project. I wrote a short proposal showing the incident breakdown and proposing to spend the first quarter on a shared feature definition library used by both training and serving, which the new store would later build on. I reviewed it one-on-one with the two managers whose teams were staffed on the store, and with the research lead who'd asked for the store, before the planning meeting.

The plan changed. The library shipped in one quarter; skew-related incidents dropped from about 2 a month to about 1 a quarter. The feature store came later, smaller than planned, on top of the library. One of the two managers stayed skeptical and I didn't win them over fully; they thought I'd delayed their project, and they had a point about the cost to their team's plans."

Specifics make mentorship stories believable:

"I mentored a new graduate on my team for a year. In month two, I noticed she'd spend two days stuck before asking for help. Rather than tell her to ask sooner, I set up a rule for both of us: after 90 minutes stuck, write down what you've tried and send it to me, and I'll reply with a question rather than an answer. By month six she was leading a small migration; by the end of the year she was promoted, and she now runs the same practice with our new hires."

Prepare three or four; you'll have time for two:

• "What would make someone in this role a clear success in six months?"
• "What's the hardest problem the team hasn't solved yet?"
• "How does the team decide priorities between research needs and product needs?"
• "How do you give feedback, and how do you like to receive it?"
• "Who has done well on this team, and what did they do?"

• "We" for everything. The manager can't calibrate your level.
• Scope inflation. Claiming a company-wide outcome that you contributed one part to. Follow-ups will find it.
• Non-engineers as obstacles. Stories where product, research or legal are the villains.
• No mentorship story at L5+.
• Not knowing what you want next. "Anything interesting" doesn't help the manager place you.
• No questions for them.

• "What did your manager think of that decision?"
• "If I called the PM from that project, what would they say about working with you?"
• "What's your biggest area for growth? What are you doing about it?"
• "Why are you leaving your current role?"
• "What kind of work drains you?"
• "Tell me about a time you had to deliver something you didn't believe in."

Mid-level (L4)

• Stories with clear personal contributions and outcomes on their team's systems.
• Works well with a non-engineering partner and can describe that person's goals fairly.
• Knows what they want to learn next; asks good questions about the team.

Senior (L5)

• Impact at the scope of a team's main system, with numbers and a clear "without me, this wouldn't have happened" part.
• Has changed how a partner team works by understanding their needs first.
• Concrete mentorship with a result; has influenced the team's plan at least once.

Staff (L6+)

• Changed a multi-team roadmap using evidence and by building support beforehand, and is candid about who stayed unconvinced and why.
• Grows several people or raises the team's bar (hiring, review practices, standards).
• Talks about the manager's problems (staffing, priorities, risk) like a partner, and asks questions that show it.