What WhiteBox actually trains

WhiteBox is not a problem list. It is built to train two things a problem list cannot: synthesis, and the index of domain knowledge that makes solutions visible in the first place.

Synthesis: why the core catalog

The skill worth building is synthesis, and implementation is where you practice it under controlled conditions. Reasoning about a system means holding its pieces in your head at once: what each one has to guarantee, the techniques required to fulfill each requirement, and how they constrain each other. That's hard to learn on a real system, because a real system buries the reasoning under everything incidental, like the build setup, the legacy decisions, the ten files you read before the relevant one makes sense. Implementing something self-contained strips all of that away. It doesn't remove the friction entirely. It trades the incidental noise of a real system for one deliberate kind: the noise of writing the code itself. That trade is the whole point. The code is friction you can put in front of a judge, something with a correct, expected behavior you either match or don't, which means the skill can be trained and measured in isolation instead of tangled up in everything a real system drags along.

And yes, a model can probably one-shot questions like "implement vector" or "implement a decision tree." Most of these exercises are one-shottable, and that's easy to read as proof they're pointless. It's the opposite. A model solves them precisely because both things it needs are already handed to it. The spec is complete, so all that's left is translating it into code, which is the part models are best at. And the problem is standard, so the model already carries the knowledge of how the pieces fit, because that fit has been worked out a thousand times before. Both of those are exactly what the exercise is supposed to build in you. When you do it yourself with minimal help, you're not just practicing the translation. You're deriving why these pieces go together instead of receiving it pre-assembled, which means you come away both better at connecting techniques and with a deeper understanding of each component. The model having that knowledge baked in is the tell: that knowledge is the prize, and letting the model supply it is how you never acquire it.

So you might ask the obvious question: then why not test that directly? Drop the implementation and just test whether someone can take a goal, name the techniques, and assemble them into a spec. The honest answer is that you can't grade that in a controlled loop with a right and wrong answer, and the whole value here came from having a judge that does. If you're confident you don't need the reps, there is a real alternative, which is to go build projects. That's the same synthesis, just ungraded and in the open. But notice who can already do it: the people who build real projects are almost always already strong at implementation, because that's how they got there. "Just build projects" isn't a way around implementation. It's implementation with the training wheels off.

That's why we built the core catalog. Real work doesn't come with a spec, it comes with an idea, and nobody hands you the components and their contracts. You start from "I want to build X" and have to decide what X decomposes into, which techniques realize each piece, and how they connect. Practicing that on something like vector, where the spec is small enough to fit in your head, is the rehearsal that lets you do it later on specs that are yours to write and systems large enough that getting the decomposition wrong actually costs you. If you've already built something big and real, you probably don't need us. Most people haven't, and that's usually exactly why they're stuck.

Domain knowledge: the index that makes solutions visible

Nobody disputes that domain knowledge matters. You can only choose among approaches you know exist, and you only know they exist by having learned them. The real question is why we train it the way we do, with questions on things that look like trivia. Why should it matter whether you can define the most vexing parse or explain how an OS schedules threads, when you could look it up the moment you need it?

Because the trivia isn't the knowledge, it's the index to it. Knowing that thread scheduling has rules, that a parse can be ambiguous in a specific named way, that a structural problem has a known shape, is what makes those ideas reachable. Without the index, whole categories of solution aren't just hard to find; they're completely invisible. You don't weigh them and reject them, since you never see them at all. The expert's edge isn't speed, it's that more of the solution space is visible to them from the start.

Take the things that feel like trivia until they aren't. Knowing how an OS schedules threads is what turns a service that stalls under load from a week of guessing into "the problem could be lock contention, look there." Knowing what the most vexing parse is turns brace initialization from a rule you follow because you were told to into a fix you understand, which is what tells you when it applies. One is recognizing the problem, while the other is understanding the solution you already use. Both come from knowing specifics about how things work, and without that, the behavior is just weather, something that happens to you that you can only react to.

Which is the real answer to "can't I just ask AI to fix it?" The model can fix the problem you bring it, but you have to recognize there's a problem of that kind to bring. AI can resolve a priority inversion once you've named the stall as one. It can't tell you that's what you're looking at. The person without the so-called "trivia" knowledge doesn't ask the wrong question, they don't even know there's a question to ask, so the facet stays invisible, fixable in principle and untouched in practice.

