Recognizing the Pattern Fast

Look at the shape of the problem rather than its wording. Ask what the input is, what the output is, and what operations are allowed. Most questions are one of a small number of shapes wearing different clothes, and the shape tells you the technique before you have written any code.

def has_duplicates(values):
    seen = set()
    for value in values:
        if value in seen:
            return True
        seen.add(value)
    return False


print(has_duplicates([1, 2, 3, 2]))
print(has_duplicates([1, 2, 3]))

The outputs are True and False. The question here might be phrased as detecting a repeated ticket number, or as checking whether a set of identifiers is unique, and the underlying technique is the same either way.

The mechanism is a checklist of structural clues. If the question asks what exists, given a set of things, use a hash set. If it asks about a contiguous range, think sliding window. If it asks for the best answer over an order that must be preserved, think dynamic programming. If the answer depends on a search space with costs, think graph search. If it asks for the best choice that cannot be undone, think greedy.

The trade-off to name is that the checklist gives you a starting hypothesis, not a guarantee. The value is in how quickly you can write the first few lines and test them against a small example, because a wrong pattern hypothesis is discovered in thirty seconds rather than twenty minutes. The other habit worth building is saying your hypothesis out loud, since the interviewer can correct you cheaply then and would rather correct you than let you build the wrong solution.

There are fewer patterns than candidates think. On the data structure side: hash maps for lookups and counting, heaps for the extreme element, stacks and queues for order of arrival, and trees for ordered data with logarithmic lookups. On the algorithm side: two pointers for sorted data, sliding windows for contiguous ranges, binary search for monotone predicates, and a small set of graph traversals for anything with nodes and edges.

The way to keep them in mind is not to memorise lists but to memorise questions. What does the problem ask you to find, the first, the last, the largest, the most frequent, the shortest, the number of ways, the longest run. Each of those questions pulls towards a particular technique: the first or last pulls towards a single scan with a hash map, the largest pulls towards a heap or a scan, the most frequent pulls towards counting, the shortest pulls towards breadth first search, the number of ways pulls towards dynamic programming, and the longest run pulls towards a window or a sequence technique.

The trade-off to name is that a small number of patterns covers a large fraction of the questions that get asked, so the marginal value of learning more patterns drops off quickly. The higher value skill is recognising when a question does not fit any pattern, because then you are working from first principles rather than forcing a template onto it. Another useful discipline is to keep a personal log of the pattern that solved each problem, since the same five or six patterns keep reappearing in different disguises.

Retrace the solution you remember and check every step against the new statement, especially the constraints and the exact question being asked. The classic traps are the small words: at most versus exactly, contiguous versus not contiguous, duplicates allowed or not, and whether you must return the values or only the count.

Change the example. Take the input from the question and work a small case by hand under the new rules, then compare with the solution you already know. If the two disagree, you have found the difference in about a minute, and that minute is far cheaper than debugging the wrong algorithm later.

The mechanism is that familiarity gives you a candidate quickly, and the candidate is only useful if you have verified it against the actual statement. The parts of a problem you must re-check are the ones that change the algorithm: the direction of the ordering, whether the answer is a maximum or a count, and the input size, since a different size can demand a different technique altogether.

The trade-off to name is that raising this concern out loud is nearly always worth it. If you quietly adapt the familiar solution and it happens to be wrong, you have produced a wrong answer with confidence, which is much worse than saying that you want to check the constraint first. Interviewers do not penalise the question, and a candidate who notices the difference is demonstrating exactly the judgement the role needs.