I think their point is that just because someone can’t whiteboard something doesn’t mean they can’t reason about it.

Have you ever worked with arrogant ones?

The problem with using trivia as a hiring filter is it doesn't do a good job of differentiating between those who don't know a thing, and those who know nothing, unfairly penalizing the former.

But it is easy to filter out those who think they know something when they blurt out correct responses like machine. But in reality they just lerned canned responses. Usually you want to discuss problem to see reasoning. If there is no reasoning just canned response, that is big red flag. That person probably lacks any depth of knowledge and doesn't understand why the question is asked.

Can you predict engineering performance from whiteboard exams? I wager Ravens Matrices would do better than your whiteboard exams.

I did. Some of them, I think, would be able to pass these types of data structures test.

I observed 3 characteristics that they had. (not that I was thinking about this before, but since you posed the question...)

1) They lacked ability to leverage others people work.

(and with that, they lacked the ability to quickly review/search/understand available corpus of knowledge )

2) they were not afraid of complexity in coding, but they seem not be able to 'conceptualize a problem' at level higher than code and technical data structures So that produced very complicate/fragile system.

That, I would call too 'literal' in interpreting the immediate business needs. Normally business needs/requiremetns are observeable gaps in some existing process, or in a high level intent. And as such -- these requirements are not 'designed'. So literally interpreting them causes the solutiosn to be short-term, that look like small 'projects', rather than products.

Specifically, they were not able to design with 'composability' in mind. Where the flexibility did not just come from 'millions of configurable attributes', but instead would come from composing working, well defined pieces - together (at the level of data models & UIs, associated with each composable element, not just code).

3) When analyzing performance problems -- they tended to solve them by optimizing details, and not looking at problem statement itself.

In other words, in my experience -- there is rather huge difference between being able to 'find solutions' from existing corpus of knowledge -- vs -- 'being quick on ones feet' so to speak, and being able to code on white board, data structure algorithms on the interview.

I normally look for people who can construct& compose from existing pieces (that includes not just code, but also articles, research papers, analogies from solutions in other domains, etc).

So I tend to look for folks who demonstrate that they can parse large corpus of knowledge, learn quickly, and reason pragmatically.

Of course, as the person describes their experience -- I tend to look for clues on what they concentrated on, what they found difficult/easy, how they leverage other's people work and why. Did they contribute to open source/etc.

I am not sure if being able to write a topological sort on an interview, automatically precludes a person from being able to reason about composable abstractions. But I just saw folks who do well on these types of interviews, but then not be able to 'increase the average of my teams', that consisted of folks who could not write those things at the interview.

I mean, tsort is already a library function. The important part is knowing it exist.