DEV Community: interview pitch

The 30-Day Coding Interview Prep Plan (For People Who Don't Have 6 Months)

interview pitch — Thu, 10 Sep 2026 08:14:23 +0000

Most interview prep advice assumes you have 3-6 months and unlimited free evenings. Most people don't. Maybe you got a call for an interview loop in three weeks. Maybe you're job hunting on top of a full-time job. Maybe you just don't want to spend half a year grinding LeetCode before you feel "ready."

Here's a realistic 30-day plan that assumes 1-2 hours a day, and focuses on the things that actually move the needle in an interview — not just problem count.

The plan only works if you stop doing this first

Before the schedule: the single biggest time-waster in interview prep is solving random problems in random order with no plan for why you got one wrong. If a problem stumps you and you just look at the solution, read it, and move on — you'll forget it in a week. You have to know which pattern you missed, not just which problem you missed.

That's the whole plan, really: organize your practice by pattern, not by problem number.

Week 1 — Foundations + the 4 highest-frequency patterns

Spend day 1 reviewing time/space complexity and the patterns you'll drill: two pointers, sliding window, hashmaps, and binary search. These four alone cover a disproportionate share of "easy" and "medium" interview questions.

Days 2-4: two pointers + sliding window (aim for 3-4 problems per pattern, timed)
Days 5-6: hashmaps for frequency/lookup problems
Day 7: binary search, including the "search on the answer" variant that trips people up

By end of week 1, you should be able to name the pattern in a new problem within 2-3 minutes, even if you can't solve it yet.

Week 2 — Trees, graphs, and recursion

This is where most people's pace collapses, because trees and graphs have more variations than arrays. Don't try to memorize every traversal — understand the three or four templates (DFS, BFS, backtracking, and topological sort) deeply enough to adapt them.

Days 8-10: tree traversals + BST properties
Days 11-13: graph BFS/DFS, including grid-based problems (very common)
Day 14: recursion + backtracking basics (permutations, subsets)
Week 3 — Dynamic programming + a system design primer

DP is the pattern people fear most, and it's also the one where "practice by pattern" pays off the most, because most DP problems reduce to a handful of shapes (0/1 knapsack, unbounded knapsack, longest common subsequence, and interval DP).

Days 15-18: DP — 1D problems first (climbing stairs, house robber), then 2D
Days 19-20: if your target role includes system design, start now — don't leave it for the last week. Learn the vocabulary (load balancers, caching, sharding, CAP theorem) even before you can design a full system end to end
Day 21: rest or catch-up day — use it, don't skip it
Week 4 — Mock interviews and weak-spot triage

This is the week most self-taught plans skip entirely, and it's the highest-leverage week you have.

Days 22-25: timed mock interviews (with a friend, mentor, or a structured tool) — explaining your thinking out loud is a completely different skill from solving quietly, and you only build it by doing it
Days 26-28: revisit your weak pattern, not a random new one. If sliding window kept tripping you up in week 1, redo it now with fresh eyes.
Days 29-30: light review only. Sleep matters more than one more problem at this stage.
What actually separates a "pass" from a "borderline pass"

Having reviewed a lot of prep timelines, the difference usually isn't raw problem count. It's:

Talking through your approach before coding — interviewers are grading reasoning, not typing speed
Knowing your weak pattern and deliberately drilling it, instead of doing more of what you're already good at
Getting real timed practice under mild pressure before the actual interview, so the format isn't a surprise

If you want a structured way to follow this — organized by pattern instead of random problem lists, plus mock interview practice and language-specific Q&A — I built [InterviewPitch ](https://interviewpitch.com/)around exactly this approach. It's free.

What's your weak pattern? Curious what trips people up most under time pressure — drop it in the comments.

7 DSA Patterns That Show Up in Almost Every Coding Interview

interview pitch — Wed, 09 Sep 2026 10:05:37 +0000

If you've been grinding LeetCode without a plan, you already know the problem: there are thousands of questions, but only a handful of underlying patterns. Once you recognize the pattern, most "new" problems stop feeling new.

Here are the 7 patterns that keep showing up across interviews at companies of every size — and how to recognize them fast.

Two Pointers

Signal: Sorted array, or you're comparing pairs/windows from both ends.

Classic problems: Pair sum in sorted array, container with most water, remove duplicates in place.

Why it works: You collapse an O(n²) brute-force scan into O(n) by moving two indices toward each other based on a comparison.

Sliding Window

Signal: "Longest/shortest substring/subarray that satisfies X."

Classic problems: Longest substring without repeating characters, max sum subarray of size k, minimum window substring.

Why it works: Instead of recomputing a window from scratch every time, you slide it — adding one element, removing one — keeping the computation incremental.

Fast & Slow Pointers (Tortoise and Hare)

Signal: Anything involving cycles or finding a "middle" without extra space.

Classic problems: Detect a cycle in a linked list, find the middle node, find duplicate number in an array.

Why it works: Two pointers moving at different speeds will eventually meet if there's a cycle — no hash set required.

Merge Intervals

Signal: You're given a list of ranges and need to combine, insert, or check for overlaps.

Classic problems: Merge overlapping intervals, insert interval, meeting rooms.

Why it works: Sort by start time first — almost every interval problem becomes trivial once sorted.

Top-K Elements (Heap)

Signal: "Find the k largest/smallest/most frequent..."

Classic problems: Kth largest element, top k frequent words, k closest points to origin.

Why it works: A heap keeps the k best candidates without sorting the entire dataset — O(n log k) instead of O(n log n).

Backtracking

Signal: "Generate all possible..." or "find all valid combinations."

Classic problems: Permutations, subsets, N-Queens, Sudoku solver.

Why it works: You explore a decision tree, and prune branches early the moment they can't lead to a valid answer — that pruning is what keeps it from being pure brute force.

Dynamic Programming (the one everyone fears)

Signal: "Maximum/minimum/number of ways to..." with overlapping subproblems.

Classic problems: Climbing stairs, coin change, longest common subsequence, knapsack.

Why it works: You cache the answer to subproblems so you never recompute the same thing twice. The trick isn't the code — it's correctly defining the state and the transition.

How to actually practice this (not just read about it)

Recognizing a pattern in an article is easy. Recognizing it cold, in a 35-minute interview, under pressure, is a different skill entirely. A few things that actually move the needle:

Drill by pattern, not by difficulty. Doing 10 sliding-window problems back to back builds pattern recognition far faster than doing 10 random "medium" problems.
Time yourself. If you can't identify the pattern in the first 3 minutes, you need more reps on that pattern specifically, not a harder problem.
Explain out loud as you solve. Interviewers are grading your reasoning, not just your final code.

If you want a structured, topic-wise way to drill these (plus language-specific interview Q&A, system design, and mock interviews), I put together InterviewPitch — it's free and organized so you can practice pattern by pattern instead of jumping between random blog posts.

What pattern do you find hardest to spot under pressure? Curious what trips people up most — drop it in the comments.