What you'll learn

  1. Quick answer
  2. What Is Actually Being Assessed
  3. Step 1: Clarify Before Coding
  4. Step 2: State the Approach Before Writing
  5. Steps 3 and 4: Write, Then Test It Yourself
  6. When You Are Stuck
  7. FAQ

Quick Answer

Follow a fixed sequence: clarify the problem and constraints, state your approach out loud before writing anything, write the code, then test it with edge cases yourself. Interviewers assess communication and problem-solving as much as the final answer. A working brute-force solution with a stated plan to optimise scores far better than silence followed by an incomplete optimal attempt.

What Is Actually Being Assessed

Candidates assume the coding round scores one thing: did the code work. Interviewers are usually scoring four.

  • Problem solving — can you get from problem to approach?
  • Communication — can you explain your reasoning as you go?
  • Coding — is the implementation clean and correct?
  • Testing — do you check your own work, or wait to be told it is wrong?

That distribution has a practical consequence. A candidate who explains a clear approach and produces working brute force usually outscores one who sits silently and produces half an optimal solution. The silent candidate demonstrated nothing that could be assessed.

It also means the worst outcome is not a wrong answer — it is a blank screen and no commentary, because the interviewer has nothing to evaluate and no way to help you.

This differs from an automated online assessment, where only test cases matter. In a live round with a human, treat the conversation as part of the answer.

Step 1: Clarify Before Coding

Two minutes here prevents solving the wrong problem, and it signals experience. Real requirements are always ambiguous, so interviewers watch whether you notice.

Questions worth asking on almost any problem:

  • What is the input size? This decides the complexity you need, so it is the most useful question.
  • Can the input be empty or null?
  • Can values be negative? Can there be duplicates?
  • Is the input sorted?
  • What should happen when there is no valid answer?
  • Can I modify the input, or must it stay unchanged?

Then restate the problem in your own words and confirm with an example:

"So given [2, 7, 11, 15] and target 9, I return the indices [0, 1]
 because 2 + 7 = 9. And if no pair exists, I return an empty array —
 is that right?"

This catches misunderstandings before you have written thirty lines based on a wrong assumption, and it is the cheapest insurance available in the whole interview.

Step 2: State the Approach Before Writing

Do not start typing immediately. Explain the plan first, and give the complexity.

"The brute force is checking every pair, which is O(n squared).
 Since the constraint is 10^5, that will be too slow.

 I can do better with a hash map: as I iterate, I check whether
 target minus the current value has been seen. That is O(n) time
 and O(n) space. Shall I code that?"

Three things this achieves. The interviewer can redirect you before you waste ten minutes on a wrong path. You have demonstrated the reasoning being assessed. And you have a plan to follow while coding, so you are not designing and typing simultaneously.

Mention the brute force even when you see the better solution. It shows you understand the baseline you are improving on, and it takes fifteen seconds.

Let the constraints drive the choice. Saying "n can be 10^5, so I need at least O(n log n)" out loud is exactly the reasoning the question is testing — often more convincing than the code that follows.

If the optimal approach is not obvious, say so and start with brute force. "I'll write the O(n squared) version first to make sure it is correct, then optimise" is a professional answer, not an admission of weakness.

Steps 3 and 4: Write, Then Test It Yourself

While writing: keep talking, but at a lower volume of detail. "I'm using a dictionary to store the value and its index as I go" is enough. Narrating every character is distracting.

Use meaningful variable names — seen, left, maxLength, not a, b, temp. Interviewers read your code as a sample of how you write professionally.

If you get stuck mid-implementation, say what you are stuck on rather than going quiet. Interviewers give hints, but only if they know where you are.

Then test it before saying you are done. This is the step most candidates skip, and it is one of the four scored areas.

Walk through a small example line by line, out loud, tracking the variables. Then check the edge cases:

  • Empty input
  • A single element
  • All elements identical
  • The answer at the very start or very end
  • No valid answer at all
  • Negative numbers, if allowed

Finding your own bug is a strong signal — it shows you can verify work without supervision. Being told your code is wrong is a much weaker position, and it is entirely avoidable.

Finish by stating the final complexity for both time and space, without being asked.

When You Are Stuck

It happens to everyone. What matters is what you do next, and there is a right answer.

Say what you are thinking. "I'm trying to find a way to avoid the nested loop. A hash map would give me O(1) lookup, but I'm not sure yet what I'd use as the key." That invites a hint and shows the process. Silence invites nothing.

Write the brute force. It is a valid answer, it earns partial credit, and its inefficiency usually points at the fix — repeated subproblems suggest DP, repeated scanning suggests a hash map or a sliding window.

Work a small example by hand. Take a five-element input and solve it manually on the board. The pattern you use instinctively is often the algorithm.

Ask for a hint. Directly. "I'm considering two pointers but I'm not certain it applies here — am I on the right track?" This is not a failure; a candidate who uses a hint well is preferred to one who stalls silently for ten minutes.

What not to do: go silent, guess randomly at approaches, apologise repeatedly, or claim to have seen the problem before if you have not. Interviewers are experienced at spotting a memorised answer, and the follow-up questions expose it.

Afterwards, however it went: ask what you could have done better. Some interviewers answer, and it is the most useful feedback you will get.

Frequently Asked Questions

Should I write brute force first or go straight to the optimal solution? Mention the brute force and its complexity, then propose the better approach. If the optimal one is not clear, write the brute force to establish correctness and say you will optimise. A working simple solution beats an incomplete clever one.
Is it bad to ask for a hint? No. Using a hint well is viewed better than stalling silently, and interviewers expect to give some guidance. Explain what you have considered and where you are stuck rather than simply asking for the answer.
How much should I talk during a coding round? Explain the approach fully before coding, then narrate at a lower level while writing — the key decisions, not every line. Silence is the real risk, because the interviewer cannot assess or help what they cannot hear.
Do I need to test my code in an interview? Yes, and it is one of the scored areas. Walk through a small example out loud and check the edge cases — empty input, one element, no valid answer. Finding your own bug is a strong signal.
What if I cannot solve the problem at all? Produce whatever partial progress you can — the brute force, a clear approach, a solution to a simplified version — and communicate throughout. Many interviews are scored on process, and candidates are frequently advanced despite not finishing.