… but that's an interview. If you cannot, within the time, demonstrate any ability, why should you be hired?
The question above, as clarified, is not complicated, nor does it rely on memorization or some "trick": anyone purporting to be a SWE should be able to write an essentially de novo solution to it.
(And in my own technical interviews, there are multiple questions, to specifically hedge against any one being "that one question a good candidate is going to miss because it's just not their day". It doesn't happen: it's either all or nothing.)
> If you cannot, within the time, demonstrate any ability, why should you be hired?
It is more likely that the interview process is broken and missing the right candidates, than it is that the interviewees are all mediocre. Most interviews are very non-inclusive the same way that the main track of school is becoming less and less inclusive. Different people need different methods to bring out the best in them.
> It is more likely that the interview process is broken and missing the right candidates, than it is that the interviewees are all mediocre.
Here's a thought experiment for you: if the interview process is so broken, why hasn't some tech company succeeded and become famous for an improved interview process, e.g. "Moneyball style"? My guess is because the process is not actually that broken, at least from the employer's perspective. I'm sure the interview process could be changed to be less regimented and more "inclusive", but that's also likely to reduce it's predictive power (i.e. you're more likely to make bad hires, and from a company's perspective that's almost always worse than missing out on a great hire).
The layoffs that I have seen reported have been reported as being random. I've been involved now in 3 layoffs directly in my career, and 100% of them, the laid off individuals were laid off without regards to skill. The reporting in the media on layoffs happening elsewhere largely matches my experience.
Sure, an argument exists around "you shouldn't've hired that many people", but that is different from an argument of "the hiring process can't discern good hires". The former is a management & long-term planning issue, the latter is how interviews are conducted.
Sure, your day-to-day work may not involve manipulating binary trees. But presumably it does involve working with variables, objects, references, manipulating data of some kind... And if you're comfortable with the fundamentals of those, then this is something you should be able to figure out even if you've never heard of a "binary tree" before, once somebody has sketched it or shown you the definition of their TreeNode class, right?
It honestly baffles me how people consider this something which needs to be drilled or memorized.
There are absolutely algorithmic questions which would fall into that category. But if somebody considers this to be one of them - or something like "find the smallest number in an array" - then I have to question whether they have an understanding of the most fundamental concepts in programming...
Or if they get through each day solely using things they've memorized by rote, or looked up, and they don't really have any idea how any of the foundations they're building on actually operate.
The question above, as clarified, is not complicated, nor does it rely on memorization or some "trick": anyone purporting to be a SWE should be able to write an essentially de novo solution to it.
(And in my own technical interviews, there are multiple questions, to specifically hedge against any one being "that one question a good candidate is going to miss because it's just not their day". It doesn't happen: it's either all or nothing.)