Are the company tags real?
Do I really need to know this for a company interview?
Many platforms like LeetCode, NeetCode, and their imitators attach company tags to problems: little labels claiming that Google, or Meta, or Citadel asked this exact question. Most people have learned to distrust them, and they're right to. The tags are frequently fake, and even when they were once real, they've usually gone stale. So it's fair to ask the same question of WhiteBox: are ours any different?
At first glance, some tags in the core catalog may look just as suspect. It seems unlikely that a firm like Millennium would sit you down and ask you to fully implement a decision tree from scratch. And to that, I'd say you aren't far off the mark. Data structures like these are far too intricate to build cleanly in a short, pressured interview setting. But despite that, the tags carry real merit, because they aren't claiming what you think they're claiming.
Two kinds of tags
There's a distinction worth drawing between literal tags and conceptual tags. LeetCode-style platforms lean on literal ones: "this exact question was reportedly asked at X." That claim rots fast. Questions leak, get recycled, get pulled from rotation, and the tag lingers for years after it stopped meaning anything. And the signal was thin to begin with; one anonymous report is enough to brand a company onto a problem forever.
WhiteBox's tags don't make that claim. When a Millennium tag sits on a full decision-tree implementation, it isn't asserting that someone was handed that prompt in a 45-minute window. It's asserting that the cluster of concepts and skills the problem exercises (the recursion, the greedy splitting criterion, the numerical care, the clean handling of edge cases under time pressure) has been tested together at that firm. The problem is a vehicle for a skill cluster, rather than a leaked transcript.
Why paraphrase
This is also why you won't find verbatim leaks here. You probably wouldn't be asked the exact question. They are all heavily paraphrased, though the structure stays generally faithful. That's deliberate. The structure is preserved because the structure is where the signal lives; the surface details are abstracted away because the surface was never supposed to be the signal. A candidate who can implement the decision tree cleanly has demonstrably built the muscles the real interview will reach for, even though the real interview reaches for them through a different door.
Where the tags come from
They correlate to interview intel (through either the official interview intel page or by word-of-mouth), and that intel is legitimate. That's the corroboration mechanism: a conceptual claim is judged by whether the skill mapping holds; whether the concepts a tag implies really do show up, together, in that company's process. Interview intel can confirm that. A stale question-leak can't confirm anything except that a question once escaped.
What if a question doesn't have a company tag?
An untagged question isn't an oversight, and it isn't an inferior problem. It usually means one of three things.
The first: the question is so widespread that tagging it would add clutter rather than signal. Some problems are asked essentially everywhere: the foundational patterns that show up across quant, HFT, and systems interviews alike. Stamping thirty company names on one of these tells you nothing you didn't already know. The absence of a tag is itself the information: assume it's fair game anywhere.
The second: only a subset of the question's concepts has been tested at real firms, and the full problem (those concepts in conjunction) hasn't. These problems are deliberately constructed to drill an important and relevant skill or combination of skills, even though no single interview has bundled them exactly this way. The individual pieces are load-bearing; the assembled whole is a training device. Leaving it untagged is the honest move, since slapping a company name on it would overclaim. It would assert a conceptual mapping the intel doesn't actually support.
The third: it reads like an interview problem, and very likely has been asked somewhere (perhaps several years ago), but there's no recent report to anchor a tag to. We'd rather leave it bare than manufacture a tag on a hunch. This is the same discipline that keeps our tagged problems meaningful. A tag has to point at reasonably current intel, so a plausible-but-unconfirmed problem stays untagged until the intel catches up.
Either way, untagged doesn't mean unimportant. It means the tag would either say too little, claim too much, or rest on evidence we don't have yet.
So "are the tags real?" turns out to be the wrong question. "Fake or outdated", the failure mode that plagues LeetCode, describes tags making a false literal claim. WhiteBox's tags make a conceptual claim, and the right test for a conceptual claim isn't "did this exact problem appear," but "does this problem train what that company actually probes." On that test, they hold up.