Technical Interview Prep: How to Think Out Loud While Solving Coding Problems

Knowing how to solve a coding problem is only part of a technical interview.

You also need to show the interviewer how you think.

Many candidates make the same mistake:

They read the question, immediately start typing, get stuck, change their approach several times, and eventually run out of time.

A stronger approach is different.

You slow down just enough to understand the problem, explain your assumptions, choose an approach, write the solution, test it, and discuss its efficiency.

This guide shows you how to do that without turning your interview into a long speech.

The Interview Is Not Just About the Final Code

Imagine an interviewer asks:

Given an array of integers, return the first number that appears twice.

A nervous candidate might immediately start writing code.

A stronger candidate might first say:

"Let me confirm the requirement. We need to return the first value whose second occurrence appears while scanning from left to right. If there are no duplicates, should I return a special value such as -1?"

That short clarification already demonstrates useful skills.

You are showing that you can:

• understand requirements
• identify ambiguity
• define assumptions
• communicate before implementation

That is much more useful than silently typing for ten minutes.

The Five-Part Interview Flow

A practical coding interview can be approached with five stages:

1. Clarify
      ↓
2. Explore
      ↓
3. Choose
      ↓
4. Implement
      ↓
5. Test and Explain

You don't need to announce every stage.

The framework is there to keep your thinking organized.

1. Clarify the Problem

Before thinking about algorithms, make sure you understand the problem.

Suppose the question is:

Find the two numbers in an array whose sum equals a target.

Don't immediately write a loop.

Ask useful questions.

Question 1: Can the array contain duplicates?

For example:

[3, 3]

with:

target = 6

Should this count?

Question 2: Can the array contain negative numbers?

For example:

[-5, 2, 7]

Question 3: What should happen if no solution exists?

Possible answers:

null
[]
[-1, -1]
throw an error

Question 4: Does the order matter?

For example:

[2, 7]

versus:

[7, 2]

These questions are not wasting time.

They prevent you from solving the wrong problem.

A Worked Example

Let's use one problem throughout the article.

Problem

Given an array of integers and a target value, return the indices of two numbers whose sum equals the target.

Example:

numbers = [2, 7, 11, 15]
target = 9

Expected result:

[0, 1]

because:

numbers[0] + numbers[1]
= 2 + 7
= 9

2. Start With the Simple Solution

Before jumping to an optimized algorithm, explain the obvious approach.

You could compare every number with every other number.

function twoSum(numbers, target) {
  for (let i = 0; i < numbers.length; i++) {
    for (let j = i + 1; j < numbers.length; j++) {
      if (numbers[i] + numbers[j] === target) {
        return [i, j];
      }
    }
  }

  return [];
}

Then explain:

"This checks every possible pair. It is simple and correct, but we are doing a lot of repeated comparisons."

Now discuss complexity.

Time:  O(n²)
Space: O(1)

The important part is not simply knowing the notation.

Explain why.

"For each element, I'm potentially checking many other elements, so the number of comparisons grows roughly with the square of the input size."

That is much stronger than simply saying:

"It's O of n squared."

3. Look for a Better Approach

Now ask:

"What information would let me avoid checking every previous number again?"

For each number:

current = numbers[i]

we need:

needed = target - current

For example:

target = 9
current = 7

needed = 9 - 7
       = 2

If we can quickly determine whether 2 has already appeared, we don't need to scan the entire previous portion of the array.

A hash map can provide that lookup.

4. Build the Optimized Solution

function twoSum(numbers, target) {
  const seen = new Map();

  for (let i = 0; i < numbers.length; i++) {
    const current = numbers[i];
    const needed = target - current;

    if (seen.has(needed)) {
      return [seen.get(needed), i];
    }

    seen.set(current, i);
  }

  return [];
}

Now explain the logic in plain language.

"I'm scanning the array once. For each value, I calculate the number required to reach the target. If that required value has already been seen, I have my pair. Otherwise, I store the current value and its index."

That explanation is far more valuable than reading the code line by line.

5. Explain the Trade-Off

The optimized solution improves time complexity:

Time:  O(n)
Space: O(n)

Why?

We scan the array once:

n elements

and use a map for fast lookups.

But the map consumes additional memory.

So the trade-off is:

Less time
   ↕
More memory

This is exactly the kind of reasoning interviewers want to hear.

Don't just say:

"Hash maps are faster."

Say:

"I'm using additional memory to avoid repeatedly scanning the array, which reduces the overall time from quadratic to linear."

What Should You Say While Coding?

You do not need to narrate every keystroke.

