Engineering Management interview prep.

An EM at a devtools / infra firm runs a team that ships products other engineers depend on - CI/CD, kv stores, schedulers, observability - often partly open-source, always at the dependency layer of every customer's stack.

What interviewers look for

  • Can the candidate manage an underperformer end-to-end at the infra layer where mistakes cascade to customers - diagnose, coach, PIP, transition - with specifics + metrics?
  • Do they hire + grow engineers deliberately at the infra bar (API discipline + distributed systems + production ownership) and across IC / OSS maintainer / DevRel paths?
  • Can they set a multi-quarter API + platform strategy: backward-compat budget, deprecation discipline, OSS-vs-product line, platform leverage - and defend tradeoffs to PM + exec + community?
  • Do they handle cross-functional + customer dynamics - PM, DX / Docs / DevRel, customer success + TAMs, OSS community - with data + tact + escalation discipline?
  • Are they delivery + dependency-layer-reliability disciplined - cell-based deploys, customer-SLO contracts, blast radius, postmortems published to customers when warranted?
  • Do they communicate well with non-engineers (exec, customers via TAMs, community) - and own bad news (deprecations, postmortems, missed customer SLO) before it festers?

Behavioural questions to expect

  1. Walk me through your CV.

    What it tests: Story coherence + genuine fit for the devtools / infra EM seat. Teams want evidence of the IC-to-EM transition handled well, progressive team scope (4 -> 8 -> 15-30 engineers), team experience at the dependency layer (customer-SLO, OSS, API discipline) - not just years.

  2. Tell me about your most impactful management decision or call.

    What it tests: Management judgment + the willingness to own a hard people / strategy / customer call at the dependency layer and defend it. Tests whether the candidate frames the call with stakes + alternatives + outcome - not 'I introduced a new process'.

  3. Tell me about a weakness, a failure, or feedback you've received and worked on.

    What it tests: Self-awareness + management discipline. Cross-role canonical. Fake weaknesses downgrade immediately. Devtools / infra EM mistakes (the missed PIP signal, the missed customer-SLO breach communication, the breaking API change shipped without proper deprecation, the OSS community fight handled badly) shape teams + customer trust.

  4. Why engineering management - and why at a devtools / infra firm specifically?

    What it tests: Authentic fit: growing people + setting strategy + driving cross-functional outcomes is different from IC; tests whether the candidate WANTS the trade-off AND understands why devtools / infra changes the EM job (customer is an engineer, OSS often part of the surface, dependency-layer reliability raises the bar).

  5. Which team or org would you want to run, and why?

    What it tests: Genuine fit + grasp of how devtools / infra EM seats differ. Tests whether the candidate has a reasoned preference (product team owning a customer-facing surface / platform team owning shared infra / OSS maintainer team / dev platform / observability) + understands what each demands.

  6. Why this firm?

    What it tests: Whether the candidate has done the homework. Bar: firm-specific evidence from the product, eng culture, OSS posture, customer-SLO contracts, scale, team challenges, and people - not generic 'great devtools company'.

  7. How would you describe this firm's engineering organisation + infrastructure in your own words?

    What it tests: Whether the candidate has internalized HOW the firm builds + operates infra - org shape, OSS posture, customer-SLO contract, RFC culture - not just that it 'has engineers'. Tests whether they've read the eng blog + RFCs + OSS repo + published postmortems.

  8. What does a great EM at this firm actually do day-to-day - and what does great look like vs average?

    What it tests: Whether the candidate has internalized the actual devtools / infra EM job - 1:1s + hiring + RFCs + planning + cross-functional + on-call + community (if relevant) + customer comms - and can articulate the great-vs-average bar.

Technical concepts to master

Performance management + the underperformer playbook (infra layer)

1:1 cadence + structure
Weekly or bi-weekly 30-60 min 1:1 with each direct report; engineer drives the agenda, EM listens + coaches; covers work, career, blockers, feedback - and customer / on-call signal where relevant.
The underperformer playbook (with customer-impact lens)
Diagnose -> direct 1:1 -> coaching plan with checkpoints + scoped non-impact work to rebuild trust -> decision point -> formal PIP if needed -> improvement OR respectful transition.
Calibration + leveling (infra ladder)
Periodic cross-EM review of every engineer against the firm's ladder + peer set; ensures fairness + consistency on ratings + promotions; infra ladder weights API design, distributed-systems depth, production ownership, OSS contribution if relevant.
Career ladder + growth conversations (IC / OSS / EM tracks)
Each engineer should know their level, what the next level expects, and the specific gap; growth plans tracked + reviewed quarterly; OSS maintainer track is increasingly a recognised path at OSS-led firms.

