> to be perfectly blunt [...] the very smart people I know are good at them> and most of the people who “don’t test well” aren’t
It's frustrating to read this same response in every interviewing thread. If I may be equally blunt: it almost always comes from someone showing a distorted understanding of the process, or implying human beings are fleshy robots which are easily deterministically QA'd by automated tests.
For weeding out the worst performers, testing works for lots of people and it works at scale. That's why it's used. That doesn't mean there aren't false negatives, or even that there aren't a lot; it just delivers good enough results for cheap enough that other local maxima aren't worth exploring.
But the industry wants it both ways. They want to cry about a talent shortage where apparently there's no one in the output of this local maximum of process they've chosen, and also claim this choice of process is fine and maybe people should git gud or maybe they're dumb, and also actively refuse to reexamine their decision in spite of its obvious failure.
The very fact of their complaint is evidence the process isn't good enough. Unless they're simply lying, its results are costing them in growth or time-to-market or actual money. If they really feel this pain, they should be finding other options—but they just don't want to.
Where else would this behavior fly?
> ...do a slight modification of breadth first search given 30-60m to sketch it out...
> ...“why can’t I get a $300k/year job without knowing what a trie is”...
I've interviewed at FAANG and elsewhere, pass and fail, and this is simply not what happens. People who defend the process often try to frame it like this and it's just... at best, indifference to the truth. In my experience—and many others', and of everyone who gets on LeetCode with a sigh because they know this—you better not be tinkering with BFS at all. Your session might be scheduled for an hour, maybe closer to 45 minutes, and the interviewer will expect you to correctly solve at least two questions, probably three, and still have time for "any questions for me?" at the end.
Counting introductions and small talk, and allowing you 10 minutes at the end to get one question in about the company, that leaves you (optimistically) with 15 minutes per question—including them explaining it, your clarifying questions, writing code on the board, erasing mistakes, drawing awkward arrows where you oops-forgot a line, and all the rest.
Need a hint? Cool, sure, I guess. Another? Uhh. (You're dumb.)
You don't in any sense have even 30 minutes for your BFS if you expect to pass, and your sketches won't count. That easy trie thing or search-with-a-twist, in actual practice if not in design, is meant for you to solve as fast as you can write it on the board. Otherwise you won't have time for questions 2 and 3, the ones they're really counting. Get ready for a crapshoot of well-chosen problems, pointless memorize-the-answer gotchas, and random applications of DP or topics from computer science papers they "would never ask because that's silly" but really just did.
If you're ok with that, I understand. But please don't say it isn't this because you like it.