Why "It Depends" Will Tank Your Tech Interview

You just got asked a really good system design question: "How would you design a rate limiter for a high-traffic API?" Your brain immediately kicks into gear, cycling through Redis, leaky buckets, token buckets, distributed counters, and eventual consistency. You've seen this before. You know the textbook answers. But then, it happens. That little voice whispers, "Well, it depends." And you utter those two words, the kiss of death in a tech interview. This isn't about avoiding a definitive answer; it's about failing to demonstrate depth when "it depends" is your entire strategy.

I’ve sat on both sides of the table in countless FAANG interviews. I’ve seen brilliant engineers stumble because they thought hedging their bets was being smart. It’s not. It signals a lack of conviction, or worse, a superficial understanding of trade-offs. The interviewer isn't looking for a single "right" answer. They're looking for your thought process, your ability to articulate trade-offs, and your judgment. "It depends" alone simply fails to deliver any of that.

The Interviewer's Silent Scream: "On What?!"

When you say "it depends," the interviewer mentally tacks on, "…on what, exactly?" You’ve left them hanging. They’ve asked you to build a system, solve a problem, or make a technical choice, and your response is essentially a shrug. Imagine a doctor telling you, "Your treatment depends." You'd immediately ask, "Depends on what? My symptoms? My medical history? My insurance?" You expect a follow-up, a clarification, a path forward. Your interviewer does too.

Think about the rate limiter example again. If you just say, "It depends on the traffic," you've said nothing useful. Of course it depends on traffic! Everything depends on traffic. A better response dives into specifics. "It depends on the expected QPS, the burst tolerance, and whether we need eventual or strong consistency. For example, if we're talking about 10,000 QPS with occasional spikes to 50,000, and a 1-second eventual consistency is acceptable for most users, I'd lean towards a distributed Redis-backed counter with a sliding window. However, if we need strict per-second limits for billing, a token bucket algorithm with a centralized authority might be more appropriate, even if it introduces a single point of failure." See the difference? You’ve immediately shown understanding of constraints and proposed concrete solutions.

The Illusion of Nuance: Why Hedging Backfires

Some candidates believe that by saying "it depends," they're demonstrating a nuanced understanding of complex systems. They think they're showing awareness that there are no silver bullets. While that sentiment is true in real-world engineering, it’s a trap in an interview. The interview isn't a real-world project where you have weeks to gather requirements. It's a compressed simulation designed to extract your technical thinking under pressure.

You have limited time, usually 45-60 minutes. Every word counts. Spending precious seconds stating the obvious—that things are complex—robs you of the opportunity to showcase how you navigate that complexity. The interviewer isn't trying to trick you into picking the "wrong" solution. They want to see you make a decision based on stated or inferred constraints, and then defend that decision. They want to hear you articulate why option A is better than option B under specific conditions.

From "It Depends" to "Given X, I'd choose Y because Z"

This is the core shift you need to make. Your goal isn't to list every possible solution. It's to propose a primary solution, explain your reasoning, and then introduce alternatives with their own trade-offs.

Let's break down how to convert a weak "it depends" into a strong, conviction-filled answer:

1. State Your Assumption (or Ask for Clarification): If the problem is underspecified, don't just say "it depends." Instead, state, "Assuming X, I would approach it this way." Or, "To give you the best recommendation, I'd need to understand Y. For instance, are we prioritizing latency or data consistency?" This shows you know what information is critical.

2. Propose a Concrete Solution: Don't waffle. Pick a path. "For a system like this, I'd initially consider using Kafka for event streaming."

3. Explain Your Rationale (Why this, not that?): This is where you shine. "Kafka provides high throughput, durability, and excellent scalability for our expected message volume of 10,000 messages/second, and its pub-sub model fits our decoupled microservices architecture well. While RabbitMQ also offers message queuing, Kafka's ability to handle backpressure via consumer groups and its native partitioning for parallel processing makes it a better fit here."

4. Discuss Trade-offs and Alternatives: Now, and only now, bring up the "it depends" part. "Of course, if our primary concern was strictly low-latency point-to-point messaging with guaranteed ordering for very few consumers, then RabbitMQ might be a simpler choice to operate for that specific use case. But for a broader event bus, Kafka's advantages outweigh its operational complexity."

This structured approach demonstrates critical thinking, problem-solving skills, and deep technical knowledge. You're not just listing options; you're evaluating them.

Scenario Breakdown: When to Use the "It Depends" Framework

Let’s walk through a couple of common interview scenarios where "it depends" can creep in and how to conquer it.

Scenario 1: Choosing a Database

Interviewer: "How would you store user profiles for a new social media app?"

Bad Answer: "It depends. SQL or NoSQL." (Shrug)

