Senior engineer interview prep — the 5 question patterns.

01Pattern 1 — System design

"Design a URL shortener." "Design Twitter's feed." "Design a rate limiter." Almost every senior interview has at least one of these. The interviewer isn't checking whether you've memorized the solution — they're checking how you decompose an ambiguous problem under pressure.

The structure that works:

1. Clarify scope (3-5 minutes). What's the read:write ratio? Expected QPS? Latency targets? Any specific constraints (regulatory, geographic, cost)? Take notes.
2. Sketch the API (3-5 minutes). What's the public interface? GET, POST, request/response shapes. This grounds the rest of the design.
3. Draw the high-level architecture (10 minutes). Client → load balancer → application → data layer. Caching where it helps. Don't optimize prematurely.
4. Deep-dive on the bottleneck (10 minutes). Pick the hardest part and discuss it in detail. Database sharding strategy. Cache eviction policy. Consistency model.
5. Address scale and failure (5 minutes). What happens at 10x traffic? What happens when a node dies? What's the data loss tolerance?

The mistake people make: jumping into a detailed solution before clarifying scope. The interviewer marks you down for skipping the clarification phase, even if your solution is correct.

02Pattern 2 — Debugging a real bug

"Production is down. Users are seeing 500 errors. What do you do?" This question rewards methodical thinking, not heroics. The strong answer follows a triage tree:

1. Confirm the scope. What's the error rate? All users or some? All regions or one? Specific endpoints? When did it start?
2. Stop the bleeding before diagnosing. Roll back the most recent deploy. Failover to backup region. Enable circuit breakers. The fix can come later — first restore service.
3. Diagnose using logs, metrics, traces. Where is the error coming from? Service mesh, database, external API? Distributed tracing tells you the path.
4. Root cause. Not "the database returned an error." That's a symptom. Why did the database return an error? Why now? What changed?
5. Permanent fix + monitoring. Patch the code. Add a metric or alert that would have caught this earlier. Write a postmortem.

The signal interviewers look for: do you stay calm? Do you communicate during the process? Do you avoid blame? Senior engineers handle incidents methodically. Junior engineers panic and start randomly changing things.

03Pattern 3 — Code review walkthrough

Increasingly common: the interviewer shows you a 100-line piece of code and asks you to review it. They want to see what you notice and how you prioritize.

The framework — review in this order:

1. Correctness. Does it do what it's supposed to? Are there bugs? Off-by-one errors? Race conditions? Null/undefined handling?
2. Security. SQL injection, XSS, missing authorization checks, secrets in source.
3. Performance. N+1 queries, missing indexes, blocking operations on hot paths.
4. Maintainability. Are functions doing too many things? Is it readable? Are the names clear?
5. Style. Only mention if there's a real consistency issue. Don't waste time on tabs-vs-spaces.

Skip the style nitpicks until you've covered the first four. The interviewer is checking whether you understand priority. Pointing out a missing semicolon before noticing a SQL injection is a flag.

04Pattern 4 — Behavioral / past projects

"Tell me about a time you disagreed with a teammate." "Describe a project that didn't go as planned." "How do you handle conflicting priorities?"

Use STAR — Situation, Task, Action, Result. Each answer should be 90 seconds, not 5 minutes.

Strong behavioral answers share three properties:

• Specificity. Real project, real teammate, real situation. Not "in general, I always..."
• Honest difficulty. The story has actual tension. If everything went smoothly, why are you telling it?
• Genuine learning. What would you do differently? Saying "nothing, my decision was correct" reads as defensive. Real seniors have things they'd do differently.

Prepare 4-6 STAR stories before the interview. You'll likely reuse them across 80% of behavioral questions.

05Pattern 5 — Trade-offs and judgment

"Should we use SQL or NoSQL for this?" "Microservices or monolith?" "When would you use Redis vs Memcached?"

These questions test judgment. The wrong answer: picking a side without acknowledging trade-offs. The right answer: laying out the trade-offs, asking about the specific context, and making a contextual recommendation.

Template: "It depends on X, Y, Z. Here's how each option handles those concerns. Given the constraints you described, I'd lean toward A — but if [specific condition], I'd switch to B."

Senior engineers don't have universal answers to these questions. They have frameworks for deciding. Demonstrate the framework.

06The coding portion — how it actually works

Senior coding interviews are easier than junior ones, in a way. The problems are often simpler. The bar is communication and code quality, not "did you spot the dynamic programming pattern in 60 seconds."

What interviewers actually evaluate:

• Did you clarify before coding? Edge cases, input format, expected behavior.
• Did you discuss approach before writing? "Here are two approaches. I'll go with X because Y."
• Is your code clean? Variable names, function structure, no dead code.
• Did you test it? Walk through with an example. Discuss edge cases. Suggest unit tests you'd write.
• Did you discuss complexity? Both time and space. Pointed out any improvements possible.

Slow correct code beats fast buggy code at the senior level. Don't rush.

07Questions to ask the interviewer

Every interview ends with "do you have questions?" Saying "no" is a flag. Asking generic questions ("what's the culture like?") is worse. Strong questions reveal that you've thought about the role and the company:

• "What's the biggest engineering challenge the team is facing right now?"
• "What's the on-call rotation like? How frequent are real pages?"
• "Who would I be working with most closely? Can you tell me about one of them?"
• "What does success look like in this role at 6 months? At 18 months?"
• "What's something that's been hard about your work this quarter?"

These questions also help you evaluate the company. An interviewer who can't articulate a real engineering challenge is a flag. So is one who paints everything as perfect.

08What to actually prepare

Most preparation time gets wasted on the wrong things. Here's the priority order:

1. Your STAR stories (4-6 hours). Write them out, rehearse them out loud. This is the biggest leverage.
2. System design (10-15 hours). Build the mental model. Practice 8-10 designs with a friend or rubber duck. The patterns repeat.
3. Coding (5-10 hours). Stay sharp on basics — array manipulation, hash maps, basic graphs. Don't grind 500 LeetCode problems for a senior role.
4. Company research (1-2 hours per company). Read recent blog posts, listen to a podcast featuring an engineer there. Understand their tech stack and current challenges.

Skip: memorizing every algorithm, doing dynamic programming drills, reading every system design book. The interviewer doesn't expect you to invent novel algorithms in 30 minutes. They expect you to think clearly under pressure.

∞The mindset

Senior interviews are a conversation between two engineers. You're not being tested. You're being evaluated as a potential colleague. The interviewer is asking themselves: do I want to work with this person? Would I trust them on a hard problem?

The candidates who do best treat it like a conversation, not an exam. They ask questions. They admit when they don't know something. They engage with the problem genuinely. They demonstrate judgment, not just knowledge. That's what senior means, and that's what the interview is actually testing.