How to Think Like a Detective in Coding Interviews: The Sherlock Technique

The Quest Begins (The "Why")

I still remember my first coding interview like it was yesterday. I sat down, the interviewer tossed over a whiteboard marker, and the problem flashed on the screen: “Given an array of integers, return the indices of the two numbers that add up to a specific target.” My brain went into overdrive, but my mouth stayed shut. I started typing, silently wrestling with edge cases, and after a painful ten minutes I finally produced a working solution—only to hear the interviewer say, “I’m not sure how you arrived at that.”

That moment stung. I’d solved the problem, but I’d failed the real test: showing how I think. Interviewers aren’t just looking for a correct answer; they want to watch you navigate ambiguity, ask the right questions, and adapt when things get tricky. I realized I needed a repeatable way to narrate my thought process—something I could rely on even when my nerves were jangling like a loose guitar string.

So I went on a quest for a technique that felt natural, didn’t require me to memorize a script, and could be dropped into any problem. After a few failed attempts (more on those later), I stumbled onto a simple three‑step verbal framework that turned my silent struggle into a confident, interviewer‑friendly dialogue. I call it the Sherlock Technique, because just like the famous detective, you start by stating the obvious, then you gather clues, and finally you piece together the solution.

The Revelation (The Insight)

The Sherlock Technique boils down to three exact phrases you sprinkle throughout the interview, each serving a clear purpose:

1. Restate & Confirm – “So, just to make sure I’ve got it right, you’re looking for ___.”
2. Outline the Plan – “I’m thinking of approaching this by ___ because ___.”
3. Narrate Each Step – “Now I’m going to __; this will give me __.”

That’s it. No jargon, no filler. You’re essentially giving the interviewer a live‑stream of your mental model. The magic lies in the exact wording—it forces you to slow down, check assumptions, and keep the conversation flowing.

Why does this work?

• Restating catches misunderstandings early. If you’ve misread the prompt, the interviewer can correct you before you waste time down a rabbit hole.
• Outlining the plan shows you’re not hacking randomly; you’ve considered trade‑offs and can justify your choice.
• Narrating each step turns silent typing into a collaborative walk‑through. The interviewer can follow along, ask clarifying questions, and see that you’re thinking aloud, not just copying code from memory.

I’ve seen candidates who tried to “think aloud” by simply saying, “Um, I’ll loop through the array…” and then trail off. That’s vague and leaves the interviewer guessing. The Sherlock phrasing gives you a scaffold: you always know what to say next, even when your mind goes blank.

Wielding the Power (Code & Examples)

Let’s see the technique in action with the classic Two‑Sum problem.

❌ What NOT to do (The Silent Struggle)

def two_sum(nums, target):
    # I’m just going to brute force it
    for i in range(len(nums)):
        for j in range(i+1, len(nums)):
            if nums[i] + nums[j] == target:
                return [i, j]
    return []

What happened here? I dove straight into code, never explained why I chose a nested loop, never mentioned the O(n²) cost, and never invited feedback. The interviewer had to infer my reasoning, and if I’d made a mistake, they’d have no idea where I went off track.

✅ The Sherlock Approach (With Exact Wording)

Interviewer: “Given an array of integers, return indices of the two numbers that add up to a specific target. You may assume each input has exactly one solution.”

Me (Restate & Confirm):

“So, just to make sure I’ve got it right, you want me to return the indices of the two numbers that sum to the target, and we can assume there’s exactly one valid pair?”

Interviewer nods.

Me (Outline the Plan):

“I’m thinking of using a hash map to store each number’s complement as we iterate. This lets us find the pair in a single pass, giving us O(n) time and O(n) space, which is better than the brute‑force O(n²). Does that sound reasonable?”

Interviewer says yes.

Me (Narrate Each Step – while coding):

def two_sum(nums, target):
    # I’m going to create an empty dictionary to hold value → index
    seen = {}
    # Now I’ll loop through the list with enumerate so I have both index and value
    for i, num in enumerate(nums):
        # For each number, I calculate the complement needed to reach the target
        complement = target - num
        # If the complement is already in the dictionary, we’ve found our pair
        if complement in seen:
            # Return the index of the complement and the current index
            return [seen[complement], i]
        # Otherwise, store the current number’s index for future look‑ups
        seen[num] = i
    # According to the prompt, we should never hit this line, but I’ll return an empty list just in case
    return []

As I typed each line, I said the accompanying comment out loud.

Why this feels different:

• The interviewer hears my reasoning before I write a line, so they can correct me if I’m heading down the wrong path.
• I explicitly mention the trade‑off (hash map vs. brute force) and justify it.
• Even if I make a slip—say, I accidentally write seen[num] = i before checking the complement—I can catch it myself because I’m verbalizing each step, and the interviewer can point it out instantly.

Common Traps to Avoid

Trap	What it looks like	Why it hurts	Sherlock fix
Vague filler	“Um, I’ll just loop through…”	Gives no insight into intent	Use the exact “Now I’m going to ___” phrase
Skipping the restate	Jumping straight into solution	Risks solving the wrong problem	Always start with “So, just to make sure I’ve got it right…”
Over‑explaining irrelevant details	Talking about your weekend while coding	Distracts from the core thought process	Keep each verbal snippet tied to the current code line
Silent debugging	Staring at the screen, muttering under breath	Interviewer can’t follow your fix	Say “I’m seeing that X isn’t matching Y; let me check Z…”

Why This New Power Matters

Adopting the Sherlock Technique changed my interview game dramatically. I went from getting polite “good effort” feedback to hearing, “I loved how you walked me through your thinking—it made it easy to follow.”

The benefits are concrete:

• Higher signal: Interviewers can assess your problem‑solving style, not just your ability to recall a solution.
• Fewer false negatives: Nervous silence no longer looks like lack of skill; your voice shows competence even when you’re typing slowly.
• Built‑in feedback loop: By speaking early, you catch misunderstandings before they waste precious minutes.
• Confidence boost: Knowing you have a reliable script reduces anxiety—you’re not winging it; you’re following a proven pattern.

And the best part? The technique scales. Whether you’re tackling a dynamic programming challenge, a system design sketch, or a simple debugging prompt, the three phrases stay the same. You just swap out the specifics.

Your Next Quest

Ready to try it out? Here’s a quick, actionable challenge:

1. Pick a LeetCode Easy problem you’ve solved before (e.g., “Reverse Integer” or “Palindrome Number”).
2. Set a timer for 10 minutes.
3. Solve it out loud, using the Sherlock phrasing at each stage. Record yourself on your phone or laptop.
4. Play it back and ask: Did I restate the problem? Did I outline a clear plan? Did I narrate each line as I wrote it?

If you catch yourself slipping into silent coding, pause, restate, and continue. Do this a few times a week, and you’ll notice the shift—your thoughts will flow, your interviews will feel more like a conversation, and you’ll start seeing those “aha!” moments from the interviewer’s side.

So go forth, channel your inner Sherlock, and let your thought process be the clue that cracks the case. Happy coding! 🚀