Bad:

"Now I'm typing const, now I'm typing seen, now I'm opening the bracket..."

Better:

"I'll use a map to store each value with its index. Before inserting the current value, I'll check whether its complement already exists."

Then code.

The goal is to explain decisions, not keyboard activity.

A Useful Think-Aloud Pattern

When solving a problem, use this sequence:

Understand the requirement
        ↓
Give a small example
        ↓
Describe the simple approach
        ↓
Identify the limitation
        ↓
Improve the approach
        ↓
Explain the trade-off
        ↓
Code
        ↓
Test
        ↓
Discuss complexity

You don't have to literally say these headings.

They are your mental checklist.

Use Examples Before Code

Suppose the input is:

[2, 7, 11, 15]

and:

target = 9

Walk through it:

i = 0
current = 2
needed = 7

7 not seen

store:
2 → 0

Next:

i = 1
current = 7
needed = 2

Now:

2 exists in map

Therefore:

[0, 1]

This small dry run can expose mistakes before you finish coding.

Test Before the Interviewer Tests You

Once the solution is written, don't immediately say:

"Done."

Test it.

Start with the normal case:

twoSum([2, 7, 11, 15], 9);

Expected:

[0, 1]

Now test another case:

twoSum([3, 2, 4], 6);

Expected:

[1, 2]

Then test duplicates:

twoSum([3, 3], 6);

Expected:

[0, 1]

Then no solution:

twoSum([1, 2, 3], 20);

Expected:

[]

You don't need twenty test cases.

A few carefully selected cases are much more useful.

Edge Cases You Should Learn to Look For

Different problems have different edge cases, but several patterns appear repeatedly.

Empty input

[]

Ask:

What should the function return?

One element

[5]

Can a solution exist?

Duplicate values

[2, 2, 3]

Does duplication change the answer?

Negative numbers

[-10, 5, 15]

Does the algorithm still work?

Very large input

100,000+ elements

Does an O(n²) solution become impractical?

Already sorted input

[1, 2, 3, 4, 5]

Could the ordering help?

The important skill is not memorizing edge cases.

It is learning to look for assumptions that can break your solution.

What If You Get Stuck?

This is where many candidates panic.

Suppose you've been thinking for several minutes and don't see the optimal solution.

Don't go silent.

Say something like:

"I see a straightforward solution using nested loops. I'll implement that first so we have a correct baseline, then I'll look for a way to reduce the repeated work."

This is much better than staring at the screen.

You have established:

Correct solution
      ↓
Understand limitation
      ↓
Improve if possible

Sometimes the simple solution reveals the optimization.

Don't Hide the Brute-Force Approach

A common interview mistake is thinking:

"I must immediately produce the optimal solution."

Not necessarily.

The brute-force solution can be useful because it gives you a baseline.

For example:

Brute force
O(n²)

Then:

Optimized
O(n)

You can clearly explain what changed.

That demonstrates algorithmic reasoning.

When You Should Change Your Approach

Suppose your initial solution is:

O(n²)

and the interviewer says:

"Can you do better?"

Don't panic.

Ask:

"Are we allowed to use additional memory?"

If yes, consider whether a data structure can remove repeated work.

For example:

Repeated search
       ↓
Hash map / set
       ↓
Faster lookup

Or:

Repeated comparisons
       ↓
Sorting
       ↓
Two pointers

Or:

Repeated subproblems
       ↓
Memoization
       ↓
Reuse previous results

The optimization should come from the structure of the problem.

Don't force a technique just because you memorized it.

Pattern Recognition Helps

Over time, you'll notice recurring patterns.

The goal is not:

"I memorized 100 solutions."

The better goal is:

"I can recognize the structure of a new problem."

Interviewer Follow-Ups

Your first solution may not be the end.

An interviewer might ask:

Can you reduce the memory usage?

Or:

What happens if the input is already sorted?

Or:

What if there are multiple valid answers?

Or:

Can you return the values instead of the indices?

Or:

How would this change if the data arrived continuously?

Don't treat follow-up questions as attacks.

They are opportunities to demonstrate flexibility.

A good response is:

"That changes the constraint, so I would revisit the data structure rather than modifying the current implementation blindly."

Then reason from the new requirement.

What If Your Code Has a Bug?

It happens.

Don't immediately erase everything.

Start by identifying the failure.

For example:

Expected:
[0, 1]

Received:
[]

Now inspect:

Input
 ↓
Loop
 ↓
Condition
 ↓
Stored state
 ↓
Return value

You can say:

