Architecture and interview playbook

Interviewers want to see structured judgment, not a service-name race.

Use REQUIRE

• R — Requirements: users, business outcome, scale, latency, RTO/RPO.
• E — Environment: current systems, skills, Regions, compliance.
• Q — Qualities: security, reliability, cost, operability, sustainability.
• U — Unknowns: state assumptions and ask clarifying questions.
• I — Interfaces: APIs, events, data ownership, failure behavior.
• R — Recommendation: show a simple end-to-end design.
• E — Evidence: testing, observability, cost, rollout, and alternatives.

A strong answer sounds like this

“I would first confirm whether an immediate SAP response is required. If it is not, I would accept the order through a regional API, commit a durable order record, and queue SAP work in SQS. This isolates campaign spikes and permits controlled retries. The trade-off is eventual confirmation, so the customer experience and reconciliation process must show pending and failed states. I would prove it with load tests, queue-age alarms, idempotency tests, and a game day where SAP is unavailable.”

Questions you should be ready for

1. Design a global customer-facing platform.
2. Connect AWS with SAP, Salesforce, and Workday.
3. Design a secure multi-account landing zone.
4. Explain Multi-AZ and Multi-Region.
5. Migrate a legacy application with little downtime.
6. Reduce cloud cost without weakening reliability.
7. Respond to a leaked credential or public bucket.
8. Choose Lambda, ECS, EKS, or EC2.
9. Choose RDS/Aurora, DynamoDB, and a cache.
10. Handle duplicated events and downstream outages.

Behavioral stories

Prepare concise STAR stories about: influencing without authority, reversing a decision after new evidence, handling an incident, explaining a trade-off to a non-technical stakeholder, reducing cost, and raising a security concern.

Whiteboard discipline

Draw users and external systems first, then boundaries, the normal request path, data stores, asynchronous paths, observability, and failure behavior. Add service names only after the responsibilities are clear.