How to Answer "Why This Approach?" Without Sounding Generic

The problem

The question sounds simple:

why this approach?

But it knocks a lot of people down.

Because the candidate may have reached a good solution, but cannot support it without falling into an automatic phrase.

The answer becomes something like:

• “because it is more performant”
• “because it is more scalable”
• “because it is best practice”
• “because it makes more sense here”

That says very little.

Sometimes it says nothing.

The interviewer does not only want to know that you picked a path.

They want to know whether the choice was made with criteria.

Mental model

Think of it like this:

Answering “why this approach?” means explaining which pain it solves better and which cost you accepted in return.

That is the core structure.

Every approach wins in some dimension and loses in another.

If you do not show that trade, the answer sounds like personal preference or buzzword.

If you show the trade clearly, the answer starts sounding mature.

Breaking the problem down

Start with the constraint that actually matters

The best justification almost always starts from a real constraint.

Examples:

• I need to preserve the index
• I need to answer in one pass
• I need to simplify delivery
• I need to reduce operational risk
• I need to keep reversibility

Without a constraint, the approach looks arbitrary.

With a constraint, it gains context.

Then name the cost you are accepting

Every choice charges something.

It may be:

• more memory
• more complexity
• worse readability
• higher write latency
• less future flexibility

When you bring up that cost yourself, the answer gets stronger.

Because it shows you are not trying to sell a perfect solution.

You are showing judgment.

Only then say why that trade is worth it

This is the sentence many people skip.

It is not enough to say:

• “I use a hash map”

It helps to say:

• “I use a hash map because I need fast lookup in one pass, and I am willing to pay extra memory for that”

Now the choice is defensible.

Saying when you would change approaches is a strong signal of maturity

This is a good move because it shows your solution is not dogma.

Something like:

If I did not need to preserve the index, I would consider sorting and using two pointers to simplify the structure.

That communicates:

• flexibility
• awareness of context
• real comparison between alternatives

A short answer is better than an abstract one

A good justification does not need to be long.

It needs to be complete in the right place.

A simple formula usually works:

1. main constraint
2. chosen approach
3. accepted cost
4. condition that would make you change

Simple example

Question:

Why did you choose a Hash Map instead of sorting the array?

Generic answer:

Because Hash Map is more efficient.

Better answer:

I chose a Hash Map here because I want to solve it in one pass and preserve the original indices. The cost is extra O(N) memory. If preserving the index did not matter, sorting and using two pointers could simplify the logic, but it would cost O(N log N) and change the order.

In a few lines, you showed:

• what you protected
• what you paid
• what you ruled out
• why you ruled it out

Common mistakes

• Defending the solution with buzzwords instead of criteria.
• Answering as if the approach had no cost.
• Talking only about the technique and not the constraint that motivated it.
• Sounding dogmatic, as if there were only one “correct” path.
• Saying “it depends” without finishing what it depends on.

How a senior thinks

People with more maturity do not try to sell that they picked the perfect answer.

They try to show that they picked the best trade for that scenario.

That applies to:

• algorithm
• architecture
• debugging
• rollout
• product decisions

Senior reasoning usually sounds like this:

given this context, I protected this, accepted this cost, and would do it differently if the constraint changed.

It is a simple answer.

But it communicates a lot at the same time.

What the interviewer wants to see

When they ask this question, the interviewer usually wants to notice whether you:

• have criteria and not only repertoire
• see cost, not only benefit
• connect technique to constraint
• can support the choice clearly

A strong answer on this topic usually sounds like this:

I try to justify an approach through constraint, cost, and switching condition. That helps me avoid answering with buzzwords and makes it clear why this solution makes sense here, not in every scenario.

Justifying the choice well matters more than repeating that it is “more scalable.”

When you explain the cost you accepted, your decision starts sounding real.