How to Approach Any Problem — The Questions Senior Engineers Ask

The difference between junior and senior isn't the answer — it's the questions first

Given "design X" or "make Y faster," a junior starts coding/drawing boxes. A senior engineer spends the first minutes narrowing the problem with questions, because the quality of any solution is capped by the quality of the understanding behind it. The questions also are half the score in an interview, and at work they prevent the most expensive mistake: building the wrong thing well.

The six questions, in order

Run these on any problem — a design, a bug, a feature, an outage.

1. Understand the real problem (before any solution)

• Can I restate it in one sentence? What exactly are we solving?
• Who is the user, and what is the real job-to-be-done behind the stated ask? (the classic X–Y problem: they ask for X because they think it solves Y — solve Y).
• What does "done" look like, and how will we measure success?
• What are we explicitly not doing? (scope boundaries)

2. Surface the constraints

• Scale: how many users / QPS / how much data? Read-heavy or write-heavy?
• Latency budget? Consistency needs (strong vs eventual)? Availability target?
• Security/compliance? Cost ceiling? Deadline? What's fixed vs negotiable?

3. Challenge assumptions

• What am I taking for granted? What would have to be true for my approach to work?
• What's the riskiest assumption — and can I test it cheaply before committing?

4. Decompose

• What are the independent sub-problems? (a MECE issue tree — mutually exclusive, collectively exhaustive)
• What's the core 20% that delivers 80% of the value? Solve that first.

5. Invert — the pre-mortem

• How could this fail? (run the 8 Fallacies + failure modes over it)
• What breaks at 10× / 100× load or data?
• What's the blast radius when it fails — and how do I contain it?

6. Find the simplest thing that works

• What's the simplest version that meets the real requirements? Do I actually need the distributed / sharded / cached version yet? (Simplicity is a senior signal; premature complexity is a junior one.)

Worked example: "make the dashboard faster"

A junior adds a cache. A senior asks:

• Faster for whom — p50 or p99? (averages hide the pain) · Which page/query? · How slow now, and what's the target? (no number = no goal)
• Where is the time actually going — the DB query, the network, or the render? → profile first; don't optimize blind (the Pareto rule).
• How much data, growing how fast? → is this an index problem (see Indexes-in-Practice), an N+1 query, or a payload-size problem?

Half those questions change the solution entirely. Then you design.

Takeaways

• Ask before you solve: understand → constraints → assumptions → decompose → invert → simplest.
• The X–Y problem and "no number = no goal" are the two traps; clarify the real goal and the metric.
• Inversion ("how does this fail / at 10×?") and "simplest thing that works" are what separate senior judgment.

---

Re-authored for this guide; approach-funnel diagram hand-authored as SVG. Synthesizes consulting issue-trees, first-principles/inversion (Munger), and the RESHADED/Hello-Interview clarification step. See also: The System Design Interview (RESHADED), Capacity Estimation, The 8 Fallacies, Designing for Failure.

I just read a lesson on **How to Approach Any Problem — The Questions Senior Engineers Ask** (System Design) and want to truly understand it. Explain How to Approach Any Problem — The Questions Senior Engineers Ask from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **How to Approach Any Problem — The Questions Senior Engineers Ask** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **How to Approach Any Problem — The Questions Senior Engineers Ask** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **How to Approach Any Problem — The Questions Senior Engineers Ask** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.