Welcome to InterviewLegend

Give a strong engineer a problem they've never seen, and within about thirty seconds they'll say something like "this is binary search on the answer space" or "this is a sliding window with a frequency map." They aren't smarter than you. They've just trained themselves to see the shape of a problem underneath the surface details, and that shape is almost always one of a few dozen patterns you can learn on purpose.

Three prompts that look unrelated: find the longest substring with no repeated characters, find the shortest subarray summing to at least k, and check whether one string contains a permutation of another. The answers differ; the loop does not. In all three you grow a window on the right until a condition breaks, then shrink it from the left until the condition holds again, and the only things that change are what you track inside the window and what makes the condition break. Write that loop five or six times and those stop being three problems. They become one problem asked three ways, and the third one no longer needs an idea.

This course teaches 14 of those patterns, and between them they cover the vast majority of coding-interview questions at Google, Meta, Amazon, Microsoft, and everywhere that copies their bar. Each one gets built from first principles and then drilled until recognizing it is automatic. None of this is about adding 14 things to memorize; done right it does the opposite, and every unfamiliar problem starts looking like a variant of something you've already solved.

Recognition matters more than volume because of the clock. A forty-five minute round leaves roughly thirty-five minutes of real problem time, and the approach needs to be settled inside the first five of them. Take fifteen minutes to find it and you can still write correct code, but you will be writing at speed with nothing left for tracing your own logic, and that is where the careless bugs live. The twenty minutes that recognition saves go into the unglamorous part, which is walking your own code through an example before someone else finds the bug in it.

The grind fails for a mechanical reason rather than a moral one. Solving a problem with the solution open in the next tab builds a memory of that solution, and what an interview asks for is the ability to generate one from nothing. The two feel identical on the day you do them and come apart three weeks later. A more honest measure than problems completed is problems you could restart cold. Pick something you solved a month ago, give yourself five minutes with no notes, and see whether you can state the approach and the complexity before you type anything. Plenty of people who have finished three hundred problems can do that for forty of them, and the gap between those two numbers is most of what goes wrong in prep.

Every lesson follows the same structure:

Those four run in that order for a reason, and most people want to jump to the third. A template you can copy looks like the portable part of a lesson, so it feels like the part worth having. It is also the part that goes first under pressure, because a template with no intuition underneath gives you nothing to fall back on when a problem is bent slightly out of its usual shape, and interview problems are always bent slightly. Trace the example by hand before you take the template. Watching the indices move is what tells you which line of it is load-bearing and which line is an accident of the example you happened to be shown.

The course is organized by pattern rather than by data structure, and that's deliberate. Nobody in an interview thinks "I need a hash map." You think "I need to find duplicates without an n² scan," and the hash map falls out of that. Learn the patterns and the data structures come along for the ride.

There is a reason binary search comes first and dynamic programming comes last, and it pays to know it before you start skipping around. Binary search leads because it is the smallest complete version of what every later pattern does: hold an invariant, and use it to discard a chunk of the search space you never have to look at. It is also the pattern most people are certain they already know, which makes its boundary cases a useful early humbling. Two pointers and sliding window take the same idea and let the invariant live between two moving indices instead of two fixed bounds. Stacks and queues are the first point where the invariant lives inside a data structure rather than in your loop variables.

The middle of the course is traversal, which is where most of the intimidating problems come from. Depth first search precedes backtracking because backtracking is depth first search with an undo step, and breadth first search follows both because by then the queue is the only new idea in it. Graphs and tries reuse that traversal machinery almost directly, while intervals and bit manipulation are narrower tools with tricks of their own. Dynamic programming sits at the end for an unglamorous reason: it assumes recursion you no longer have to think about and a habit of naming state precisely, both of which get built in the sections before it. Attempted out of order, it is the section that convinces people they are bad at algorithms.

Depends on where you actually are, so be honest with yourself. Start too far ahead and you're building on foundations that hold up fine on easy problems and collapse the moment an interview gets hard.

"I can write code but haven't done interview prep before". Start with the next lesson, How to Study Effectively, then Time & Space Complexity, then Binary Search. Go in order, because each section leans on the one before it.

"I've done some LeetCode but feel stuck at mediums". That stall is almost always a pattern-recognition gap, not a coding one. Start at Binary Search even if you're sure you know it, because the boundary-finding and answer-space variants are exactly where most people quietly have blind spots.

"I'm comfortable with the basics and need to level up for FAANG". Go straight to your weakest sections. Use the end-of-lesson problems as an honest test: solve them cold, without hints, and move on. If you reach for a hint, that's the section to slow down in.

Settle the calendar question before you start. An engineer who can already write code but has never prepped is usually eight to twelve weeks out from interview ready, at six to ten hours a week. What moves you inside that range is how much of this you already saw in school, far more than any difference in aptitude. The reading is the small half. Forty hours of lessons spread over three months is under four hours a week, and everything else goes into problems you get wrong the first time.

If your first onsite is two weeks away, ignore all of that and do something narrower. Pick four: binary search, two pointers, sliding window, depth first search. Work those properly and accept deep coverage of four shapes over shallow contact with fourteen. Spread two weeks across the whole course and you will recognize nothing when it counts. Spend it on four patterns and you walk in genuinely solid on four.

Coach enough engineers through this and one thing stops being subtle: who passes and who doesn't rarely separates on raw intelligence. It separates on how they study.

Do the problems, don't just read the solutions. This is the number-one way people burn months of prep. Reading a clean solution feels like understanding, and it isn't even close. You need the fifteen minutes of sitting stuck before you reach for a hint, because that struggle is the part that rewires how you think.

Explain your approach out loud. In a real interview you narrate your thinking the whole time while you code, so practice that from the first problem. If you can't say out loud why a min-heap beats sorting here, you don't understand the trade-off yet, and the interview is a bad place to find that out.

Review problems you solved correctly. A correct answer isn't the finish line; a clean, efficient one is. When you've solved something, read the walkthrough anyway, because there's often a tighter approach or an edge case you got past on luck.

Go back to finished sections on purpose. A pattern you drilled in week one and have not touched since week two is largely gone by week six, and the loss stays invisible until the day you fail to notice a window problem in front of you. Rework two or three problems from an old section every week. Twenty minutes buys the difference between having covered this course and being able to use it.

One thing this course will not promise: you will still meet problems that do not map cleanly onto anything in it. Everyone does. What pattern work changes is the next ninety seconds. A problem that resists a sliding window and resists sorting has told you something real, and saying so out loud beats a silent stare at the prompt. Ruling the wrong shapes out fast is worth nearly as much as finding the right one.