Solve problems and interviews / Coding Interviews
Where to start
Thinking Before You Code in Interviews
A repeatable way to avoid writing the wrong solution too early in coding interviews.
The problem
Many interview mistakes happen before the code starts.
The candidate recognizes a pattern too early and answers a question that feels close, but is not actually the one being asked.
Mental model
Thinking before you code is not stalling. It is how you show control.
The simple model is:
- understand the problem
- name the first correct solution
- improve only when there is a reason
That keeps optimization from showing up before understanding.
Breaking it down
A safe sequence is:
- restate the prompt in your own words
- confirm inputs, outputs, and edge cases
- name the simplest correct approach
- explain the trade-off
- optimize only if needed
This sequence keeps you from solving the wrong problem by accident.
Simple example
Suppose the prompt is:
Find the first repeated number in an array.
Instead of jumping straight to a hash map, say:
The brute-force version compares each number with the values after it. That is easy to trust, but it is O(n²). If I need linear time, I would track seen values in a set and return the first number I encounter twice.
Now the interviewer can see your reasoning, not just your final code.
Common mistakes
- jumping to the optimized pattern before proving you understood the prompt
- hiding your reasoning because you want to look fast
- forgetting edge cases like empty input or no repeated value
- explaining theory forever and never landing on a decision
How a senior thinks
A senior engineer knows that trust matters more than theatrics.
They make the path visible:
Here is the simplest correct version. Here is the trade-off. Here is how I would improve it if needed.
What the interviewer wants to see
Most interviewers are looking for a few direct signals:
- you understood the problem
- you can choose a sensible trade-off
- you can explain your decision clearly
That is why thinking before coding usually scores better than sounding fast.
In interviews, clarity beats speed more often than people think. First prove you understood the problem, then improve the solution.
If you have not explained the simplest correct version yet, you are probably optimizing too early.