The Architecture Interview Nobody Prepared For

"Design Twitter." "Design Uber." We've all done these interviews. We draw boxes for Load Balancers, text for "Kafka," and some cylinder shapes for "Sharded Database." But does this actually prove you can build a system? Or does it just prove you've read "Designing Data-Intensive Applications"? Real engineering is about constraints, not boxes.

The Missing Pieces

Real architecture is rarely about drawing a perfect diagram on a whiteboard. It's about asking the right questions before you draw anything:

1. Constraint Discovery

The candidate who immediately starts drawing boxes fails. The Senior Architect asks: "What is the budget?", "What is the team size?", "What is the timeline?", "What are the compliance requirements?". Building a system for a 3-person startup is radically different from building for Google.

2. Failure Modes

Any junior can draw the happy path. I want to see you design for failure. What happens when the Redis cache evaporates? What happens when the 3rd party API goes down? How do we handle partial failures? "It just works" is not an answer. Implement circuit breakers, retry with exponential backoff, and dead letter queues.

3. The "Day 2" Problem

Designing the system is Day 1. Living with it is the rest of your life. How do we debug this distributed mess? How do we deploy it? How do we migrate data when the schema changes? Observability and operability are first-class architectural concerns.

CAP Theorem in Practice

Don't just recite the definition. Tell me about a time you sacrificed Consistency for Availability and why. Tell me why you chose Eventual Consistency for the 'Likes' counter but Strong Consistency for the 'Wallet balance'.

A Better Interview

Instead of "Design Twitter," I prefer: "Here is a broken system. Here are the logs. Tell me what's wrong and how to fix it." Or, "Here is a feature request. Tell me why we shouldn't build it." These questions test pragmatism, experience, and the ability to say "no"—the most important word in an architect's vocabulary.

Hire engineers who understand trade-offs, not just tools.