That's why we have these types of questions. The point isn't to make you recite how the scheduler works, but rather to make the concept fire when you meet it in the wild, so the day a real system behaves a certain way, you already know which shelf to reach for. Look something up once and it evaporates once the problem is resolved, coming back to haunt you another day. Build the index and it's there every time the shape returns.

Algorithms Roadmap & DSA

So the first thing to understand is that you get good at solving problems by solving problems. More specifically, solving problems you haven't seen, not by watching other people solve them, or re-solving the same 150 problems. Everything else follows from that. There is a good blog written by LGM umnik, which I think also transfers to interview prep.

Pick a single archive and stick with it for a while. When I mean archive, it means a site with a lot of problems. This could be Leetcode, Codeforces, AtCoder, CSES, USACO, it doesn't really matter. The best places to begin are AtCoder's Beginner Contests and the CSES Problem Set, both of which give you clean, standard problems. LeetCode is fine to keep for interview-format practice, but in my opinion the community creates a lot of traps in terms of improvement (see other guides for my opinion on leetcode, as it's outside of the scope of this one). For beginners especially, the environment you grow up in matters way more than the problems themselves.

From there, work through the early roadmap topics: two pointers, sliding window, prefix sums, binary search, stacks and queues, recursion, graph traversal, and basic dynamic programming. There shouldn't be a fixed order. Learn these techniques because they are the most reusable concepts and they are essentially prerequisites before you can solve more complicated problems. In our algorithms roadmap, you could choose to focus on the starred problems in each topic and follow your weak spots rather than a rigid sequence. We don't want you to feel like you must follow anything strictly. If you can solve level 5 to 6 problems routinely on the first try and within reasonable time, you can already crush most big tech interviews.

Your improvement loop should look something like this.

Use the roadmap as a map, not a checklist

The roadmap is a map rather than a checklist, and the distinction matters. A strict linear sheet makes beginners feel they have to complete every step in order before they are allowed to move on, and this one is built to be used the opposite way, so you should skip around it based on what you need and what you are curious about. The earlier topics tend to be the highest return on your time and the most directly applicable to interviews, which makes them a sensible place to start, but that is a reason to start there, not an obligation to finish them in sequence. Jump to what interests you, drop back to fundamentals when something later exposes a gap, and let your understanding build organically instead of mechanically.

You will also notice AtCoder, CSES, and contest problems sitting alongside the more familiar interview ones, and that is deliberate. The common belief that competitive programming is scary or irrelevant or overkill is simply wrong, and the resources themselves are some of the best that exist anywhere. AtCoder and CSES in particular give you cleaner statements and better test cases, and they force you to understand the underlying algorithm rather than pattern-match your way to a template. The whole roadmap is hand-picked from CSES, USACO, and contest-style problems by people who have actually competed, and it is selected for the ideas that generalize rather than the patterns that get memorized. Competitive programming is a strict superset of interview problems: the techniques transfer downward cleanly while the reverse does not hold, and reaching Expert, somewhere around 1600, is already enough to make most big tech rounds feel easy.

When to look at the solution

Not yet, but not never either, because the struggle is the training and skipping it teaches you almost nothing, so the real question is knowing when to stop. The usual rule, stuck for N minutes and then open the solution, is the wrong one, because a clock has nothing to do with whether more thinking will actually get you anywhere. Open the solution by decision instead, based on whether you still have anything left to try, and treat an editorial as a fixed amount of insight that you only get to spend once: if you still have ideas to try, or you feel close, keep going, and if your list of things to try is genuinely empty, or you are about to give up and forget the problem rather than work on it, then reading it is worth more than the struggle you have left. ko_osaga put this well on Codeforces:

When you do read it, do not just nod along and move on, because you understand a solution the instant you see it and that is not at all the same as being able to produce one. Close the editorial, rebuild the solution yourself from scratch, and then come back a few days later and solve a variant with one constraint changed, because that last part is what actually makes it stick. What you are really after is the link between the problem and the idea, why these constraints point to this technique and not another, because if you can reproduce the steps but cannot reconstruct that link, you have memorized a route instead of building the intuition.