Stuck on a Coding Interview Problem? Try These Steps

By Hourly DSA · September 22, 2026 · 4 min read

When you're stuck on a coding interview problem, reduce the uncertainty before reaching for another algorithm. Clarify what the answer must contain, solve a tiny case by hand, and describe the simplest correct method. Those steps give you something concrete to improve.

Staring at the prompt and cycling through pattern names rarely helps. A small example can tell you which information matters and which assumption is getting in the way.

First, name the exact output

Suppose the task says to “find a duplicate.” Does it want any repeated value, the first repeat encountered, every duplicated value, or a true/false answer?

Those versions are related, but they don't have identical requirements. Before optimizing, write one sentence defining success.

For this example, use: “Return true if any value appears more than once; otherwise return false.”

Now you can check an approach against a precise contract.

Build the smallest useful examples

Try these inputs:

[]        → false
[4]       → false
[4, 4]    → true
[4, 7, 4] → true
[4, 7, 9] → false

The empty and single-element cases show that one position cannot duplicate itself. The separated repeat shows that checking only adjacent positions won't work on arbitrary unsorted input.

You haven't chosen a data structure yet, but you've already ruled out a tempting shortcut.

When an example gets complicated, shrink it until it tests one behavior. A ten-element input may hide a mistake that two elements expose clearly.

Describe a slow method that works

Compare every pair of distinct positions. If any values match, return true. Otherwise return false after all pairs have been checked.

That's a correct baseline. For n values, the number of pairs is n(n − 1)/2, giving O(n²) time and O(1) extra space.

A baseline is useful because it separates “I don't know how to solve this” from “I don't know how to make this fast.” The second is a narrower problem.

During an interview, explain the baseline briefly and identify its cost. That gives the interviewer a clear view of your reasoning while you work toward an improvement.

Find the repeated question

The pairwise method repeatedly asks whether the current value has appeared elsewhere. Can you keep information from earlier work so you don't repeat the search?

A set of previously seen values answers that question directly. Scan from left to right. If the current value is already present, you've found a duplicate. Otherwise insert it and continue.

With expected constant-time hash-set operations, that gives expected O(n) time and O(n) extra space in the worst case.

The important step was identifying the information to retain. The label “hash set” came afterward.

Change the conditions before committing

What if you cannot use O(n) extra memory? Sorting and checking neighbors becomes another approach to investigate, with a sorting cost and possible mutation of the input. The sorting implementation also affects auxiliary space.

What if the values arrive as a stream? A seen set fits that access pattern, but storing every distinct value can grow without bound unless the problem limits the stream or domain.

Constraints aren't decorative. They determine which improvement is acceptable.

For another example of a condition changing the right approach, see two pointers vs. sliding window.

Use a hint that answers your current question

If you're stuck during practice, look for the smallest hint that addresses the gap. Useful questions include:

Which information from earlier steps would avoid repeated work?
Does the input have an ordering I can exploit?
Can the answer to a smaller case help with this one?
What property must stay true as I move a boundary?

If you read a solution, close it and reconstruct the key idea on a different small input. Copying the implementation while it's visible doesn't show whether you can reproduce the reasoning.

In a live interview, ask a precise clarification or describe the obstacle aloud. “I'm looking for a way to avoid rescanning the prefix” communicates more than silence.

End with a question you can revisit

A useful takeaway from this example is: “When I need to detect a repeated value, what information should I preserve during a scan?”

Hourly DSA gives you short opportunities to practice that kind of approach selection. For a repeatable way to keep the lesson, use this DSA mistake-review method. One clear correction is easier to carry forward than a page of copied code.