Coding pattern drill.
Pick a pattern. Start the timer. Work three problems of escalating difficulty (easy → medium → hard). Reveal the approach if you're stuck; open the deep dive after the timer ends. The whole loop fits inside an hour for most patterns. Built for L5 / L6 prep where pattern recognition matters more than raw LeetCode reps.
Two pointers
A pair of indices walking a sorted array (or string), each moving on its own trigger.
Open the deep dive →- 01
Pair sum in sorted array
Given a sorted array and a target, return the pair of indices whose values sum to the target.
- 02
Container with most water
Given heights[n] representing vertical lines, find two that hold the most water.
- 03
Trapping rain water
Given an elevation map, return the total water trapped between bars.
How to use this drill
Pick a pattern. Don't open the approach. Set the timer. Work the three problems in order — easy first to warm up, then medium, then hard. If you stall for more than five minutes on a problem, reveal the approach (this is what the button is for — not cheating). After the timer ends, open the deep dive and the LeetCode page for any problem you couldn't finish.
One pattern per session works well. The point isn't to grind sixty problems in a day; it's to recognise the right tool when an unfamiliar problem appears in an interview. Five patterns a week, two weeks, you've covered the canon.
Why these twenty patterns
This is the set that maps to roughly 90% of the coding problems in senior-IC interview loops at FAANG-tier companies. It's the same set indexed by Educative's Grokking the Coding Interview, by Sean Prashad's pattern list, and by every other widely-recommended pattern taxonomy. We organised it the same way to make cross-referencing easy.
Within each pattern, the three problems are picked to span the difficulty range. The easy one is usually a textbook example. The medium is the most-asked variant. The hard one is the trick variant that interviewers reach for when they want to stress-test the pattern.
Common mistakes
- Solving without saying which pattern you're using. Interviewers grade pattern recognition. Even if you go straight to code, narrate: "this looks like a sliding-window problem because we need contiguous subarrays meeting a constraint".
- Memorising solutions instead of recurrences. The recurrence is what generalises. If you remember "edit distance is O(m·n) two-row DP" you can derive the code; if you remember the code, you can't derive a variant.
- Skipping the easy problem. The easy one anchors the pattern; the medium and hard are variations. Start cold on the hard and you waste 10 minutes recovering the pattern's shape.
- Coding before pseudocoding. Two minutes of pseudocode prevents 15 minutes of debugging. State the invariants of each loop, the base cases of each recursion, before writing real code.
- Ignoring the test inputs. Empty array, single element, all same, sorted, reverse-sorted — every pattern has edge cases. Name them at the start; check them at the end.
Frequently asked questions
Are these LeetCode problems?
Yes — the LeetCode link on each problem opens the canonical version. We picked LeetCode because it's the most-referenced source in interview prep; the same problems appear under other names on HackerRank, Codeforces, and on company-internal practice systems.
How many patterns do I need to know for an L5 round?
If you can confidently solve the medium problem in fifteen patterns, you're ready. L6 / staff loops tend to ask harder mediums or easier hards across the same set, so the difference is depth within each pattern, not breadth across them. Spending an extra week on the hardest five patterns beats adding ten more patterns at shallow depth.
What if the approach hint isn't enough?
Open the deep dive linked at the top of the page — each pattern has a long-form explanation with worked examples and visual intuition. The deep dives go into the recurrence derivation, common variants, and where the pattern appears in production code.
Should I write code on this page or somewhere else?
Somewhere else. The page is a problem prompt + approach reveal, not a code editor. Use your editor of choice — LeetCode's, a local repl, or paper for whiteboard practice. Practising on paper for at least a few problems matters if your loop is in-person.
Why no scoring or progress tracking?
Streaks optimise for the wrong thing. The metric that matters is "can I solve a fresh medium in this pattern within 15 minutes", not "how many days in a row did I open this page".