Coding interview tips: thinking aloud, asking questions, and handling blanks

Why thinking aloud matters more than the right answer

Most interviewers are not looking for a perfect solution on the first attempt. They want to see how you approach an unfamiliar problem. A candidate who talks through a flawed approach and catches their own mistake is more impressive than one who silently produces a correct answer with no visible reasoning.

Thinking aloud also gives the interviewer a chance to help you. If you say 'I am going to try a brute-force O(n squared) approach first and then see if I can improve it,' the interviewer may confirm that is fine or nudge you toward a better direction. That nudge is not cheating. It is the interview working as intended.

• State your initial interpretation of the problem before touching the keyboard.
• Name the approach you are considering and its trade-offs, for example 'a hash map here would give me O(1) lookup at the cost of extra space'.
• Narrate each step as you write it, not after.
• If you change direction, say why: 'Actually, this breaks when the input is empty, so I need to handle that first.'

Clarifying questions to ask before you start coding

Spending two to three minutes on clarifying questions before writing any code is almost always worth it. It prevents you from solving the wrong problem, and it signals that you think carefully about requirements, which is exactly what engineers do on the job.

Keep your questions focused. You are not stalling; you are gathering the information a real engineer would need. Aim for three to five targeted questions, not an exhaustive list.

1. Input constraints: 'Can the input be empty or null? What is the maximum size I should expect?'
2. Output format: 'Should I return the result or print it? If there are multiple valid answers, does the order matter?'
3. Edge cases: 'What should happen if there are duplicate values? Should I handle negative numbers?'
4. Performance expectations: 'Is there a time or space complexity target I should aim for?'
5. Assumptions: 'Can I assume the input is sorted, or do I need to sort it myself?'

How to handle going blank mid-interview

Going blank is normal. It happens to experienced engineers. The worst response is to freeze silently. The best response is to say something out loud immediately, even if it is just 'I want to think through this step by step.'

Returning to basics almost always helps. Restate the problem in your own words, write out a small concrete example by hand, and ask yourself what data structure fits the shape of the problem. A stack for last-in-first-out problems, a queue for breadth-first traversal, a hash map when you need fast lookups.

• Say 'Let me work through a small example' and write one out on the whiteboard or in the editor.
• Ask yourself: what is the simplest possible input, and what should the output be?
• If you are stuck on an optimal solution, say so and offer the brute-force version: 'I know this is not efficient, but let me get a working solution first and then optimise.'
• It is acceptable to say 'I am not immediately recalling the exact syntax for this, but the logic I would use is...' Interviewers care more about the logic than whether you remember every method name.

Structuring your solution before you write it

Write a brief plan in comments before you write any real code. This takes about sixty seconds and gives you a roadmap. It also shows the interviewer your intended structure, so they can flag a misunderstanding early.

A plan might look like this: initialise a hash map, iterate through the array, check if the complement exists in the map, return the indices if found, otherwise add the current value to the map. Once you have that written, filling in the actual code is much faster and less error-prone.

• Write your plan as comments, then convert each comment into code.
• State your time and space complexity before you start: 'This should be O(n) time and O(n) space.'
• After finishing, walk through your solution with the example input you used earlier to verify it.
• Check edge cases explicitly: empty input, single element, all duplicates, negative numbers.

Common mistakes that cost candidates the offer

Jumping straight into code without any discussion is the most common mistake. The second is writing code in silence. The third is giving up when the first approach does not work instead of pivoting out loud.

Arguing with the interviewer about the problem statement is also a red flag. If they tell you your solution has a bug, say 'thank you, let me trace through that' and find it. Defensiveness signals poor collaboration.

• Do not optimise prematurely. Get a working solution first, then improve it.
• Do not ignore the interviewer's hints. If they ask 'is there a way to do this in one pass?' that is a direct hint, not a casual question.
• Do not skip testing. Even if you are confident, trace through your code with at least one example.
• Do not use overly clever one-liners if you cannot explain them. Readable code with clear intent beats a compact solution you cannot defend.

Real-time support during the interview itself

Break-In Bad has an on-screen interview assistant that listens to the interviewer's questions and shows you relevant answers and hints that only you can see, even on a shared screen. If you are mid-interview and the interviewer asks a question you did not expect, the assistant can surface a structured response while you speak. It works for technical and behavioural questions. You can try it with the 50 free credits you get on signup.