The 5-Step Mental Framework for Identifying Algorithmic Patterns in 60 Seconds

One of the biggest myths about coding interviews is that you need to memorize hundreds of LeetCode problems.

You don't.

What separates experienced engineers from beginners isn't how many problems they've solved—it's how quickly they recognise the underlying pattern.

When I look at a new algorithm question, I don't immediately think about code.

I spend the first minute asking a series of questions.

That one minute often saves me twenty.

Here's the mental framework I use to identify the right algorithmic pattern in under 60 seconds.

Step 1: What Is the Input?

Before thinking about algorithms, understand what you're working with.

Ask yourself:

• Is it an array?

• A string?

• A linked list?

• A binary tree?

• A graph?

• A matrix?

• An interval list?

• A stream of data?

The data structure usually hints at the solution.

For example:

• Arrays often lead to Two Pointers, Sliding Window, Prefix Sum, Binary Search, or Dynamic Programming.

• Trees suggest DFS, BFS, recursion, or tree traversals.

• Graphs typically involve BFS, DFS, Union-Find, Topological Sort, or shortest-path algorithms.

The input is your first clue.

Step 2: What Is the Question Really Asking?

Ignore the story.

Focus on the operation.

Common requests include:

• Find...

• Count...

• Search...

• Merge...

• Detect...

• Validate...

• Optimise...

• Schedule...

• Minimise...

• Maximise...

For example:

"Find the shortest..."

→ Think BFS, Dijkstra, or Binary Search on the answer.

"Find all combinations..."

→ Backtracking.

"Find the maximum subarray..."

→ Kadane's Algorithm.

The wording often reveals the pattern.

Step 3: What Constraints Matter?

The constraints are often more important than the problem statement.

Ask yourself:

• Can I sort the data?

• Does order matter?

• Are duplicates allowed?

• Is the data already sorted?

• Can I modify the input?

• Is extra memory acceptable?

• What are the limits on n?

Then estimate complexity.

If n = 100

Almost anything works.

If n = 100,000

O(n²) is probably too slow.

If n = 1,000,000

Aim for O(n) or O(n log n).

Constraints eliminate many possible solutions before you write a single line of code.

Step 4: Which Pattern Fits Best?

Most interview questions fall into a surprisingly small number of reusable patterns.

Here are some of the most common:

Arrays

• Two Pointers

• Sliding Window

• Prefix Sum

• Monotonic Stack

• Binary Search

Trees

• DFS

• BFS

• Lowest Common Ancestor

• Tree DP

Graphs

• BFS

• DFS

• Topological Sort

• Union-Find

• Dijkstra

• Minimum Spanning Tree

Dynamic Programming

Use DP when you see:

• Optimal solution

• Overlapping subproblems

• Repeated calculations

• "Maximum"

• "Minimum"

• "Number of ways"

Backtracking

Perfect for:

• Permutations

• Combinations

• Sudoku

• N-Queens

• Word Search

Greedy

Greedy often appears when:

• Local decisions produce the global optimum.

• Sorting simplifies the problem.

• Interval scheduling is involved.

You don't need hundreds of algorithms.

You need to recognise around 20–30 core patterns.

Step 5: Validate Before You Code

Before touching the keyboard, mentally test your approach.

Ask:

• Does it work on an empty input?

• A single element?

• Duplicate values?

• Negative numbers?

• Very large inputs?

• Worst-case scenarios?

Many interview mistakes happen because candidates rush into implementation without checking their reasoning.

Five minutes of planning can save thirty minutes of debugging.

The Pattern Recognition Cheat Sheet

When I see a problem, my brain runs through something like this:

✅ Sorted array? → Binary Search or Two Pointers

✅ Contiguous subarray? → Sliding Window or Prefix Sum

✅ Parent-child relationships? → Tree Traversal

✅ Connections between nodes? → Graph Algorithms

✅ Shortest path? → BFS or Dijkstra

✅ All possible choices? → Backtracking

✅ Maximum or minimum with repeated decisions? → Dynamic Programming

✅ Merge overlapping ranges? → Sorting + Intervals

✅ Fast lookups? → Hash Map or Hash Set

After enough practice, this becomes almost automatic.

Why This Framework Works

Beginners try to remember solutions.

Experienced engineers recognise patterns.

That's a huge difference.

Instead of asking:

"Have I seen this exact problem before?"

Ask:

"Which family of problems does this belong to?"

Once you identify the pattern, the implementation becomes much easier.

Coding interviews are less about memorising answers and more about building a mental library of reusable problem-solving techniques.

The good news?

That library is much smaller than most people think.

Master the patterns, and you'll solve far more problems with far greater confidence.

What's your favourite algorithmic pattern—or the one you struggled with the most before it finally clicked? Share your experience in the comments!