Senior interviews are difficult because the answer is rarely a fact or an algorithm. The interviewer is trying to understand how you make decisions when requirements are incomplete, how you communicate trade-offs, and whether you improve the system and the people around you. The questions below cover junior foundations, mid-level trade-offs, and senior-level design and incident leadership.
How to read the examples: the guidance is [ANALYSIS]. Any quoted metric or personal outcome is an [ILLUSTRATIVE ASSUMPTION], not a claim about a particular company or system. Replace it with evidence from your own work. A useful senior answer explains the decision, the rejected alternative, the result, and the guard that prevents recurrence.
Junior: foundations
Q1. “Tell me about yourself.” How do you stay concise?
[ANALYSIS] Use a short three-part structure: your current scope and stack, one recent outcome, and why this role fits. [ILLUSTRATIVE ASSUMPTION] “I work on Java services and care about reliability. I reduced a service’s p99 from 800 ms to 120 ms. This role matches the distributed-systems problems I want to solve.” Avoid a life story. Describe problems you solve, not every technology you have touched.
Q2. “What is your biggest weakness?”
[ANALYSIS] Choose a real weakness that is manageable, then explain the process you use to reduce its impact. [ILLUSTRATIVE ASSUMPTION] “I used to underestimate migration risk. Two of my first five releases rolled back, so I now prototype the risky path first; my last four migrations had no rollback.” Do not use a disguised strength such as “I work too hard.”
Q3. “Where do you see yourself in five years?”
[ANALYSIS] Talk about scope and judgment rather than a title. [ILLUSTRATIVE ASSUMPTION] “I want to own difficult architectural decisions, lead a 10x scale-up while keeping p99 below 200 ms, and mentor four engineers toward similar scope.” The point is leverage, not a promotion list.
Q4. “Why do you want this job?”
[ANALYSIS] Connect the role to a verified problem domain, scale, or working model. If you do not have a reliable public number, do not invent one. [ILLUSTRATIVE ASSUMPTION] “The payments domain would let me go deeper on distributed consistency.” Name two facts you actually verified and explain why they matter to you.
Q5. “Describe a bug you fixed.”
[ANALYSIS] Use symptom, reproduction, root cause, fix, and guard. [ILLUSTRATIVE ASSUMPTION] “A cache defect raised p99 from 120 ms to 800 ms. A 200-line stress test reproduced it; the cause was a missing expireAfterWrite bound. I fixed it, added a cache-size alert, and p99 remained below 130 ms for six months.” End with the regression test, alert, or invariant that protects the fix.
Q6. “What do you do when you are stuck?”
[ANALYSIS] Use a repeatable escalation path: time-box a minimal reproduction, isolate variables with a bisect or simplification, read the actual error and source, then ask one specific question with evidence. [ILLUSTRATIVE ASSUMPTION] “I make three attempts of 15 minutes each, then send the minimal reproduction; most blockers are answered within 10 minutes.” The process matters more than the exact threshold.
Q7. “What would your first 90 days look like?”
[ANALYSIS] Give milestones. [ILLUSTRATIVE ASSUMPTION] In the first 30 days, learn the codebase, on-call rotation, and two incident reviews, then deploy a low-risk change. From day 30 to 60, shadow production traffic and fix a medium bug. From day 60 to 90, own one feature end to end. Do not stop at “learn the stack.”
Q8. “When is it okay to ask for help?”
[ANALYSIS] Ask before a blocker becomes expensive, but bring evidence. [ILLUSTRATIVE ASSUMPTION] Use a 15-minute solo attempt, record what failed, and ask a focused question with a short reproduction. A good question can turn an hour of stalled work into 10 minutes of guidance.
Q9. “What does owning a bug mean?”
[ANALYSIS] Ownership includes reproduction, remediation, regression protection, and communication. [ILLUSTRATIVE ASSUMPTION] A data-corruption bug may take six hours to fix and two more to add a regression test and alert; the work is complete when the bug class is prevented, not when the ticket leaves your queue.
Q10. “How do you say ‘I don’t know’?”
[ANALYSIS] Say it directly, then give a verification plan and a bounded hypothesis. [ILLUSTRATIVE ASSUMPTION] “I do not know that from memory. I would check X; my initial estimate is Y, and I would verify it within 30 minutes.” Do not bluff.
Q11. “What makes a good code-review comment?”
[ANALYSIS] A useful comment teaches or exposes risk. Ask a question instead of rewriting the code: “Why is this map unbounded?” [ILLUSTRATIVE ASSUMPTION] Keep a review below 400 lines, limit substantive comments to 3–5, and measure whether review time improves. Review is a teaching mechanism, not a linter output.
Q12. “How much testing do you write?”
[ANALYSIS] Allocate tests according to risk, not a universal coverage target. [ILLUSTRATIVE ASSUMPTION] A money path might require 100% branch coverage, core logic about 80% unit coverage, and one integration test per critical flow, while boilerplate has about 20%. Coverage is a risk budget.
Q13. “How do you learn an unfamiliar codebase?”
[ANALYSIS] Trace one request from entry point through service layer, data layer, and response before changing code. [ILLUSTRATIVE ASSUMPTION] Follow a small user-visible flow through 5–6 layers, draw a one-page map, and identify 2–3 high-risk files. Read the tests; they are often the most accurate documentation.
Q14. “What do you log and alert on?”
[ANALYSIS] Log request ID, duration, error class, and the relevant business value at suitable levels. Alert on user-visible symptoms, not every possible cause. [ILLUSTRATIVE ASSUMPTION] An alert might fire when error rate exceeds 1% or p99 exceeds 300 ms for five minutes. Review alert noise and keep the signals actionable.
Q15. “How do you keep commits reviewable?”
[ANALYSIS] Keep each commit small, single-purpose, and clearly named. [ILLUSTRATIVE ASSUMPTION] A 900-line refactor may be split into six coherent commits, each below 200 changed lines where practical. A readable history helps reviewers reconstruct intent.
Q16. “How do you estimate a task?”
[ANALYSIS] Decompose the work, estimate the riskiest step separately, and state confidence and dependencies. [ILLUSTRATIVE ASSUMPTION] Four steps may total five days with a one-day uncertainty range, including two days for a migration and one day for rollback work. An estimate is not a promise without assumptions.
Q17. “Tell me about a mistake.”
[ANALYSIS] Choose a real mistake, own the outcome, and show the durable process change. [ILLUSTRATIVE ASSUMPTION] A migration without a tested rollback corrupted 1,000 rows and required three hours to recover; the follow-up was a postmortem and tested rollback for the next 12 migrations. Do not blame the deploy system or deadline.
Mid-level: trade-offs and execution
Q18. “How do you prioritize when everything is urgent?”
[ANALYSIS] Compare impact, affected users, and reversibility, then publish the order. [ILLUSTRATIVE ASSUMPTION] A data-corruption issue affecting 2 million users outranks cosmetic UI work; a reversible configuration change outranks an irreversible delete. Use buckets such as today, this week, and later.
Q19. “How do you handle technical debt?”
[ANALYSIS] Make it visible, owned, budgeted, and tied to code you are already changing. [ILLUSTRATIVE ASSUMPTION] A team may reserve 20% of capacity and reduce five hotspots in a quarter, cutting average bug-fix time from two days to one. The exact allocation depends on the team.
Q20. “Tell me about a disagreement with a colleague.”
[ANALYSIS] Show that you listened, argued from evidence, and committed after the decision. [ILLUSTRATIVE ASSUMPTION] A benchmark at 1,000 messages per second with two workers might show one queue library at p99 below 50 ms and another at 200 ms; you can still adopt the colleague’s retry design. Do not frame the story as winner versus loser.
Q21. “How do you handle a vague or changing requirement?”
[ANALYSIS] Write down plausible interpretations, choose the cheaper-to-reverse slice, ship it, and learn. [ILLUSTRATIVE ASSUMPTION] A thin version may ship in three days and reveal that the original interpretation was wrong, avoiding two weeks of rework. Speed of learning is the goal.
Q22. “What technical decision do you regret?”
[ANALYSIS] Explain what you believed, what evidence changed your view, and what you do now. [ILLUSTRATIVE ASSUMPTION] Four abstraction layers built for unused flexibility may take three weeks and later be removed. Prefer the simplest design that meets the current requirement; add seams when a real need appears.
Q23. “How do you balance delivery and long-term health?”
[ANALYSIS] Make the shortcut explicit, bounded, and scheduled for follow-up. [ILLUSTRATIVE ASSUMPTION] Ship 80% now to gain two weeks of runway, then schedule the remaining 20% within one month. A shortcut without an owner and date is unmanaged debt.
Q24. “A stakeholder wants a two-week feature in one week.”
[ANALYSIS] Present the trade-off table: full scope in two weeks, reduced scope in one week, or full scope with explicit reliability risk. [ILLUSTRATIVE ASSUMPTION] A 70% slice may fit the week; full scope might add two days of incident debt and 40% estimated bug risk. Let the stakeholder choose the cost.
Q25. “Tell me about mentoring someone.”
[ANALYSIS] Show increased capability, not the work you performed for them. [ILLUSTRATIVE ASSUMPTION] Pair for two hours weekly over three months, let the engineer own the first three PRs of each feature, and measure progress from a four-day review cycle to one day. Use the person’s real outcome.
Q26. “How do you delegate work you could do faster?”
[ANALYSIS] Delegate when the learning value and future capacity outweigh the short-term cost. [ILLUSTRATIVE ASSUMPTION] Someone delivering 80% of your quality in the time you need for 100% may be the right owner. Review the result without taking the work back; otherwise you remain the bottleneck.
Q27. “What do you do when you will miss a deadline?”
[ANALYSIS] Tell stakeholders as soon as the risk is known and offer options. [ILLUSTRATIVE ASSUMPTION] On day eight of a 15-day plan, you may offer to cut analytics or move the date by one week. Early information preserves choices; late information removes them.
Q28. “How do you say no?”
[ANALYSIS] Preserve the goal, explain the constraint, and identify what must move. [ILLUSTRATIVE ASSUMPTION] “This requires X, and the queue is already three weeks; which item should slip?” A reasoned no is part of reliable planning.
Q29. “How do you balance process and output?”
[ANALYSIS] Keep process that demonstrably reduces risk or waste; remove process that does not. [ILLUSTRATIVE ASSUMPTION] A deploy checklist might reduce rollbacks from eight per quarter to one, while shortening a 30-minute stand-up to 10 minutes may preserve the same information. Revisit ceremonies periodically.
Q30. “How do you handle rework?”
[ANALYSIS] Treat rework as a signal about an earlier missing step. [ILLUSTRATIVE ASSUMPTION] If 15% of work is reworked and 80% traces to ambiguous requirements, a one-page pre-coding specification might reduce rework to 4%. Fix requirements or architecture before demanding more speed.
Q31. “What is your approach to monitoring and alerting?”
[ANALYSIS] Design for actionable alerts, clear symptoms, and a runbook for each page. [ILLUSTRATIVE ASSUMPTION] Consolidating 40 alerts into eight SLO-based alerts could reduce pages by 70%. Alert fatigue is an operational defect.
Q32. “How do you document decisions?”
[ANALYSIS] Write an ADR when the decision is made: context, alternatives, constraints, evidence, and consequences. [ILLUSTRATIVE ASSUMPTION] A one-page ADR can compare two options, including one that costs 30% more CPU but keeps p99 below 200 ms. Document why, not just what.
Q33. “What if users do not want a feature that took three weeks?”
[ANALYSIS] Own the miss, stop further investment, and change validation. [ILLUSTRATIVE ASSUMPTION] If only 0.1% of users use a reporting page, remove it and add five user interviews before future builds. The lesson is useful only if the workflow changes.
Q34. “How do you prevent burnout?”
[ANALYSIS] Treat sustainable pace as a reliability control. [ILLUSTRATIVE ASSUMPTION] After an incident-heavy month, reduce planned work by 30% or extend a sprint from two weeks to three; output may remain stable if hotfixes and rework fall. Do not normalize long hours as a capacity plan.
Senior: design, incidents, and leverage
Q35. “Describe a production incident you led.”
[ANALYSIS] Give a timeline: detection, containment, root cause, durable fix, and follow-up. [ILLUSTRATIVE ASSUMPTION] At 02:10, p99 is 800 ms and errors are 12%; within 10 minutes you roll back and shed 30% of traffic. At 03:00, an unbounded cache is identified; a bounded Caffeine cache with a 10,000-entry cap and a size alert restores p99 to 120 ms. A two-page postmortem and tracked actions can improve MTTR from 40 minutes to 15.
Q36. “How do you communicate during an incident?”
[ANALYSIS] Communicate symptoms, actions, and impact at a predictable interval. [ILLUSTRATIVE ASSUMPTION] Post a three-line update every 15 minutes and assign one communications owner: “Checkout errors are 12%; we are rolling back the 09:15 deploy; 2,000 customers are affected.” Keep responders focused while stakeholders stay informed.
Q37. “What does systems thinking mean?”
[ANALYSIS] Trace the full request path: client, gateway, services, database, cache, and queue. Consider upstream and downstream effects. [ILLUSTRATIVE ASSUMPTION] Adding retries could double consumer queue depth; a circuit breaker may contain the failure instead. Model retry storms, timeout budgets, fallback behavior, and backpressure before deployment.
Q38. “How do you design for 10x current load?”
[ANALYSIS] Design explicit seams and measure the current bottleneck; do not build an unverified architecture for a hypothetical scale. [ILLUSTRATIVE ASSUMPTION] A system measured at 100 requests per second may prepare for 1,000 by caching the hottest 20% of reads and sharding the queue by key. The future change should be a controlled configuration or targeted tuning, not an assumed rewrite.
Q39. “How do you explain latency to non-technical stakeholders?”
[ANALYSIS] Translate latency into customer and business impact using verified data. [ILLUSTRATIVE ASSUMPTION] “At 800 ms, checkout completion falls by about 6%, worth roughly $6,000 per month; a two-week cache change could reduce latency to 120 ms.” Do not present the business conversion as fact unless you measured it.
Q40. “Tell me about a decision made with incomplete information.”
[ANALYSIS] State what was known, unknown, considered, chosen, and how the downside was bounded. [ILLUSTRATIVE ASSUMPTION] With 45 minutes and partial monitoring, fail over to a backup region only if the action is reversible in 10 minutes and instrumented; a kill switch might cap the downside at 20 minutes of double latency. The method is reversible action plus fast feedback.
Q41. “How do you defend an architecture decision?”
[ANALYSIS] Use a trade-off table, failure modes, and reproducible measurements rather than seniority. [ILLUSTRATIVE ASSUMPTION] Option A may use 30% more CPU while keeping p99 below 200 ms; option B may be cheaper but reach 900 ms under load. A five-minute staging test is evidence, not proof of production behavior.
Q42. “How do you set and enforce SLOs?”
[ANALYSIS] Treat the SLO as a shared service contract with an error budget. [ILLUSTRATIVE ASSUMPTION] A 99.9% monthly availability target corresponds to a 43-minute monthly budget. Product and engineering decide what to delay when the budget burns; alert on burn rate rather than every individual error.
Q43. “How do you run a postmortem that changes behavior?”
[ANALYSIS] Keep it blameless, written, and action-tracked: timeline, causal analysis such as the five whys, and 2–3 actions with owners and dates. [ILLUSTRATIVE ASSUMPTION] A bounded cache and size alert might both ship within two weeks. An action without an owner is not a plan.
Q44. “How do you raise the level of engineers around you?”
[ANALYSIS] Build mechanisms: questions in reviews, design documents, and blameless incident reviews. [ILLUSTRATIVE ASSUMPTION] A weekly one-hour design review may reduce rework from 15% to 5% over six months. Success is a team that makes good decisions without depending on your comments.
Q45. “How do you make yourself replaceable?”
[ANALYSIS] Turn private knowledge into team knowledge through documentation, runbooks, ADRs, and shadowing. [ILLUSTRATIVE ASSUMPTION] Two engineers should be able to cover each service you own; a two-week absence should not require paging you. Replaceability removes a dependency and increases your scope.
Q46. “Tell me about improving on-call.”
[ANALYSIS] Audit pages, distinguish causes from symptoms, add runbooks, and automate safe remediation. [ILLUSTRATIVE ASSUMPTION] If there are 25 pages per week, 80% are cause-based, and half lack runbooks, reducing the set to eight SLO-based alerts could produce a 70% reduction. Measure both noise and response time.
Q47. “How do you lead without authority?”
[ANALYSIS] Make the evidence easy to inspect and start with a small pilot. [ILLUSTRATIVE ASSUMPTION] A one-page RFC, four early one-on-ones, and a pilot on one service could support moving three services to a queue library. A benchmark such as 2x throughput and p99 of 50 ms versus 200 ms is useful only if the test is reproducible.
Q48. “What does career growth look like for a senior?”
[ANALYSIS] Increase scope and leverage, either by deepening a technical domain or widening influence. [ILLUSTRATIVE ASSUMPTION] A cache fix saving $6,000 per month in one service might become a shared library used by three teams. Choose an IC or management path deliberately; the measure is the radius of your decisions, not the title alone.
Q49. “How do you handle ambiguity at the organization level?”
[ANALYSIS] Convert a vague goal into questions, owners, deadlines, and a thin plan. [ILLUSTRATIVE ASSUMPTION] For “improve reliability,” ask what breaks most, what costs most, and what can ship in one quarter; an SLO plan may deliver two of three items and reduce incidents by 50%. State the assumptions and revise them as evidence arrives.
Q50. “What does senior mean in one sentence?”
[ANALYSIS] “Senior means making sound decisions under uncertainty, owning the outcome, and increasing the capability of the people around you.” Support the sentence with one short, measured story: a latency improvement, fewer pages, or an engineer who can now ship independently. Judgment, ownership, and leverage are the core signals.
Self-check
- Junior: I can introduce my scope, discuss a real weakness and mitigation, explain a bug through its guard, describe how I get unstuck, and own a mistake.
- Mid-level: I can prioritize by impact and reversibility, present deadline trade-offs, mentor with an outcome, delegate for growth, and turn rework into a process fix.
- Senior: I can lead an incident, translate technical impact into business impact, set SLOs and error budgets, run an action-tracked postmortem, and raise team capability through mechanisms.
- I label illustrative metrics as assumptions and replace them with evidence from my own work.
- I can define seniority in one sentence and support it with a concise story.