The technical credibility round for engineering managers is graded differently from IC system design. The interviewer is asking: could this person credibly review my design doc and push back on bad ideas? Not: can they invent every protocol from first principles?
What is graded
- Can you frame ambiguous problems and pick scope?
- Do you ask the right tradeoff questions?
- Can you guide the conversation as if you were leading a design review?
- Are you willing to make decisions and defend them?
- Do you know enough to push back when an engineer overcomplicates?
What is not graded as heavily as in IC interviews
- Implementation details (rate limiter algorithm internals)
- Memorization of QPS-per-instance benchmarks
- Live coding
- Optimal complexity analysis
How to drive an EM system design
The strongest signal is acting like the senior person in the room without being arrogant.
- Clarify the problem. “What is the user story? Who is the customer? What is success?” — these are EM-level questions.
- Pick scope explicitly. “I am going to focus on the read path first; we can come back to writes if there is time.”
- Decompose into components. “I see five pieces: ingest, storage, query, serving, ops.”
- Make tradeoff calls. Pick one approach and explain why over alternatives. Do not just enumerate options.
- Address ops. Monitoring, alerting, on-call, rollout, rollback. ICs forget this; EMs are expected to lead with it.
- Address team. “If I had a team of 6 engineers, I would split this into 3 swimlanes: ingest pipeline, query layer, frontend.”
The on-call and incident question
“How do you handle on-call as an EM?”
Strong answers cover:
- You participate in on-call enough to stay credible (some EMs rotate, others shadow)
- You analyze incident frequency and root-cause yourself, not just delegate
- You ensure runbooks exist for every alert
- You allocate engineering time to reduce alert volume — false alerts are a tax
The technical-debt question
“How do you balance new features against technical debt?”
Strong answers:
- Track debt explicitly — prioritized backlog, not folklore
- Allocate a budget (10–20% of capacity is common)
- Tie debt paydown to specific outcomes — “this refactor unlocks the next feature with half the effort”
- Be willing to take on debt deliberately when speed matters more than purity
The “do you still code?” question
This question is a Rorschach test — the right answer depends on the company.
- Smaller / earlier-stage: some coding is expected (10–20%)
- FAANG senior+: coding is rare; reading PRs is expected; managing-up and strategy take precedence
Best honest answer: “I write code when it unblocks the team or when I want to keep my hands warm. I review code regularly. I do not pretend my code is critical-path.”
Frequently Asked Questions
What if I have not done a recent technical project I can defend?
Pick the most recent decision you led — even a tooling choice or a process change. The depth of your reasoning matters more than the size of the project.
Do I need to keep up with frontier tech (Rust, eBPF, vector DBs) as an EM?
Headlines, yes. Implementation details, no. You should be able to explain why your team would or would not adopt them.
How do I handle being out-coded by my reports?
Celebrate it. The goal is to hire engineers stronger than you in their domains. Your value as an EM is the leverage you create across the team, not the code you write.