How to choose a tech stack in an interview

The Problem Statement

Interviewer: "You have just proposed using PostgreSQL, Redis, and Go for this system. Walk me through why you picked those specific technologies. What would make you change any of them?"

This question tests three things: whether your technology choices are requirements-driven rather than familiarity-driven, whether you can articulate trade-offs without sounding defensive, and whether you understand that good engineers pick boring technology by default and exotic technology only when forced by constraints.

Most candidates fail this by either giving no justification ("it is what I know") or over-justifying with buzzwords ("MongoDB is web-scale"). The interviewer wants to see a repeatable framework, not an opinion about which database is best.

I think of tech stack questions as the "show your work" moment. The answer is not the technology you pick. The answer is the reasoning process that led you there. If your reasoning is sound, even picking an unusual technology is fine. If your reasoning is missing, even picking the "right" technology looks like a lucky guess.

Clarifying the Scenario

You: "Great question. Before I walk through my reasoning, I want to clarify a few things."

You: "When you say 'why these technologies,' are you asking me to justify each one against alternatives, or are you asking about the overall philosophy of how I make technology choices?"

Interviewer: "Both. Start with your general framework, then apply it to the specific choices."

You: "Got it. And should I also cover what signals would make me reconsider these choices? Like, at what scale or access pattern shift each one breaks down?"

Interviewer: "Yes, that is what I am most interested in. I want to see that you are not married to your choices."

You: "One more thing. Should I factor in team expertise and operational maturity, or keep this purely technical?"

Interviewer: "Include the operational side. That is often the tie-breaker in real decisions."

You: "OK. I will structure my answer in three parts: first the general evaluation framework I use for any technology decision, then how I applied it to arrive at PostgreSQL, Redis, and Go for this system, and finally the specific triggers that would make me swap any of them out."

My Approach

I break every technology decision into four evaluation axes, applied in this order:

1. Requirements first: What access patterns, consistency guarantees, and latency targets does this component need to meet? Name the concrete numbers before naming any technology.
2. Constraints second: What does the team know? What does the cloud provider offer managed? What is the budget? These narrow the options more than technical features do.
3. Options third: Only now do I compare specific technologies. I want at least two real candidates for each slot, not one.
4. Exit strategy last: What happens when this choice stops working? Every technology decision should include "and here is how we migrate away from it."

The critical mistake candidates make is starting at step 3. They jump to "PostgreSQL vs MongoDB" without first establishing what queries the system needs to serve. That is cargo-culting: picking technology based on what is popular rather than what fits.

I have watched candidates spend their entire design interview debating database choices without ever stating the access pattern. The interviewer cannot evaluate your reasoning if you skip the reasoning and jump to the conclusion.

For your interview: announce the framework before applying it. Say "I evaluate technology choices on four axes" and name them. This shows the interviewer you have a repeatable process, not just opinions about databases.

The Architecture

Here is the decision flow I use for any technology selection in a system design interview:

The flow is sequential, not parallel. Each stage filters the options further. By the time I reach "Technology Evaluation," I usually have only 2-3 realistic candidates, not 15.

Let me walk through how this plays out for the three most common technology decisions in system design interviews: database selection, build vs buy, and how to present your choice.

Database Selection Framework

This is the technology question you will face most often. Every system design question involves storing data, and the interviewer will ask why you chose your storage layer.

Here is the decision tree I use:

The key insight: I do not start by comparing databases. I start by naming the access pattern. Once the access pattern is clear, the category narrows to 2-3 options, and from there the decision is usually obvious.