Engineering manager / tech lead interview questions

What is a weekly 1:1 with a developer for?

The strongest answer: Their meeting — concerns, growth, what is in their way — with a running agenda they own; status lives on the board

Why it works: Exactly. The 1:1 belongs to the report, and status has other homes.

• The 1:1 is theirs.
• Running agenda, owned by the report.
• Status goes on the board, not here.
• Move it, never drop it.

An interviewer says: “Design a URL shortener.” What do you do first?

The strongest answer: Ask what it must do and at what scale — reads vs writes, expiry, custom aliases, analytics — and state the assumptions you will design against before drawing anything

Why it works: Right. Requirements and numbers first; the boxes follow from them.

• Clarify functional and non-functional requirements first.
• State assumed scale in numbers.
• Only then draw.
• Check assumptions with the interviewer.

A senior developer left sharp, dismissive comments on a junior’s pull request.

When and how do you raise it?

The strongest answer: Privately within a day or two: the specific comment, the effect on the junior, and a question about what they intended

Why it works: Exactly. Fast, private, specific, and curious about their side.

• Feedback is soon and private.
• Behaviour, impact, then their view.
• Do not queue it for the 1:1.
• Do not broadcast a hint.

As tech lead, what is code review on your team for?

The strongest answer: Shared understanding and catching defects early — anyone reviews anyone, and the lead is not the only approver

Why it works: Exactly. Review spreads knowledge; a single-approver gate turns you into the bottleneck.

• Review spreads understanding.
• Anyone can review anyone.
• Automate style, discuss design.
• Never approve to save the number.

What does a load balancer do, and what does it not do?

The strongest answer: It spreads incoming requests across several identical servers and stops sending to ones that fail health checks; it does not make one slow server faster or fix a database bottleneck behind them

Why it works: Right. Distribution and failover, nothing more.

• Distributes requests across servers.
• Removes unhealthy servers.
• Not a cache, not capacity.
• Bottlenecks behind it remain.

You were the fastest developer on the team and were just made tech lead.

How much should you code now?

The strongest answer: Less, and off the critical path — small tickets and reviews so I can be interrupted to unblock people without holding a release

Why it works: Exactly. Stay technical, but never be the person a release is waiting on.

• Code, but off the critical path.
• Be interruptible.
• Do not hoard the hard tickets.
• Do not vanish from the codebase either.

What is the difference between scaling up and scaling out?

The strongest answer: Up means a bigger machine — simple, but there is a ceiling and one box to lose; out means more machines behind a balancer, which needs the service to be stateless or to share state elsewhere

Why it works: Right. Up is easy until the ceiling; out needs stateless services.

• Up: bigger box, ceiling, single failure.
• Out: more boxes, needs statelessness.
• Choose by state and ceiling.
• Neither is always right.

Product asks for an estimate for a new feature. How do you produce it?

The strongest answer: With the people who will build it: break it down together, note the unknowns, and give a range rather than a day

Why it works: Exactly. The builders estimate, and the unknowns are part of the answer.

• The builders estimate.
• Break it down, name unknowns.
• Give a range.
• Never adopt someone else’s date.

A developer asks why the team has coding standards at all. What do you tell them?

The strongest answer: So any of us can read and change any file: reviews then argue design, not style. We agree them as a team and let a formatter and linter enforce what they can

Why it works: Exactly — shared readability and cheaper reviews, with anything mechanical enforced by a tool rather than a person.

• Shared readability, enforced by tools.
• Agree them with the team.
• Automate format and lint.
• Review design, not style.

Two developers are blocked on another team’s access approval. What is your day?

The strongest answer: Unblocking them is my top priority today — I chase the approval myself and find them useful work meanwhile

Why it works: Exactly. Clearing blockers is the lead’s core work, not an interruption to it.

• Blockers are your work.
• Chase cross-team asks yourself.
• Keep people usefully busy meanwhile.
• Escalate as a step, not a reflex.

