Technical Interviews
Architecture review interviews in Japan: critique a design without redesigning everything
Evaluate an existing architecture against explicit goals, failure modes, operations, and trade-offs, then propose changes with a validation plan.
Sources
What you can use right away
- Agree on quality priorities before judging components.
- Use concrete success and failure scenarios to expose design risk.
- Recommend the smallest justified change and explain how to validate it.
Architecture review is a different task from system design
A system design prompt asks you to build from a blank page. An architecture review gives you an existing design, history, or constraint set and asks whether it is fit for purpose. Resist replacing it with your favorite stack before you understand why it exists.
Open with five questions: who uses it, what must not fail, current scale, expected change, and which constraints are fixed. Then write the top quality priorities, such as reliability, security, latency, delivery speed, or cost.
Trace scenarios through the diagram
Use one normal scenario, one peak scenario, and one failure scenario. Follow data and control flow across boundaries. At each step, ask about ownership, consistency, capacity, timeout, retry, observability, and recovery.
A diagram alone does not prove a risk. Tie the concern to a scenario: "If the payment provider times out after charging, this synchronous retry can create a duplicate order because no idempotency key is shown."
Try this checklist
- Mark trust boundaries and stores containing sensitive data.
- Circle single points whose failure stops the user journey.
- Write the recovery owner and signal beside each major dependency.
Rank findings instead of listing possibilities
Use a short register: risk, triggering condition, impact, current control, proposed change, validation. Rank by impact and likelihood under the stated context. A global theoretical risk can be lower priority than a known operational bottleneck.
Separate fact from inference. "The diagram shows one database" is a fact. "It cannot meet availability goals" is an inference that needs workload, recovery, and deployment evidence.
Worked example: reviewing an interview scheduling service
Suppose the design writes a schedule, calls an external calendar API, and sends email in one request. A useful review asks what happens when the calendar call succeeds but the database write fails, whether repeated requests duplicate events, and how users learn that synchronization is delayed.
A measured proposal might store the requested schedule first, process calendar synchronization asynchronously with an idempotency key, and expose a pending state. State the trade-off: users may briefly see pending synchronization, but the system gains retry and auditability.
End each proposal with evidence
Do not stop at "add a queue" or "use microservices." Name the decision test: load test at an agreed peak, recovery drill, failure injection, cost comparison, security review, or a staged rollout metric. Architecture is a set of bets; validation shows how you will discover a bad one.
Close with the current design strengths, the top two risks, the next decision, and the evidence needed. This keeps the discussion constructive and makes your priorities visible.
Try this checklist
- Practice reviewing one design you built and one you inherited.
- Prepare a case where the right answer was to keep the current design.
- Record a two-minute review summary and remove unexplained jargon.
Common questions
Should you cover every Well-Architected pillar? Use the frameworks as prompts, not a recital; go deep on the stated priorities. What if the interviewer withholds scale? Offer two branches and say which fact would choose between them. Can you challenge a fixed constraint? Ask once, then evaluate within it.
A respectful critique is direct about risk and modest about missing context. That balance matters in any language and is especially useful when interviewing with a team whose decision history you do not know.