Solving problems out loud

Why it matters

Technical interviews for software developer, data scientist and machine learning engineer roles usually include a live problem-solving session. The interviewer cares less about whether you remember a trick and more about how you think: do you clarify the problem, consider options, write clear code and test it? The same habits make you a better teammate in code reviews, pair programming and design discussions, and they help a teacher model problem solving for a class. Thinking out loud is a skill, and like any skill it improves with deliberate practice.

A framework you can repeat

Use the same steps every time so you never freeze on a blank editor.

1. Understand (about 10% of the time). Restate the problem in your own words. Ask about inputs and outputs: types, sizes, sorted or not, duplicates, negative numbers, empty input. Ask what to return when there is no answer.

"So I get a list of integers, possibly empty, and a target. I return the indexes of two different items that add up to the target, or None. Can the list have duplicates? Roughly how large can it be?"

2. Examples. Work one normal example and at least two edge cases by hand before coding: empty, one item, no answer, duplicates. Write them down; they become your tests.

3. Brute force first. Say the simplest correct idea and its Big-O, even if it is slow.

"The simple approach checks every pair. That is O(n^2) time and O(1) space. It's correct, so it's my fallback."

4. Optimise. Look for the pattern. Is it sorted (binary search, two pointers)? A counting or "seen before" question (hash map)? Consecutive items (sliding window)? Repeated sub-problems (DP)? Nested or tree-shaped (recursion, BFS/DFS)? State the new complexity and the trade-off.

"If I store each number's index in a dict as I go, I can check for the complement in O(1). That's O(n) time and O(n) extra space."

5. Code. Narrate at the level of intent, not every keystroke: "this loop keeps a running window sum", "this check stops an item pairing with itself". Use clear names. If you get stuck, say what you are trying to do; interviewers often give a hint.

6. Test. Run your examples through the code by hand, line by line, tracking variables. Then the edge cases. Fix bugs calmly and say what you found.

7. Review. Restate the final time and space complexity and mention what you would improve with more time (input validation, a library function, handling very large inputs).

What "out loud" sounds like

Good narration is short and specific:

• "I'm going to assume the input fits in memory; let me know if not."
• "I'm not sure yet whether sorting helps. Let me try the example."
• "This is failing on the empty list because nums[0] doesn't exist. I'll add a guard."

Silence for a few seconds while you think is fine. Say "Let me think for a moment" so the interviewer knows you are working.

Practising effectively

• Practise on paper or a plain editor sometimes, without autocomplete or running code, because many interviews do not let you run code.
• Time-box yourself: about 30 to 45 minutes per problem. If you are stuck after 20, read a hint, then solve it yourself the next day.
• Record yourself or practise with a friend. Listening back is uncomfortable and very effective.
• Keep a log of problems: the pattern, the mistake you made, and the complexity. Reviewing patterns beats grinding hundreds of random problems.
• Use free practice sites (LeetCode, HackerRank, Exercism, NeetCode's free roadmap) and focus on easy and medium problems that use this course's patterns.

Be honest about the process

Interview formats vary by company, and many now include take-home projects, pair programming or system design instead of, or as well as, algorithm puzzles. Data science and ML roles often add statistics, SQL and modelling questions. Teaching roles may ask you to explain a concept to a beginner. Read the job posting and ask the recruiter what to expect; many companies publish their interview guides.

Common mistakes

• Coding immediately before understanding the problem or agreeing on the output.
• Going silent for minutes, so the interviewer cannot help or give you credit.
• Skipping the brute force and getting stuck on a clever idea with nothing to show.
• Never testing, or only testing the happy path.
• Arguing with hints. A hint is help, not criticism.

Quick recap

Understand, examples, brute force, optimise, code, test, review. Say what you are doing and why, state Big-O at each stage, and test edge cases out loud.

Try it

The Do tab walks you through a full practice session on a problem from this course, recorded on your phone or computer, with a short self-review.