Technical Interview Tips: How to Explain Your Thinking Under Pressure

Technical Interview Tips: How to Explain Your Thinking Under Pressure

The most useful technical interview tip is simple: do not solve the problem silently. Interviewers need to see how you understand requirements, choose an approach, handle uncertainty and check your work. A technically correct answer can still be hard to assess when the reasoning stays in your head.

Technical interviews are not the same as normal engineering work. You usually have less context, a shorter deadline and someone listening to each decision. That makes communication part of the technical skill. The good news is that it is trainable if you practise the interview format, not just the underlying problems.

1. Clarify the problem before writing code

Start by restating the problem in your own words. Then ask the questions that would change your approach:

- What are the input limits? - Can the input be empty or contain duplicates? - Does the order matter? - What should happen when there is no valid answer? - Is the goal the simplest solution or the most efficient one?

This is not stalling. It prevents you from solving a different problem confidently. Once you understand the constraints, state the plan in one or two sentences before you open the editor.

2. Start with a working approach

Do not hide a correct simple solution because you are searching for the cleverest one. Explain the straightforward approach, its time and space complexity, and then discuss how you could improve it.

For example:

> “The direct approach checks each pair, which is O(n²). I can make that faster by storing values I have already seen in a hash map, bringing the lookup down to O(1) on average and the overall approach to O(n).”

That explanation gives the interviewer something to evaluate even before the code is finished. It also leaves you with a safe version if the optimisation takes longer than expected.

3. Narrate useful thinking, not every thought

Talking does not mean filling every second with words. Explain decisions, assumptions and changes of direction. Useful narration sounds like:

- “I am choosing a map because I need constant-time membership checks.” - “This works for the normal case, but I need to handle an empty input before I index it.” - “The brute-force version is complete. I am now looking for a way to avoid repeating this scan.”

Avoid apologising for thinking. A short pause followed by a clear next step is stronger than a stream of filler words.

4. Test before the interviewer asks

When the code is ready, choose a normal example and trace it line by line. Then test an edge case and a case that could expose a duplicate, boundary or ordering bug. Say what you expect before you run through the code.

This shows engineering discipline and gives you a chance to find the mistake yourself. If the result is wrong, do not panic. State what failed, identify the likely cause and fix the smallest part necessary.

5. Make trade-offs explicit in system design

For system design, begin with requirements rather than architecture diagrams. Ask about users, traffic, read and write patterns, latency, availability, data retention and the most important failure mode.

Then choose a design and explain why. There is rarely one perfect technology. A strong answer makes the trade-off visible: a relational database may make consistency and querying easier, while a different store may suit a particular access pattern or scale. The interviewer is assessing your judgement, not your ability to name every service.

6. Recover cleanly when you get stuck

Getting stuck is not automatically a failure. Going silent and pretending that nothing is wrong is harder to recover from. Try this sequence:

1. State what you know about the problem. 2. Name the approach you are considering. 3. Identify the part that is uncertain. 4. Try a smaller example or a simpler solution. 5. Ask a focused question if a requirement is genuinely unclear.

You can say, “I do not see the optimal step yet. I know the direct approach is correct, so I will write that first and use it to check the assumptions.” That keeps the conversation useful and gives you a path forward.

7. Practise the explanation, not only the answer

Solve a problem once, then solve it again while speaking. Record the explanation or use voice-led mock interview practice. Review whether you:

- answered the question before giving background; - stated the complexity clearly; - explained why the data structure or architecture fits; - tested the important edge cases; and - finished with a clear result.

Our guide to why people fail technical interviews covers the common communication failures in more detail. You can also practise an interview question out loud for free before adding a full coding session.

A 30-minute technical interview practice session

Use one problem rather than jumping between five:

- Minutes 1–5: read the prompt, clarify assumptions and restate it. - Minutes 6–10: describe a simple approach and its complexity. - Minutes 11–20: implement while narrating the important decisions. - Minutes 21–25: test a normal case and two edge cases. - Minutes 26–30: review the explanation and repeat the weakest section.

The last five minutes matter. They turn a solved problem into an interview skill.

Frequently Asked Questions

What should I say first in a technical interview? Restate the problem in your own words and confirm the important constraints. Then describe the approach you plan to try before writing code. This shows that you understand the task rather than reacting to keywords.

Should I explain the brute-force solution? Usually, yes. If it is correct, explain its complexity and use it as a baseline before improving it. A complete simple solution is more useful than an unfinished optimal one.

How do I stop going silent when I am stuck? Practise narrating the uncertainty: say what you know, what you have tried and what you will test next. Repeated out-loud practice builds the habit of keeping the interviewer informed without pretending to know the answer immediately.

How much should I talk while coding? Explain decisions, assumptions and changes in approach. You do not need to describe every character you type. Short, relevant updates are easier to follow than constant commentary.

How should I prepare for a system design interview? Practise clarifying requirements, estimating scale, choosing a simple initial design and explaining trade-offs. Review the failure modes and bottlenecks of your design, then explain what you would change as the system grows.

*The code is only part of the interview. Practise saying the reasoning that makes the code understandable. Start a free Voxxhire practice session.*