In a frontend interview the algorithm round is rarely about exotic data structures. It leans easy-to-medium — arrays, strings, hash maps, the occasional tree — and what gets scored is not whether you land the optimal solution, but whether you get there in a way the interviewer can follow. They are hiring a colleague, and they are watching how you think under mild pressure. A repeatable method makes that thinking visible.
Why method beats memorization
You cannot memorise your way through this. There are too many problems, and the interviewer can always perturb one you have seen. What you can do is run the same disciplined process every single time, so that even on a problem you have never seen, you look calm, structured, and easy to work with. Two candidates who both reach the optimal answer do not score the same: the one who narrated a clear path scores far higher than the one who stared silently and then typed a correct answer from nowhere.
Step 1 — Clarify before you touch the keyboard
Restate the problem in your own words and ask the questions that pin down the input. How large can it get? Can it be empty? Are there duplicates, negatives, or non-ASCII characters? Is the array sorted? Do I return a new value or mutate in place? What should happen on invalid input? This costs thirty seconds and does three things: it prevents you from solving the wrong problem, it surfaces the edge cases you will test at the end, and it signals that you gather requirements before you build — exactly what you do on the job.
Step 2 — State the brute force and its Big-O, out loud
Before optimising, say the obvious solution and its cost: “I could compare every pair, which is O(n²) time and O(1) space.” This is not a wasted step. It proves you understand the problem, it gives you a correct baseline you can fall back on if you run out of time, and it frames the optimisation as a deliberate improvement rather than a lucky guess. An interviewer will almost always rather see a working brute force than an elegant solution that never compiles.
Step 3 — Name the pattern
This is the heart of it. Most interview problems are one of a small set of patterns wearing a costume. Before writing code, decide which one the input shape is pointing at:
- Sorted array → binary search, or two pointers converging from the ends.
- “Find a pair / have I seen this value” → a hash map or set for
O(1)lookup, trading space for time. - Contiguous subarray or substring → a sliding window that grows and shrinks.
- Top / smallest k elements → a heap of size k.
- Tree or graph traversal → BFS for shortest-path and level-order, DFS for exploring all the way down.
- Overlapping subproblems → memoization, then dynamic programming.
Naming the pattern converts an open-ended problem into a template you already know how to fill in. Saying “this looks like a sliding-window problem because we want the longest run that satisfies a condition” tells the interviewer you have seen the underlying structure, which is worth more than the code that follows.
Step 4 — Code it cleanly
Now write, and narrate as you go: “I’ll keep two pointers, left and right…” Use names a reader can follow, handle the edge cases you already identified in step one, and prefer clarity over cleverness. If you get stuck, say what you are stuck on — interviewers routinely nudge candidates who are visibly reasoning, and can do nothing for one who has gone silent.
Step 5 — Dry-run it
Do not announce you are done. Trace your code on one normal input and on the edge cases from step one — the empty array, the single element, the duplicate. Walk the values line by line. This is where you catch the off-by-one before the interviewer does, and catching your own bug reads as a strength, not a weakness. Finish by restating the final time and space complexity.
The failure modes to avoid
- Jumping straight to code. Skipping clarification and the brute force is the most common way strong coders underperform.
- Silent thinking. If you are not talking, the interviewer has nothing to score and cannot help you.
- Optimising too early. A slow solution that runs beats a fast one that does not exist.
- Ignoring edge cases. Empty input, a single element, and duplicates are where interview code breaks — name them up front and test them at the end.
The method is the same whichever problem lands in front of you. Practise it on the DSA interview questions, and use the decision table there to make step three — naming the pattern — automatic. Then read reading the prompt for the vocabulary that maps a question to its technique.