What impresses interviewers (and red flags)
In one line
Interviewers are impressed by judgement they can see: numbers that drive choices, simple designs, honest trade-offs, failure thinking and operational sense; they are put off by buzzwords, rigidity and ignoring the problem in front of you.
What it is
Strong-hire feedback in design rounds usually contains the same phrases: 'drove the discussion', 'used estimates to make decisions', 'identified the real bottleneck early', 'proactively covered failure modes', 'adjusted well to new constraints'. These come from specific behaviours you can practise.
Red flags are just as consistent: drawing before asking, naming technologies without reasons, designing for imaginary scale, hand-waving consistency ('we will use Kafka so it is exactly-once'), ignoring hints, and not knowing how anything fails or is monitored.
In the AI era, interviewers also listen for whether you understand systems you did not write line by line: where an LLM call fits, what it costs, how it fails, how you evaluate it. Being able to reason about architecture matters more as code becomes cheaper to produce.
Why interviewers ask
Two candidates can draw nearly the same diagram and get opposite results. The difference is in how they got there and what they said about it. Knowing what reads as strong and what reads as a red flag lets you avoid losing a round you technically solved.
How it works
- 1Open with structure: a 20-second plan ('requirements, numbers, API, data, high-level, then deep dives on X and Y'). It shows you can lead.
- 2Let numbers change the design: say 'this is 360k writes per second, so a single primary is out'. Interviewers remember the moment estimates drove a choice.
- 3Start simple and add complexity only with a reason. Saying 'one Postgres is enough here until about N writes per second' is more impressive than a 15-box diagram.
- 4Be precise about guarantees: say 'at-least-once delivery with idempotent consumers gives effectively-once processing' instead of 'exactly-once'. Say which reads can be stale and for how long.
- 5Bring up failure before being asked: what happens when the cache, a region, a consumer or the payment provider fails; timeouts, retries with backoff and jitter, circuit breakers, graceful degradation.
- 6Show operations sense: key metrics (p99 latency, error rate, queue lag), SLOs, alerts, gradual rollouts with feature flags, and how you would debug an incident.
- 7Mention cost when it matters: CDN egress, SMS fees, LLM tokens, storage tiers. Senior engineers are expected to design within a budget.
- 8Adapt to new constraints gracefully: 'Good point, that changes the partition key; here is the new one and what it costs us.'
Worked example · Two answers to 'How does your notification system handle retries?'
- Weak answer: 'We put messages in Kafka, so they are delivered exactly once, and we retry on failure.' This hand-waves both delivery semantics and retry behaviour.
- Strong answer, part 1: 'Kafka gives at-least-once to our consumer, so a crash after sending but before committing the offset will resend. Each notification has an ID, and we record it in Redis with SET NX and a 24-hour TTL before calling the provider, so duplicates are dropped.'
- Part 2: 'Provider calls have a 2-second timeout. Failures go to a retry topic with exponential backoff and jitter, at most 5 attempts, then to a dead-letter topic with an alert.'
- Part 3: 'If the SMS provider error rate passes 20% for a minute, a circuit breaker opens and we switch to a secondary provider; OTPs have their own high-priority lane so a marketing backlog never delays them.'
- Part 4: 'We track send success rate per provider, end-to-end OTP latency at p99, and retry topic lag, with an alert if OTP p99 passes 10 seconds.'
- The second answer is longer by only a minute, but it contains five pieces of evidence an interviewer can write down.
Picture it
It is like a cricket commentator compared with a fan. Both watch the same ball, but the expert explains why the bowler changed length, what the field setting allows, and what happens if the batter misses. The interviewer is listening for the expert's commentary on your own design.
Key patterns
Say the why
When: Every component and choice
How: Follow each choice with 'because' and a requirement or number. 'Redis, because we need 50k reads per second under 5 ms and can lose a few seconds of counts.'
Proactive failure pass
When: After the high-level design and after each deep dive
How: Walk the diagram box by box and ask 'what if this is slow or down?' Give detection and mitigation for the top two or three.
Precise guarantees
When: Discussing queues, replication and caches
How: Name the delivery semantic, the consistency level and the staleness window explicitly instead of using vague words like 'reliable' or 'real time'.
Real-world use
Google SRE practices
Google's SRE book popularised SLOs, error budgets and blameless postmortems. Mentioning an SLO and how you would alert on it is a simple way to show operational maturity.
AWS Builders' Library
Amazon's articles on timeouts, retries with backoff and jitter, and avoiding fallback in distributed systems are a good source of precise failure-handling language for interviews.
Kafka exactly-once semantics
Kafka's transactions give exactly-once processing only for read-process-write flows inside Kafka. Any side effect outside Kafka, such as a payment or an email, still needs idempotency. Saying this correctly is a common strong-hire moment.
AI features in production
Teams shipping LLM features route calls through a gateway with timeouts, fallbacks between models, budgets per tenant and tracing. Discussing these, rather than treating the LLM as a magic box, impresses in AI-era design rounds.
In a project
You keep reaching the final round and getting 'lean no hire' with feedback like 'design was fine but lacked depth and seemed rehearsed'.
- Replace memorised architectures with reasoning: for each practice problem, write the two numbers and one requirement that drive the design.
- Prepare a short failure checklist (dependency down, retry storm, hot key, data loss, region loss) and apply it to every mock.
- Practise precise wording for guarantees, consistency and delivery semantics until it is automatic.
- In mocks, have your partner add a surprise constraint at minute 25 and practise adapting calmly.
- End every mock with metrics, SLOs and a rollout plan in under two minutes.
Impact: Feedback starts to mention 'proactively covered failure modes' and 'adapted well to new constraints', the evidence that turns a lean no-hire into a hire.
Trade-offs
Use it when
- Practising for any design round from SDE-2 upwards
- Reviewing mock interview recordings
- Preparing short stories about systems you have run in production
Avoid it when
- Name-dropping papers or technologies you cannot explain in depth; follow-up questions will expose it
- Covering every impressive topic at the cost of finishing the core design
Common mistakes
- Buzzword architecture: Kafka, Kubernetes, microservices and Cassandra with no link to requirements.
- Claiming exactly-once, zero downtime or 100% availability.
- Ignoring the interviewer's numbers and designing for a different problem.
- Defending a choice after a new constraint makes it wrong.
- Never mentioning monitoring, alerts or rollout.
- Long silences while thinking; think aloud instead.
- Treating an LLM or third-party API as always fast, cheap and correct.
Interview questions
Quick revision
- Open with a short plan, then follow it.
- Let numbers drive at least two decisions out loud.
- Simple first; add complexity only with a reason.
- Precise words: at-least-once plus idempotency, staleness windows, p99.
- Do a failure pass without being asked.
- Metrics, SLOs, alerts and gradual rollout.
- Mention cost: egress, SMS, LLM tokens, storage tiers.
- Adapt to new constraints; do not defend old choices.
- Red flags: buzzwords, 'exactly-once', no questions, silence, ignoring hints.
Check yourself
1. Which statement is a red flag?
2. When is the best time to discuss failure modes?
3. The interviewer adds 'users are mostly on 2G networks in rural areas'. What is the best response?
4. Which shows operational maturity most clearly?
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.