How to Identify Which Algorithm to Use

Two engineers sit down with the same unfamiliar problem. One stares at the description, mentally cycling through every technique, trying each until something sticks. The other reads three lines, notices the input is a directed graph with dependencies, and knows topological sort applies within 30 seconds. Both have solved roughly the same number of problems. Both have been preparing for months. One has trained how to identify which algorithm to use. The other is still guessing.

The gap isn't talent or problem count. It's a skill that almost nobody trains directly.

The phase every platform skips

Every DSA learning resource teaches two things. How an algorithm works (the mechanism) and how to apply it (the problems). What almost none of them teach is the step in between, where you look at an unfamiliar problem and determine which algorithm actually applies.

Algorithm identification: Reading a problem and systematically determining which pattern fits before you write any code. You analyze four diagnostic signals: the input, the output, the required transformation, and the algorithmic invariant that enables it.

This is what separates solving novel problems from only solving ones you've seen before. Most platforms assume this skill develops passively through volume. Sometimes it does develop that way. Someone who solves 500+ problems across diverse categories will start recognizing patterns by feel. But that's an expensive way to build the skill, like learning to read by staring at enough words until the alphabet clicks. It works for a fraction of learners and takes way too long for most.

This missing skill shows up during interviews in a specific, painful way. You've studied topological sort in depth. You understand how it works. You can implement it when someone tells you to use it. But the problem description doesn't say "use topological sort." It says "determine if all courses can be completed given their prerequisites." The bridge between those two sentences is identification, and that bridge rarely gets practised deliberately.

Four questions to identify which algorithm to use

The process is four questions, asked in order. Each one narrows the search space until the right pattern becomes clear.

Identifying which algorithm to use: Five problems

Five problems across five different algorithm families, with all four questions applied each time.

Take Course Schedule, which asks whether you can finish all courses given their prerequisites. Your input is a directed graph where courses are nodes and prerequisites are edges. You need a boolean output, whether everything can be completed. The transformation requires determining whether a valid ordering of all nodes exists. And the invariant confirms your reading: a valid ordering exists if and only if the graph contains no cycle. Topological sort on a DAG produces exactly such an ordering.

Once you've identified the pattern, the implementation follows directly from the invariant:

You don't need to have seen Course Schedule before. You need to recognize "directed dependencies + valid ordering = topological sort."

Now consider Longest Substring Without Repeating Characters. Your input is a string with characters as elements, and you need a single integer representing maximum length. Finding the longest contiguous range satisfying a uniqueness constraint is the transformation. The invariant confirms it: the variable sliding window maintains a window where all characters are unique, expanding when the constraint holds and contracting when it breaks.

The trigger words are "contiguous range" and "optimize length." Those two together point to sliding window before you've finished reading the problem description. Three more problems diagnosed the same way:

One diagnostic process produced five different outputs depending on the problem. The questions stayed constant while the answers changed every time.

Why problems get misidentified

Picking the wrong algorithm happens for specific, predictable reasons.

These traps get worse under time pressure. It's tempting to skip the diagnostic step and jump straight to the first pattern that feels right during an interview. That instinct is completely understandable, but it's also the most common source of wrong starts under a clock.

When the framework points to more than one pattern

Sometimes you'll run through all four questions and end up with two plausible answers instead of one. That's not a failure of the process. It's a signal that the problem sits at the boundary between pattern families, and boundary problems are some of the most common ones interviewers pick.

Consider a problem that asks you to find the shortest transformation sequence from one word to another, changing one letter at a time. The first three questions are straightforward: word list input, single integer output, search through intermediate states. But question 4 is where it gets interesting: you could model this as BFS on an implicit graph where each word is a node, or you could frame it as DP where each state represents a word and you're minimizing transitions.

Both framings are technically valid. BFS wins here because the graph is unweighted and you want the shortest path, which is exactly what BFS guarantees. The DP framing would work but adds unnecessary complexity. When two patterns survive the four questions, break the tie with a simpler rule: which invariant maps more directly to what the problem asks?

This happens more often than you'd expect. Tree problems occasionally straddle DFS and BFS depending on whether you need level order information. The four questions don't always produce a single answer on the first pass. But choosing between two candidates you understand is fundamentally different from choosing among fifteen you haven't filtered.

Two patterns can coexist.

Some problems genuinely require combining two patterns. Certain graph problems need both BFS and union find at different stages. When you hit these hybrid problems, the framework still helps because you've identified which patterns are in play. You're not guessing anymore. You're deciding how to compose known tools.

Recognizing when you've picked wrong

The other thing worth practising is noticing during implementation that your identification was off. A recurrence relation that keeps getting more complex instead of simplifying suggests you might've picked DP when greedy was the right call. A DFS tracking so much state that the function signature has five parameters points toward a different traversal strategy. And when your sliding window's contraction logic doesn't converge, the constraint might not be monotonic, which means sliding window doesn't apply.

Catching a wrong identification at minute 5 is recoverable. Catching it at minute 25 usually isn't. Check for these warning signs after writing the first 10 lines of code, not after finishing the full implementation.

Learning to identify which algorithm to use

This skill doesn't have to develop passively over years of problem solving. You can train it directly, the same way you train the algorithms themselves.

The key insight from learning science is interleaving: mixing practice across different pattern types so you're forced to figure out which pattern applies on every problem. Blocked practice (solving 20 sliding window problems in a row) trains application. Interleaved practice (mixing sliding window, two pointers, DP, and graph problems) trains the selection step. Studies on interleaved math and motor skill practice show the same result: worse performance during training, but significantly better transfer to novel problems.

This is the gap most platforms don't address. LeetCode's default practice mode lets you filter by topic, which is blocked practice. You already know it's a sliding window problem before you read the description. You never have to decide which pattern to use.

Codeintuition is the only platform that teaches this as a separate phase. Every pattern module includes a dedicated identification lesson before any problems begin. You don't learn what the variable sliding window is and then jump to problems. You first learn the cues that tell you when a variable sliding window applies, such as "contiguous range" + "dynamic constraint" + "optimize length or count." Then you practice applying the pattern to problems where you've already been trained to recognize it.

The learning path sequences 75+ patterns this way across 16 courses. Premium covers the full path at $79.99/year, but even the free Arrays course teaches you to recognize 8 patterns covering two pointers, simultaneous traversal, fixed sliding window, variable sliding window, interval merging, and maximum overlap. After completing it, you'll recognize triggers on unfamiliar problems before reaching for the hints.

Six months ago, you would've stared at Course Schedule and tried BFS, then DFS, then maybe DP, burning 25 minutes before arriving at topological sort by elimination. Now you read "directed dependencies" and "valid ordering" and the pattern is clear before you've finished the description. What changed was training the one skill that every other platform assumed you'd figure out on your own.