"The algorithm should find the complement, so I'll trace the map state for the first two iterations."

Then walk through it.

This demonstrates debugging ability instead of panic.

How Much Should You Talk?

A technical interview should not become a speech.

A useful rule:

Before coding

Explain:

• your interpretation
• important assumptions
• approach
• complexity expectation

During coding

Explain:

• important implementation decisions
• why a data structure is being used
• anything that could be confusing

After coding

Explain:

• test cases
• edge cases
• time complexity
• space complexity
• possible alternatives

Avoid explaining obvious syntax.

The interviewer cares more about why than what you typed.

Weak vs Strong Communication

Weak

"I'll use a HashMap because it is O(1)."

Stronger

"I need to repeatedly check whether the complement has appeared before. A map lets me keep previously seen values and look them up without scanning the array again, which brings the overall approach down to linear time."

The second explanation connects:

Requirement
     ↓
Data structure
     ↓
Algorithm
     ↓
Complexity

That is what you want.

Don't Memorize Scripts

You may be tempted to memorize sentences such as:

"First I will clarify the problem, then identify the optimal approach..."

Don't.

If you memorize a speech, it can sound unnatural.

Instead, memorize the thinking process:

What exactly is being asked?

What are the constraints?

What is the simplest correct solution?

Where is the repeated work?

Can I remove that work?

What trade-off am I making?

Does the code work for edge cases?

Those questions are reusable across many problems.

A Practical 30-Minute Practice Session

You don't need to spend every study session solving ten problems.

Try this instead.

First 5 minutes

Read one problem.

Do not code.

Write:

Input:
Output:
Constraints:
Examples:
Edge cases:

Next 5 minutes

Explain two approaches:

Simple approach:
...

Better approach:
...

Next 10 minutes

Code the solution.

Talk through important decisions.

Next 5 minutes

Test:

Normal case
Edge case
Large/special case

Final 5 minutes

Explain:

Time complexity:
Space complexity:
Why this approach:
Possible improvement:

This makes your practice much closer to an actual interview.

Build an Interview Mistake Log

After each practice problem, record what went wrong.

For example:

Problem:
Two Sum

Mistake:
Started coding before clarifying output.

Algorithm:
Hash map

Communication:
Explained code too much.

Testing:
Forgot duplicate values.

Complexity:
Correct.

Next focus:
Clarify requirements before implementation.

After twenty problems, this becomes more useful than simply counting how many problems you solved.

You start seeing your own patterns.

Your Preparation Should Measure More Than Problem Count

Suppose Candidate A solves:

150 problems

but cannot explain their approach clearly.

Candidate B solves:

80 problems

and can:

• clarify requirements
• recognize common patterns
• explain trade-offs
• write clean code
• test edge cases
• recover from mistakes

Problem count alone doesn't tell you who is better prepared.

A better practice scorecard is:

Track the weak areas.

Then practice those specifically.

A Karyvio Interview Practice Template

For your next coding problem, copy this template into your notes:

PROBLEM
What exactly is being asked?

INPUT
What does the function receive?

OUTPUT
What must it return?

CONSTRAINTS
What limits matter?

EXAMPLE
What happens with a small input?

EDGE CASES
What could break the solution?

SIMPLE APPROACH
What is the easiest correct solution?

OPTIMIZED APPROACH
What repeated work can I remove?

DATA STRUCTURE
Why am I choosing it?

COMPLEXITY
Time:
Space:

IMPLEMENTATION
Write the code.

TEST
Normal:
Edge:
Special:

FOLLOW-UP
What constraint could change the solution?

The goal is to make this process automatic.

Before Your Next Technical Interview

Don't spend your final preparation days only memorizing solutions.

Practice the complete process:

A good technical interview performance is not:

Question → Code → Done

It is:

Question
   ↓
Understanding
   ↓
Reasoning
   ↓
Implementation
   ↓
Verification
   ↓
Communication

Final Takeaway

You do not need to sound like an algorithm textbook during a coding interview.

You need to make your reasoning visible.

When you receive a problem:

1. Understand what is actually being asked.
2. Clarify assumptions that affect the solution.
3. Start with a simple correct approach.
4. Look for repeated work.
5. Choose a better data structure or algorithm when justified.
6. Explain the trade-off.
7. Write clean code.
8. Test normal and edge cases.
9. State time and space complexity.
10. Stay flexible when the interviewer changes a constraint.

The strongest interview habit is simple:

Don't try to look like someone who already knows the answer. Show that you know how to find the answer.

That is the skill worth practicing.