Hiring + interviewing at the infra bar

Loop design + rubric
A typical loop: recruiter screen + hiring-manager call + technical screen (coding or take-home) + on-site (coding, system design at infra scale, behavioral, bar-raiser); each round has a defined rubric + signal.
Bar-raiser + debrief discipline
Non-hiring-team interviewer with veto power; debrief structured around evidence per signal, not gut feel.
OSS / community signal (where relevant)
For maintainer-track or OSS-leaning roles, public OSS contribution (PRs, RFCs, conference talks) is a legitimate signal alongside the loop - never the only signal, but corroborative.
Onboarding + the 30 / 60 / 90 (infra layer)
Structured first 90 days: onboarding buddy, scoped first project (often a low-risk infra change to build confidence), shadowed on-call before primary, weekly checkpoints, 30 / 60 / 90 milestones, formal review.

Technical strategy + API + platform roadmap

Multi-quarter strategy (devtools / infra flavor)
A 12-18 month thematic strategy laddering to org OKRs + customer outcomes; 2-3 themes (e.g. 'API stability + deprecation discipline', 'platform leverage for product teams', 'reliability ceiling').
Roadmap + allocation
Quarter-by-quarter bets with explicit allocation: feature work (e.g. 50%), platform + API + tech debt (e.g. 25%), reliability + on-call burn-down (e.g. 25%).
API + backward-compat budget
Explicit declaration of the deprecation window (6-18 months typical for paid infra), calendar for breaking changes, integration with v-next API surface, customer comms + tooling.
RFC + design-review discipline
Big bets get an RFC (written design with alternatives + tradeoffs); design reviews ensure senior + staff engineers weigh in before committing; for OSS-led firms, RFCs may go through public community review.

Cross-functional + OSS community + customer dynamics

PM + DX / Docs / DevRel partnership
PM owns what + why; EM owns how + when + team; DX / Docs / DevRel own the engineer-customer experience. Healthy: shared OKRs, joint roadmap, weekly sync, escalation discipline.
Customer success + TAM coordination (especially for major customers)
TAMs (technical account managers) own the strategic customer relationship; EM partners with TAM on incidents, API deprecations affecting that customer, multi-quarter roadmap visibility.
OSS community + maintainer relationships (where relevant)
At OSS-led firms, the EM partners with the maintainer team (sometimes inside the firm, sometimes external); navigates the project-vs-product line; protects the maintainer pool; addresses community signal honestly.
Stakeholder + exec + customer communication
Weekly status + risk-flagging; monthly strategy memo; quarterly business review; customer-facing summaries on material incidents; tone honest + concise, not status-theatre.

Practical drills

  • An engineer on your team has missed deliverables, owned a P0 that escalated to a major customer, and the team is starting to route around them. Walk me through what you'd do over the next 90 days.
  • You're the Senior EM for 2 teams (8 + 7 engineers) at this firm: one product team owning a customer-facing API surface, one platform team owning shared infra + the SDK. The org OKR is 'lift NRR by 5pts'. The API has 30% of customers on a behavior we'd like to deprecate. Walk me through your 12-month strategy + roadmap.
  • Your team is about to ship a paid-product feature - workspace-level governance + RBAC - that the OSS community has been requesting in the open-source project. Several prominent maintainers are arguing it 'belongs' in OSS. Walk me through how you'd navigate this over the next 4 weeks.

Smart-question anchors

  • Team + scope - the team's surface area, current challenges, what the EM would own in 6-12 months
  • API + platform discipline - backward-compat policy, deprecation cadence, RFC + API-review culture
  • OSS posture - OSS-led vs open-core vs proprietary; project-vs-product line; maintainer + governance model
  • Customer-SLO + on-call - SLO tiering, error budgets, customer-published postmortems, recent incidents
  • Performance + calibration + leveling - cadence, ladder, IC / OSS / EM tracks, bar-raiser in hiring + promo

Related roles

Sourced from

Ready to Generate Your Own Prep?

Drop your CV and a job description on the home page. A couple of minutes later you get a report with everything you need to land the job.

Generate my first prep