How to Answer the Toughest Question in Any Engineering Interview

A practical approach that top engineers use without overthinking.

Hey High Performers,

Picture this: You're sitting across from a FAANG hiring manager, discussing your latest project. The compensation? $200K+. Everything's going well until they ask the question that sends most engineers spiraling:

"Why did you choose that approach?"

Last month, I heard about an engineer who completely bombed at this exact moment. Here's how it went down:

Interviewer: "Why did you choose this approach?"

Engineer: "Well, MongoDB has amazing flexible schemas, and we used Redis for caching, and implemented sharding for scalability..."

Interviewer: "But WHY did you choose it?"

Engineer: silence

Game over. $200K opportunity gone.

---

The Hidden Pattern in Failed Interviews

We're trained to showcase our technical knowledge. We name-drop technologies like trophies:

• "I used NoSQL"

• "We implemented document storage"

• "Built it with Cassandra"

But we skip the most critical part: the problem we were solving.

Your choice of database doesn't make you smart. Your ability to explain WHY you chose it does.

That interviewer didn't care if you knew MongoDB inside and out. They cared that you understood:

• When to use it

• When NOT to use it

• What problem it actually solved

---

The Framework That Changes Everything

Next time someone asks about your technical decisions, flip your answer structure:

Instead of starting with the solution, start with the problem:

❌ Don't say: "We used MongoDB for this project"

✅ Do say: "We had this problem where we needed to store user profiles with completely different data structures—some users were individual contributors, others were enterprise accounts with complex hierarchies. A relational schema would have meant constant migrations every time we added new user types. That's why we chose MongoDB's flexible document structure."

---

The Magic Three-Step Formula

1. Start with the constraint: "We needed to optimize for..."

2. Explain the problem: "The challenge was..."

3. Then mention your solution: "So we chose..."

This signals that you solve problems first, and choose tech second.

---

Why This Matters More Than You Think

Your MongoDB knowledge will be obsolete in 5 years. But your ability to:

• Identify the real problem

• Evaluate tradeoffs

• Justify technical decisions

That's career-defining stuff. That's what separates senior engineers from junior ones who happen to know the latest frameworks.

---

Real Examples That Work

Here are three sample responses that would have saved that $200K opportunity:

Database Choice: "We were building a real-time chat application where message volume could spike 10x during peak hours. We needed something that could handle unpredictable write loads without locking up. Traditional SQL databases would have required complex sharding strategies that our 3-person team couldn't maintain. MongoDB's built-in horizontal scaling let us focus on features instead of database administration."

Architecture Decision: "Our users were complaining about 5-second load times on the dashboard. Profiling showed 80% of the delay came from aggregating data across 12 different microservices. We implemented a denormalized read model using Redis because we could afford eventual consistency for dashboard data, but we couldn't afford those load times."

Technology Stack: "The client had a hard requirement for SOC 2 compliance within 6 months. Our existing Python/Django stack would have required 3 months of security hardening. We switched to Next.js with Vercel because their infrastructure was already SOC 2 compliant, saving us 12 weeks of compliance work."

See the pattern? Problem first, constraints second, solution third.

---

The Questions That Reveal Everything

Smart interviewers dig deeper with these follow-ups. Prepare for:

• "What were the alternatives you considered?"

• "What would you do differently knowing what you know now?"

• "How did you measure success?"

• "What was the biggest risk with this approach?"

These questions are your chance to prove you think like a senior engineer

---

What Senior Engineers Actually Do

Here's what separates $200K+ engineers from the rest:

Junior Engineer Thinking: "I need to use the latest technology to show I'm up-to-date"

Senior Engineer Thinking: "I need to solve this problem with the least amount of complexity and risk"

Senior engineers are technology pragmatists. They choose boring, proven solutions when possible. They only reach for cutting-edge tech when the problem demands it.

---

The 24-Hour Rule

Before your next interview, spend 24 hours reviewing your recent projects through this lens:

1. What problem were you actually solving?

2. What constraints shaped your decision?

3. What alternatives did you consider?

4. What tradeoffs did you accept?

5. How did you validate your choice?

Write down your answers. Practice saying them out loud. This exercise alone will put you in the top 10% of candidates.

---

The Bottom Line

The next time you're in an interview (or explaining your architecture to stakeholders), remember: they don't care about your tech stack — they care about your thinking process.

Lead with the problem. The solution becomes obvious.

And if you're currently job hunting? Stop memorizing MongoDB features and start documenting the problems you've solved. That's what gets you the offer.

---

Keep building!

P.S. What's the hardest "why" question you've been asked in an interview? Hit reply and let me know — I read every response. The best stories might make it into next week's newsletter.

---

Forwarded this newsletter? Subscribe here to get insights like this every week.