[mattsfrey]

This seems extremely off to me - from my POV who the hell has time to study algorithms and implementing data structures every time they need to find a job? Trying to make sure I can whiteboard a random CS problem from a massive set of potentials on the fly in front of observers is drastically more involved and requires much more time that serves no other purpose than facilitating interviewing, versus just spending an hour of my time programming a solution to a problem at home.

[charleslmunger]

I think it may depend on how much your day-to-day work involves data structures and algorithms.

Almost any work on compilers will involve good working familiarity with graphs

Work with concurrency will tend to involve linked data structures, like treiber stacks, or modeling computations as directed acyclic graphs of data dependencies

Working in a memory constrained environment tends to involve data structures and algorithms tailored to that domain, etc.

Now it's totally true that many algorithms questions just reduce to brain teasers, or are so esoteric and interview-specialized (Find out if this linked list has a cycle in O(1) space!) that they only serve to stoke the egos of the interviewer. But I wouldn't say that using algorithms or implementing a data structure is a skill that only exists to facilitate interviewing - and being able to explain your thought process as you work is really important when making contributions to other teams' code. I try to focus my interview questions on miniature versions of problems I've actually had to solve in the course of my job. For example, the futex state machine I wrote here:

https://android-review.googlesource.com/c/platform/art/+/810...

If you subtract the interrupt and timeout handling, you have a real problem with a simple, approachable (for someone with some concurrency knowledge) solution, and you only need to know about two futex calls which have simple behavior and are easy to explain in limited time. I wouldn't ask this question of someone looking for a web development position; but then again, I don't interview those candidates because I know nothing about web development. But it's a nice question for someone who listed concurrency on their resume.

[candybar]

Most of the top employers in the market have similar types of interviews so you have to study anyway unless you want to rule out all of them and any time spent preparing for such interviews amortizes across all of them. Meanwhile, a take-home test is almost always a one-off and takes much longer on a marginal basis and rarely is even used to make the final decision - every time I've done a take-home, I've also had to go through the full interview loop.

Also, "an hour of my time programming a solution to a problem" is likely not an actual work-sample/take-home - it's likely a replacement for a phone-screen that doesn't require an engineer to conduct, thus can be given to many more people to keep the top of the funnel large. The only time I've done a real take-home in less than 10 hours, it was rejected for not being polished enough.

[dunpeal]

> The only time I've done a real take-home in less than 10 hours, it was rejected for not being polished enough.

Because you were competing with folks who were unemployed and probably invested 30+ hours in it.

[dunpeal]

Not sure what you're arguing.

I'm fine going through tough technical interviews.

I'm not fine spending 3-5+ hours on some trivial coding task that can be gamed and was issued to me by folks who may not have even thoroughly checked my resume.

Given the current supply/demand curve, and the fact that top employers like FAANGs do not require this sort of time and effort (and for a good reason), I don't have to jump through that hoop.

[tdestan]

I think what they're arguing is that since most engineers don't use the algorithmic knowledge on a day-to-day basis (and are thus likely to be rusty), the time they'd need to spend reviewing/prepping to pass a whiteboard coding interview is greater than the time it would take to do the work sample.