Why do interviewers keep asking whether a service is stateless?

The strongest answer: Because a stateless service keeps nothing between requests on its own box, so any instance can serve any request — that is what lets you add instances, replace a dead one and deploy without users noticing

Why it works: Right. Statelessness is what makes scaling out and failover trivial.

• Stateless: nothing kept between requests locally.
• Any instance serves any request.
• State moves to a shared store.
• Enables scale-out and failover.

You hand a piece of work to a developer. What do you actually hand over?

The strongest answer: The outcome, the constraints, and what they may decide alone, plus an agreed check-in — not a list of steps

Why it works: Exactly. Delegate the problem and the decision rights, then check in on purpose.

• Delegate outcome and constraints.
• Say what they may decide alone.
• Agree the check-in.
• Do not redo it in secret.

A developer has been missing expectations for two months. What is your first move?

The strongest answer: Work out why — unclear expectations, a skill gap, motivation, or something outside work — then set clear, written expectations with a short feedback loop

Why it works: Exactly. Diagnose, make expectations explicit, and give them a real chance with fast feedback.

• Diagnose before you act.
• Written expectations, short loop.
• Formal process is a later step.
• Do not manage by hoping.

You are designing the interview loop for a new backend role. What matters most?

The strongest answer: Define what the role needs, ask every candidate the same structured questions, score against one rubric, and collect scores before the debrief

Why it works: Exactly. Structure and a shared rubric are what make a loop fair and comparable.

• Define the role first.
• Same questions, one rubric.
• Independent scores before debrief.
• No puzzles, no mirror tests.

In the debrief, the most senior interviewer says a firm no before anyone else has spoken.

How do you run the debrief?

The strongest answer: Everyone submits written scores before anyone speaks, we weigh the evidence against the rubric, and as hiring manager I make the call and own it

Why it works: Exactly. Scores first, evidence over volume, and a named decider.

• Written scores before discussion.
• Evidence against the rubric.
• Hiring manager decides and owns it.
• Never hire out of fatigue.

An engineer asks what they need to do to be promoted. What do you tell them?

The strongest answer: Walk the ladder together, name the concrete gaps with examples, agree a plan with check-ins, and be honest that I cannot promise timing

Why it works: Exactly. Concrete gaps, a plan, and honesty about what you control.

• Use the ladder, with examples.
• Name the gaps concretely.
• Plan plus check-ins.
• Never promise a date you do not control.

A VP asks when the project will ship. What do you give them?

The strongest answer: A range, the assumptions behind it, the things that would move it, and the date by which I will narrow it

Why it works: Exactly. Ranges with named movers are honest and still useful to plan around.

• Range plus assumptions.
• Name what would move it.
• Say when you will narrow it.
• Do not quote the happy end.

Which delivery metrics do you look at, and what for?

The strongest answer: Lead time, deployment frequency, change-failure rate, and time to restore — as a team-level trend we discuss, never for ranking individuals

Why it works: Exactly. Flow and stability metrics belong to the team and guide the system, not the appraisal.

• Flow and stability, at team level.
• Trend, not target.
• Never per-person.
• Never for ranking.

Production is down and the team is on the call. What is your role as manager?

The strongest answer: Coordinate: make sure someone is commanding, own the communication outwards, make decisions the responders need, and keep noise away from them

Why it works: Exactly. Your job is coordination and shielding, not a fourth pair of hands on the keyboard.

• Coordinate and communicate.
• Shield the responders.
• Make the decisions they need.
• Root cause comes afterwards.

What makes a post-incident review worth doing?

The strongest answer: Blameless, focused on how the system allowed it, with a few action items that have owners and dates and get tracked

Why it works: Exactly. Systems, not people, and actions that actually get done.

• Blameless, always.
• Ask what the system allowed.
• Few actions, owned and dated.
• Track them to done.

How do you make room for technical debt alongside features?

The strongest answer: An explicit, visible share of capacity agreed with product, spent on the debt that causes the most pain or blocks the roadmap

