Yes, but at some point, the knowledge becomes so basic that it should be considered part of basic CS literacy. By analogy, if you are a writer, you should know what similes are even if you aren’t using them every day (to say nothing of things like commas).
I personally consider binary search to be in this class of knowledge. It’s one of the simplest (if not the simplest) divide-and-conquer algorithms, and if a person doesn’t know whether it performs better than linear search and why, that tells me that the person lacks all kinds of other pieces of critical knowledge, as well.
I’m not saying that knowing this stuff is completely unimportant, but rather than using knowledge of algorithms as a rough signal of someone’s ability to do their (non-algorithms-related) job, it’s better to measure it more directly.
Firstly, how can we do that ? There’s no way we can grant each candidate an evaluation period that lasts two or three monhts—which is what it’d take to measure his performance directly. So, we need some heuristics.
Secondly, “is the candidate CS-literate at all” is just the kind of heuristic that we can use for this. And, IMO knowing about binary search (not necessarily by name, especially if the candidate is not a native English speaker) is a great test for this heuristic. It’s pretty much the CS equivalent of “can you form words into sentences”.
One measure is to get them to do a small project (a few hours worth as most) of a similar (but simpler) nature to what your company does. That may not be perfect but it’s a lot closer than whiteboard algorithms. IIRC research suggests that of all forms of job candidate evaluation, “work samples” such as this have the highest correlation with subsequent performance.
It’s true, but that is still a significant investment of time, both on our parts and the applicants’. Most companies implement a two-stage filter: the phone screen, where they weed out a large portion (if not the majority) of the applicants, and the in-person interview, where the applicant might be asked to solve a programming problem like the one you mention. The “what is binary search and how does it work” type of questions are designed for the phone screen phase. IMO that is entirely appropriate, for the reasons I stated above.
The use of in-person whiteboard type questions is not what I mean at all—I mean a small but realistic project for the person to solve at home on their own time with their own tools. Maybe there is a necessity for a faster screen but I’m not convinced that that particular question is close to optimal for most hiring unless programming those kind of algorithms is something you actually do on a regular basis.
Indeed—if a programmer didn’t remember what ‘binary search’ means, I’d still expect them to be able to derive it on the spot from a rough description and then tell me exactly how it fares as compared to linear search.
Yes, but at some point, the knowledge becomes so basic that it should be considered part of basic CS literacy. By analogy, if you are a writer, you should know what similes are even if you aren’t using them every day (to say nothing of things like commas).
I personally consider binary search to be in this class of knowledge. It’s one of the simplest (if not the simplest) divide-and-conquer algorithms, and if a person doesn’t know whether it performs better than linear search and why, that tells me that the person lacks all kinds of other pieces of critical knowledge, as well.
I’m not saying that knowing this stuff is completely unimportant, but rather than using knowledge of algorithms as a rough signal of someone’s ability to do their (non-algorithms-related) job, it’s better to measure it more directly.
Firstly, how can we do that ? There’s no way we can grant each candidate an evaluation period that lasts two or three monhts—which is what it’d take to measure his performance directly. So, we need some heuristics.
Secondly, “is the candidate CS-literate at all” is just the kind of heuristic that we can use for this. And, IMO knowing about binary search (not necessarily by name, especially if the candidate is not a native English speaker) is a great test for this heuristic. It’s pretty much the CS equivalent of “can you form words into sentences”.
One measure is to get them to do a small project (a few hours worth as most) of a similar (but simpler) nature to what your company does. That may not be perfect but it’s a lot closer than whiteboard algorithms. IIRC research suggests that of all forms of job candidate evaluation, “work samples” such as this have the highest correlation with subsequent performance.
It’s true, but that is still a significant investment of time, both on our parts and the applicants’. Most companies implement a two-stage filter: the phone screen, where they weed out a large portion (if not the majority) of the applicants, and the in-person interview, where the applicant might be asked to solve a programming problem like the one you mention. The “what is binary search and how does it work” type of questions are designed for the phone screen phase. IMO that is entirely appropriate, for the reasons I stated above.
The use of in-person whiteboard type questions is not what I mean at all—I mean a small but realistic project for the person to solve at home on their own time with their own tools. Maybe there is a necessity for a faster screen but I’m not convinced that that particular question is close to optimal for most hiring unless programming those kind of algorithms is something you actually do on a regular basis.
Indeed—if a programmer didn’t remember what ‘binary search’ means, I’d still expect them to be able to derive it on the spot from a rough description and then tell me exactly how it fares as compared to linear search.