Better Answer: "For user profiles, I'd initially lean towards a relational database like PostgreSQL. We'll need strong consistency for critical user data like email addresses and authentication tokens, and the ACID properties of PostgreSQL provide that reliability. We'll also likely have complex relationships—users to posts, users to friends—which SQL handles elegantly with foreign keys and joins. We can scale it vertically for a good while, and if we hit limits, we can explore sharding strategies or read replicas. Now, if the profiles also include highly unstructured data like user-generated content feeds that don't need strict relational integrity, or if we anticipate extremely high write volumes that don't fit a traditional relational model, then a document store like MongoDB or DynamoDB might be considered for those specific parts of the profile, potentially alongside PostgreSQL for the core structured data."

Notice how the better answer starts with a concrete choice, justifies it, and then introduces conditions where an alternative might be considered for specific sub-problems. It doesn't just throw out options.

Scenario 2: API Authentication

Interviewer: "What authentication mechanism would you use for a new internal microservice?"

Bad Answer: "It depends on security requirements."

Better Answer: "For internal microservices, I’d typically start with OAuth 2.0 with JWTs for token-based authentication. This provides a robust, industry-standard framework. We'd have an Authorization Server issue tokens, and our microservices would validate these JWTs using a shared secret or public key, which is efficient as it doesn't require a round trip to the auth server for every request. This scales well and allows for granular scope management. If we're talking about machine-to-machine communication where no user is involved, then the Client Credentials grant type would be appropriate. However, if these services are extremely sensitive and require mutual TLS (mTLS) for strong identity verification at the network layer in addition to token-based authentication, we'd implement that as an additional layer of security. For simpler, less critical internal tools, an API key might suffice for quick development, but I'd always prefer OAuth 2.0 for anything interacting with user data."

Again, a clear primary choice, justifications, and then specific scenarios for alternatives or enhancements. You're showing an understanding of different tools and when to apply them, not just listing them.

The Subtle Art of "It Depends, BUT..."

There's a subtle, effective way to use "it depends" that doesn't fall into the trap: "It depends, but if I had to pick one right now given common assumptions, I'd go with X because Y." This acknowledges the complexity without abdicating responsibility for making a choice. It also gives you an out if you later realize your initial assumption was flawed, without making you look indecisive. This is particularly useful when the interviewer gives you very little context.

For example, "It depends heavily on the specific latency requirements and data volume. But for a typical web application needing real-time updates for ~100,000 concurrent users, I'd likely prototype with WebSockets due to their persistent connection model and bidirectional communication capabilities. If that proves too resource-intensive or we discover the 'real-time' aspect is actually more like a 5-second poll, then long polling would be a simpler alternative." You've shown you understand the variables, made a reasonable default choice, and articulated why.

The Real-World Caveat: When Not to Force a Choice

Now, here's the honest caveat: sometimes, you genuinely cannot make a good decision without more information. If an interviewer asks, "What's the best database?" without any context about scale, data type, consistency needs, or team expertise, then forcing a choice can be detrimental. In such a case, pivot immediately to asking clarifying questions.

"That's a great question, and the 'best' database truly depends on several factors. Could you tell me more about:

• The expected data volume and query patterns? Are we talking about petabytes of data or a few gigabytes?
• The read-to-write ratio?
• What are the consistency requirements? Do we need strong ACID guarantees, or is eventual consistency acceptable for some data?
• What's the team's existing expertise? Are they familiar with SQL or NoSQL operations?

Based on those answers, I can provide a much more tailored recommendation, but generally, for X type of workload, Y database often performs well."

See the difference? You're not just saying "it depends." You're actively trying to unblock the decision-making process by identifying the missing pieces of information. This demonstrates leadership and a pragmatic approach to problem-solving, which is exactly what senior engineers do. You're not just answering the question; you're engineering the solution to the problem.

Practice Makes Perfect: Rehearsing Your Conviction

This isn't just about knowing the right answers; it's about confidently articulating them. Practice taking common interview questions and forcing yourself to make a decision, even if you preface it with assumptions. Record yourself. Listen to how you sound. Do you waffle? Do you use filler words? Do you sound confident in your choice, even while acknowledging trade-offs?

Grab a whiteboard or open a blank document. For each common design problem (rate limiting, distributed cache, user authentication, data storage for a social feed), force yourself to outline:

1. Initial choice: What's your default solution?
2. Why: What are its key benefits for a typical scenario?
3. Trade-offs: What are its weaknesses or complexities?
4. Alternatives: When would you pick something else, and why?

This structured thinking will rewire your brain to move past the vague "it depends" and directly into concrete, reasoned arguments. Your interviewers will thank you for it with an offer.

Ready to Ace Your Next Interview?

Practice with AI-powered mock interviews tailored to your target role and company. Start Practicing for Free | Explore Interview Prep