Learning objectives
- Whiteboard a quote API with asynchronous document generation.
- Investigate a customer report of intermittent 502 responses.
- Apply Assumption register to a customer decision and defend the tradeoff.
The mental model
An architecture interview tests how you turn uncertainty into a defensible design. A debugging interview tests how you turn symptoms into evidence and action. In both, begin by clarifying the goal, constraints, and success criteria. Draw a simple path before adding components. Explain what you know, what you assume, and what you would verify. A whiteboard is a shared reasoning surface, not an art contest. The interviewer should be able to follow a request, identify the state owner, and understand a failure path. Good answers leave room for feedback and revise gracefully when new information changes the problem.
How it works
For architecture, ask about users, traffic shape, data sensitivity, consistency, latency, reliability, existing systems, and operational capacity. Choose a baseline design, then examine bottlenecks and trust boundaries. Label synchronous calls, asynchronous work, authoritative stores, and control points. Present one alternative with a concrete reason to choose it under different constraints. Do not multiply components merely to sound senior.
For debugging, scope the failure by time, affected population, and change history. Follow the request from DNS through connection, TLS, proxy policy, cache, application, and dependency as relevant. State hypotheses with predicted evidence and choose the lowest-risk discriminating test. Keep mitigation separate from complete explanation. In both formats, manage time: spend enough on discovery to avoid solving the wrong problem, then move to a provisional answer. If you do not know a product limit, state the architectural dependency and the official documentation or test you would use to verify it. End by summarizing the decision, tradeoffs, and remaining assumptions rather than introducing new features.
When the interviewer changes a constraint, restate what changed and identify the affected decision. If immediate consistency becomes mandatory, revisit the state path; if the team has two engineers, revisit operational complexity; if traffic is bursty, revisit admission and asynchronous work. This shows adaptable reasoning. Do not defend the first diagram simply because you drew it. Preserve the parts that still satisfy requirements and explain the smallest revision that addresses the new information.
Applied example · hypothetical
Hypothetical mock: design a globally used quote API that stores approved quotes and generates documents. You clarify that approval must be durable while document generation may be asynchronous. Draw client, ingress, API, authoritative database, queue, and renderer. When the interviewer adds a slow signing provider, you discuss deadlines, idempotency, and pending status. In the debugging variation, failed documents begin after a deployment; you request queue age, worker errors, and version comparison. You do not redesign the entire system before isolating the change.
In a customer engagement
Customer whiteboarding uses the same habits. Invite the customer to correct the current-state diagram before presenting a future state. Mark uncertain paths visibly and confirm the owner of each system. Keep an executive explanation ready: which workflow improves, which risk is reduced, what changes operationally, and what evidence will validate the proposal.
Interview relevance
Practice a fifteen-minute architecture answer and a ten-minute incident investigation. Record whether you clarified requirements, stated assumptions, considered failure, and invited feedback. Do not grade yourself on the number of products named. The strongest senior signal is a coherent decision that adapts to evidence and includes an honest validation plan.
Common mistakes
- Starting with every available product
- Leaving completion semantics ambiguous
- Assuming every 502 is a WAF block
Key terminology
Assumption register — A visible list of unverified premises that materially affect an architecture or decision.
Discriminating test — A test whose possible results help distinguish between competing hypotheses.
Whiteboard contract — The shared understanding of what diagram symbols, boundaries, and assumptions mean during a discussion.
Explain it without the page
- Whiteboard a quote API with asynchronous document generation.
- Investigate a customer report of intermittent 502 responses.
Further reading
Sources explain the underlying concepts; examples and practice answers are original course material. Recheck current limits and plan eligibility before a real proposal.