Why it works: Exactly. Debt work is a negotiated, visible investment tied to actual pain.

• Explicit, visible capacity.
• Agree it with product.
• Target the debt that hurts.
• Never hide it.

You are writing a technical proposal for a change that touches three teams. What does it contain?

The strongest answer: The problem and goals, explicit non-goals, the options considered with their trade-offs, a recommendation, risks, rollout and rollback, open questions, and who decides by when

Why it works: Exactly — a proposal shows the thinking, not just the answer, so reviewers can engage with the trade-offs.

• Problem, options, recommendation, decision.
• State goals and non-goals.
• Options with fair trade-offs.
• Risks, rollout, rollback, deadline.

URL shortener: how do you generate the short code?

The strongest answer: Either hash the long URL and take the first characters, handling collisions by retry, or hand out pre-generated unique codes from a counter or key service; say which, and why — a counter gives guaranteed uniqueness but predictable codes, a hash is stateless but needs collision checks

Why it works: Right. Name the scheme and its trade-off.

• Hash-and-truncate or pre-generated keys.
• Handle collisions explicitly.
• Predictability vs statelessness.
• Length from the target count.

The team is split on how to structure a new service. How do you get to a decision?

The strongest answer: Write the options with their trade-offs and context, timebox the discussion, name who decides, and record the decision so we can revisit it

Why it works: Exactly. Written options, a decider, a timebox, and a record.

• Write options and trade-offs.
• Timebox and name the decider.
• Record the decision.
• Not a vote, not a shouting match.

Coaching has not worked and you are moving to a formal performance process. What does doing it well look like?

The strongest answer: Written, specific expectations they could recognise as met or not, real support and check-ins, HR involved from the start, and honesty about where it can end

Why it works: Exactly. Clear, supported, documented, honest — and a genuine chance to succeed.

• Specific, written expectations.
• Support and check-ins are real.
• HR from the start.
• Never build a case in secret.

A fifteen-year-old billing system must be replaced while it keeps invoicing every month.

How do you replace a large legacy system without a big-bang cut-over?

The strongest answer: Put a facade in front, route one capability at a time to the new system while the old keeps serving the rest, and retire the old pieces as traffic moves — the strangler fig pattern

Why it works: Exactly. Facade, incremental routing, measured retirement. Every step is reversible.

• Facade in front of the legacy.
• Move one capability at a time.
• Retire as traffic moves.
• Every step reversible.

You have to let a team member go. How do you do it?

The strongest answer: Prepared and private, clear and brief about the decision, with next steps and support ready, and a team message afterwards that protects their dignity

Why it works: Exactly. Prepared, humane, clear, and dignified in front of the team.

• Prepare, and do it yourself.
• Clear, brief, humane.
• Next steps ready.
• Protect their dignity with the team.

How do you make the case for two more engineers?

The strongest answer: Tie them to outcomes: what the team is asked to deliver, what will not happen without them, and the alternatives I considered such as descoping

Why it works: Exactly. Headcount is bought with outcomes and honest alternatives.

• Outcomes, not busyness.
• Say what will not happen otherwise.
• Show the alternatives.
• Do not pad the ask.

Your cloud bill has grown quarter on quarter and finance has asked you to explain it.

How do you handle it?

The strongest answer: Make the cost visible to the team by service, set a target with them, fix the biggest waste first, and balance it against the delivery we owe

Why it works: Exactly. Visibility, a shared target, biggest waste first, and a trade-off you own.

• Make cost visible per service.
• Set the target with the team.
• Biggest waste first.
• Do not blame, do not mandate blindly.

The team wants to rewrite the core service from scratch. How do you respond?

The strongest answer: Understand the pain concretely, then favour an incremental path — replace behind a seam piece by piece — and decide on evidence about risk and value

Why it works: Exactly. Name the pain, prefer incremental replacement, and decide on evidence.

