How to Answer 'What Would You Do First?'

The problem

This question sounds simple:

“What would you do first?”

But it knocks a lot of people out.

Because many answers go one of two bad ways:

• too fast a guess
• too vague an abstraction

In the first case, the person jumps straight to the solution:

“I would already open a PR.”

In the second case, they hide behind polished language:

“I would understand the context better, align with the team, and evaluate trade-offs.”

Both answers can sound weak.

The first because it feels impulsive.

The second because it does not decide anything.

The real problem is that a lot of people confuse “first step” with “first heavy task.”

It almost never is that.

Mental model

Think about it this way:

the right first move is the smallest move that most reduces uncertainty, risk, or damage.

That definition helps a lot.

Because it shifts the focus from:

• “which solution do I like more?”

to:

• “which move puts me in a better position to decide the rest?”

Sometimes that first move is investigation.

Sometimes it is damage containment.

Sometimes it is alignment on the objective.

Sometimes it really is implementation.

But the logic is always the same:

first comes the move that improves the quality of the next decision.

Breaking the problem down

First is not the same as main

This mistake is very common.

The person thinks:

• “the problem is in payments”
• “so my first move is to fix the bug”

Not necessarily.

If you still do not know:

• how big the impact is
• whether the problem is still active
• whether the most recent deploy caused it
• whether there is a simple mitigation

then “fixing” is not the first move yet.

It is a later step.

Three common openings: understand, contain, or unblock

Most scenarios fall into one of these openings:

• understand what is happening
• contain immediate damage or risk
• unblock the next team decision

That already gives the answer more shape.

If it is a production incident, the first move is often containment.

If it is an ambiguous product problem, the first move is often understanding the impact better.

If it is a stuck discussion between options, the first move is often unblocking the criterion.

A good first move is usually cheap and informative

This is a great filter.

The strong first move usually:

• costs little
• gives fast learning
• reduces the chance of making things worse

Examples:

• check the scope of the problem before touching anything
• verify whether there was a recent change
• trigger rollback or a feature flag
• validate with data whether the pain is real or local
• align on the main goal before arguing about solutions

Notice the logic.

You are not solving the whole case yet.

You are buying clarity.

Jumping straight to code is often technical vanity

That sounds harsh, but it helps.

Too many answers go too early to:

• refactor
• architectural change
• new implementation
• automation

without first answering:

• is this really the problem?
• is this the most urgent problem?
• is there a cheaper way to reduce risk right now?

Sometimes code does come first.

But not because “real engineers start coding.”

It comes first because the context is already clear enough.

The first move depends on the cost that threatens the case most

This helps a lot when the answer starts feeling generic.

Ask:

• is the biggest risk revenue?
• user trust?
• downtime?
• rework?
• delay in a business window?

When you identify the dominant cost, the first move becomes more obvious.

You stop answering in abstractions and start answering in context.

A strong answer always shows order

It is not enough to say the first move.

It helps to show the sequence quickly:

1. what I would do first
2. what I expect to learn from it
3. what I would do next depending on the result

That makes it clear your head is not just reacting.

It is navigating.

Simple example

Imagine this question:

“After a deploy, checkout conversion dropped. What would you do first?”

Weak answer:

“I would investigate the checkout code.”

That may happen later, but it is still too early.

Better answer:

“My first move would be to confirm whether the drop is real, how big the impact is, and whether it started exactly after the deploy. If the effect is significant and the correlation looks strong, I would evaluate rollback or turning off the change before diving into the code. I do that because the first goal is not to prove I have a neat technical hypothesis. It is to reduce damage and get clarity on where the problem likely came from.”

That works because it shows:

• impact reading
• containment before technical ego
• decision order
• criteria for the next move

Common mistakes

• Answering with the final solution instead of the first move.
• Staying too generic and choosing nothing.
• Jumping to code when the problem is still poorly defined.
• Ignoring damage containment in a critical scenario.
• Not saying what the first move is supposed to clarify.

How a senior thinks

People with more experience usually ask:

“What is the smallest move that gives me the most useful clarity?”

That is the real question behind the answer.

Because the point is not to look busy.

It is to create the conditions for a better decision.

What the interviewer wants to see

The interviewer is looking for whether you can:

• order uncertainty before action
• avoid confusing speed with judgment
• protect damage before chasing elegance
• explain why the first move matters more than the most visible one

A strong answer usually sounds like this:

“My first move would be to confirm the impact and the likely cause before choosing a technical fix. If there is clear production risk, I would contain it first. If the goal is still blurry, I would reduce the ambiguity until the next step is obvious. The point is to choose the move that improves the next decision, not just the one that looks active.”

The first move is not the loudest move. It is the move that improves the board.

In interviews, good judgment usually shows up in what you choose to do before the obvious solution.