[marginalia_nu]

> (The weakness of this study is we didn't follow up with people. We only knew if our candidates got hired, not how well they did after they were in the door, as employees. So we might have just been mirroring the same biases the companies themselves have in their hiring processes.)

This is some weakness. Surely this is the outcome that's interesting.

I also suspect there's likely a correlation between how hard someone is trying to get hired and the freshness of their CS skills.

Chances are a motivated candidate will have been brushing up on CS because it's such a trope to be grilled on those types of questions; that same candidate likely prepared for other interview questions as well and I would indeed expect that to increase the odds of getting hired.

Since nobody walks around with perfect recall of the types of algorithms that crop up in the classic tech interview, it's fairly safe to assume the CS part of the interview is a direct measure of how much preparation the interviewee has done.

[josephg]

> Since nobody walks around with perfect recall of the types of algorithms that crop up in the classic tech interview, it's fairly safe to assume ...

I'd love to have data on that.

I know its really common for engineers to never touch this stuff in their day to day work. Most product teams don't need any of this knowledge at all. So asking about it in an interview is a massive waste of time.

But personally, I've used a lot of these algorithms while working on collaborative editing for the last few years. For diamond-types, I ended up writing my own b-tree and skip list implementations, and I make heavy use of binary search, BFS, DFS and priority queues. I've used priority queues in plenty of projects - like, years ago I made a library to mock out timers in nodejs for our test suite so we didn't have to wait for real timeouts to trigger in our test suite.

But I've got no idea what percentage of working engineers use any of this. 5%? 1%? 0.01%? On the surface, it seems nowhere near useful enough to justify how often these questions show up in interviews.

[marginalia_nu]

Well part of the reason I'm skeptical of how who would actually be able to pass these interviews without cramming for them based on the fact that I too have used a fair number of the algorithms (because as mentioned, internet search is a fractal of challenging CS problems) and would almost definitely not pass such an interview.

Just because I've implemented a binary search a few times, and a b-tree, and a skip list, and various sorting and intersection algorithms doesn't mean I can reconstruct them on a whiteboard from memory. What it amounts to is that I have an upper quartile understanding of the underlying idea and the general quirks (among practicing programmers), but not much more than that.

[josephg]

> would almost definitely not pass such an interview.

If you would fail an interview like this, it’s not calibrated correctly. I know it’s unsatisfying, but nobody gets perfect marks on assessments like this by design. Nobody is expecting you to program up a correct btree on a whiteboard in an interview. Just being able to speak in detail about data structures and algorithms from practical experience is a very strong signal in a candidate. Let alone being able to explain high level concepts, and talk about when they’re useful and maybe explain some implementation details. That’s great!