• Understand the pain first.
• Incremental over big bang.
• Decide on evidence.
• Never freeze the business.

How do you decide whether to build or buy a component?

The strongest answer: Whether it is core to what differentiates us, the total cost including operation and lock-in, and whether the team has the capacity to own it well

Why it works: Exactly. Core versus context, whole-life cost, and honest capacity.

• Core or context?
• Total cost, including lock-in.
• Capacity to own it.
• Demos do not decide.

Your queue delivers at least once. What does that force on every consumer?

The strongest answer: Idempotency: each message carries a key and the consumer records what it has processed, so a redelivery after a crash or a slow ack is a no-op; you design the side effects to tolerate repeats rather than hoping for exactly-once

Why it works: Right. Repeats are certain; make them harmless.

• At-least-once means duplicates.
• Consumer keeps processed keys.
• Side effects tolerate repeats.
• Do not rely on exactly-once.

A team of twelve is getting slow. How do you split it?

The strongest answer: Along product or domain boundaries so each team can ship on its own, involve the team in the shape, and name a lead for each

Why it works: Exactly. Split for independent flow, with the team’s input and clear ownership.

• Split by domain, not layer.
• Each team can ship alone.
• Involve the team.
• Name the leads.

Which quality metrics do you actually use with your team?

The strongest answer: Defects that reach users, each recorded with the stage that should have caught it, alongside change failure rate — read as a trend with the team rather than as a target to hit

Why it works: Exactly — an escaped defect plus where it should have been caught points straight at the check to strengthen.

• Count what reaches users.
• Record where it escaped.
• Read it as a trend.
• Never per developer.

A hot cache key expires and 5,000 requests miss at once. Design against it.

The strongest answer: Coalesce: the first miss takes a lock or a single-flight slot and rebuilds while the others wait or serve the stale value; add early refresh before expiry with jittered TTLs so keys do not expire together; the database sees one read, not thousands

Why it works: Right. Single flight, stale-while-revalidate, jitter.

• One rebuild, others wait or serve stale.
• Refresh before expiry.
• Jitter TTLs.
• DB sees one read.

Placing an order touches inventory, payment and shipping services. How do you keep them consistent without one transaction?

The strongest answer: A saga: a sequence of local transactions with a compensating action for each step — reserve stock, charge, book shipping; if booking fails, refund and release; orchestrated by a coordinator or choreographed by events, with every step idempotent and the state persisted

Why it works: Right. Compensation, persisted state, idempotent steps.

• Local transactions with compensations.
• Orchestrated or choreographed.
• State persisted.
• Every step idempotent.

What principles guide how you design an engineering organisation?

The strongest answer: Teams aligned to value streams or domains they can own end to end, minimal handoffs, clear ownership, and an awareness that the org shape becomes the system shape

Why it works: Exactly. Ownership, flow, and an eye on Conway’s law.

• Align to value streams.
• Minimise handoffs.
• Clear ownership.
• Org shape becomes system shape.

You have been asked to reduce your organisation by a fifth of its roles.

How do you run it?

The strongest answer: Decide by role and business need with criteria I can explain, tell people quickly and directly with real support, and then rebuild trust honestly with the people who stay

Why it works: Exactly. Defensible criteria, direct and supported delivery, and honest work with the survivors.

• Explainable criteria.
• Direct, quick, supported.
• Never disguise the reason.
• Rebuild trust with the stayers.

Cloud spend is growing faster than revenue and nobody owns it. What do you set up?

The strongest answer: Tagging and allocation so every cost has an owning team, budgets with alerts per team, a regular review of the biggest lines with the engineers who can change them, and architecture standards for the recurring wastes

Why it works: Exactly. Ownership, budgets, regular engineering review, standards. A system, not an event.

• Every cost has an owner.
• Budgets and alerts per team.
• Regular review with engineers.
• Standards for recurring waste.

How do you build the annual engineering budget?

