[kazarov]

I'm pretty sure there is a positive correlation, just because people who tend to be good at competitions usually do them because they like computer science in general, so they learn other stuff too (and they are likely smart). And this is also a reason why this side is tested so much in interviews - it is easy to test and the result is somewhat significant.

Now, most good software engineers would probably not be very good at competitions, because competitions require certain specific skills that are not useful outside of competitions. And that's why good interviews don't put too much weight on algorithmic skills.

[goostavos]

It sounds like it may have been awhile since you've interviewed. The modern "good" interview is all data structure and algorithm white boarding nonsense. For me, who is not a competitive programmer, the standard interview prep is spending a couple of hours on Hacker Rank every day and making sure I can delete a node in a binary tree on a white board without so much a missing semicolon. For some reason that signals "good developer" more than a catalog of work on github, big name companies, or experience in general.

[rs86]

From my experience i'd rather work with programmers with strong CS skills. They put out better code

[seanp2k2]

I'd rather work with the ones who actually care about the people they're solving problems for vs the ones who can write bubble sort with no reference material, which happens in the real world precisely never. Employers pay developers to solve problems, not necessarily to write the most efficient code possible. I get that it's a craft and it's good to understand what happens under the hood, but you can get pretty damn far solving actual business problems for people without having to care which brand of sort ES2016 uses. These skills in micro-optimizations / textbook CS don't help much with understanding customers and solving their problems at the end of the day, so they're really not that valuable for many business scenarios. I think that a lot of engineers in this industry forget that they're not generally paid to write the most efficient data structures and algorithms for 40 hours a week, and that ironically, attempting to do so would very likely not be the most efficient means of increasing shareholder value. Can't see the forest for the B-trees, if you will.

https://github.com/poteto/hiring-without-whiteboards has a list of companies who don't participate in this particular flavor of shenanigans.

[rs86]

I don't think knowing details of algorithms is why strong CS skills are important.

Understanding CS teaches a lot about seeing abstractions and choosing between different levels of abstraction and problem solving. It greatly helps modelling business problems as software. I don't think it is important as an end in itself.

[z3t4]

being good at physics doesnt help you jump higher. its good to know theory, but to be good at something you need practice.

[BoiledCabbage]

True, but being good at physics helps you build a better airplane.

And I'd argue programming is closer to building an airplane than it is to the almost innate skill of jumping.

[kazarov]

I interviewed this week. While there were a few whiteboard coding questions that I personally wouldn't ask, most of the interviews were quite reasonable (mostly algorithmic still, but it was in robotics, so understandable). But yeah, I actually don't understand why people insist on using a whiteboard so much. Everybody has a computer these days and typing is much faster.

At my previous company (not robotics) I conducted a lot of interviews and I think we hit a good balance between algorithmic problems and design/architecture ones. Then again, even algorithms questions can be formulated as real world problems - it help weeding out obvious brain teasers. We also didn't asks people to write code on the whiteboard - there was a separate coding exercise.

I don't even think that asking about algorithms is such a bad thing if you do it correctly and it's not all what you do. But perhaps too many people just throw a problem at the interviewee without and help or guidance.

Overall, conducting a good interview is hard and it is not a primary job of most engineers who do it, so it's not surprising there are quite a few bad interviewers out there.