The strongest answer: From the strategy: what we must deliver, the headcount and non-headcount that needs, a couple of scenarios, and a reserve for what we do not know yet

Why it works: Exactly. Strategy-first, scenarios, and an honest reserve.

• Start from strategy.
• Headcount and non-headcount.
• Scenarios plus a reserve.
• Nothing hidden.

How do you keep a consistent hiring bar across ten teams?

The strongest answer: Calibrated interviewers, shared rubrics per level, a bar-raiser or independent voice in each loop, and periodic review of how the loops actually decide

Why it works: Exactly. Calibration, shared rubrics, an independent voice, and inspection.

• Calibrate interviewers.
• Shared rubrics per level.
• Independent voice in each loop.
• Inspect the loops.

You are asked to move a portfolio of two hundred applications to the cloud. How do you approach it?

The strongest answer: Inventory and classify by business value, risk and technical shape, assign each a path — retire, rehost, replatform, refactor, replace — sequence by dependencies and quick wins, and build a landing zone and a repeatable pipeline before the first wave

Why it works: Exactly. Classify, choose a path per application, sequence, and industrialise the mechanics first.

• Inventory and classify first.
• A path per application.
• Landing zone and pipeline before wave one.
• Learn on low-risk systems.

Design multi-tenancy for a product where some tenants are regulated.

The strongest answer: Tiered isolation: shared schema with a tenant key and row-level enforcement for most, and a separate database or cluster for tenants whose contract or regulation demands it — one code path, an isolation level chosen per tenant, with noisy-neighbour limits and per-tenant keys for encryption

Why it works: Right. One product, several isolation tiers.

• Isolation as a per-tenant tier.
• Shared with row-level enforcement.
• Dedicated where required.
• Same code path.

You run several teams. What tells you one of them is in trouble, before somebody resigns?

The strongest answer: On-call load and the share of unplanned work, how long changes wait, whether problems get raised in the open, who never takes leave — read together and checked in 1:1s, never as one score

Why it works: Right — load, flow, safety and leave, cross-checked with what people actually say; no single number carries that.

• Watch load, flow, safety, leave.
• Read the signals together.
• Confirm them in 1:1s.
• No single team score.

How do you limit the blast radius of a failure in a system serving millions?

The strongest answer: Cells: independent copies of the whole stack, each serving a slice of customers, with a thin routing layer; a bad deploy or a poison request takes out one cell, deploys roll cell by cell, and capacity grows by adding cells — at the cost of cross-cell features being hard

Why it works: Right. Isolation by cell; the cost is anything cross-cell.

• Independent full-stack cells.
• Customers pinned to a cell.
• Deploy cell by cell.
• Cross-cell features are the cost.

How do you run performance calibration across teams?

The strongest answer: Compare evidence against the ladder across teams, look actively for bias in the pattern, and refuse a forced distribution

Why it works: Exactly. Evidence, consistency, bias checks, and no quota.

• Evidence against the ladder.
• Consistency across teams.
• Look for bias.
• No forced curve.

How much should an organisation worry about cloud vendor lock-in?

The strongest answer: Decide deliberately per layer: accept lock-in where the managed service is a real advantage, keep data and interfaces portable, and know the exit cost of each big dependency — total avoidance costs more than most lock-in

Why it works: Exactly. Lock-in is a price you pay knowingly, per layer, with data portability as the line you hold.

• Decide per layer, deliberately.
• Keep data and interfaces portable.
• Know the exit cost.
• Total avoidance is its own cost.

Split a monolith into services without downtime — including the data.

The strongest answer: Strangler by capability: put a facade in front, carve one bounded context at a time, move its data by dual-writing into the new store while the monolith remains the source of truth, verify parity, flip reads, then writes, then delete; the database split is the real work, and the order of contexts is chosen by value and coupling

Why it works: Right. One context at a time, data migrated with parity checks.

• Facade, then one context at a time.
• Dual-write, verify, flip.
• Order by value and coupling.
• Delete the old path.