2 ms·

> The problem is expecting a candidate to have them memorized and be able to rattle off a particular algorithm from memory in a 15-30 minute interview window I

> The problem is expecting a candidate to have them memorized and be able to rattle off a particular algorithm from memory in a 15-30 minute interview window I get the feeling that we're talking past each other. It certainly seems that we have different kinds of interviews in mind. I'm referring to about an hour long session where a candidate is asked to solve a basic problem with a linked list. The candidate shouldn't be expected to have the algorithm memorized. Competent developers should be able to work out simple algorithms manipulating a linked list given an hour's time. > you look it up or grab it from a library instead of writing a busted implementation yourself. Usually. Sometimes there is no library. The point is the candidate should be able to write the library themselves if needed. The beauty of many linked list questions is that no reference is needed to work out the optimal answer (Flynn's algorithm being a notable exception). > There are lots of ways to evaluate critical thinking and problem solving skills that don't rely on a candidate having memorized the contents of a CS textbook. Again, I don't think that linked list traversal and reversal require some kind of arcane CS knowledge. Interviewers shouldn't be asking for e.g. on-the-spot implementations of Dijkstra's algorithm, the Hindley-Milner type inference system or the max-flow problem. > A better interview question is one that focuses on solving a real problem for a hypothetical customer, because that's what most engineers actually get paid to do. This is a good complement to a basic algorithmic / coding test. But it doesn't replace such a test.

kevingadd 13y ago
My PoV is that even if you have the hour or so that it should take for an average candidate to arrive at Floyd's algorithm or something, is that really the best use of the hour to screen the candidate? If your goal is simply to see whether they can solve problems using linked lists, that's noble, but making a candidate spend the majority of an interview trying to arrive at a solution for a new problem from scratch is a questionable decision, especially if each person in the interview pipeline is going to do the same thing with another problem. For reference, the first time I saw the cycle detection problem it was in an interview, and I had to derive Floyd's algorithm myself. It indeed took about an hour, so your estimate's probably not that far off. The problem is that it's the least optimal environment to solve a new problem for the first time without any assistance or context, which is what you're basically requiring. The candidate is basically left swimming in the deep end of the pool and you watch them flail around and at the end of it, maybe they've come up with a solution to the problem. Maybe they're really close and haven't hit that flash of inspiration yet. Maybe you accidentally misstated one of the problem's constraints and they're never going to figure it out as a result. Pretty lame. For basic stuff like reversing a LL I agree that no reference is needed to work out the optimal answer, but on the other hand I strongly believe those questions are worthless as a way of evaluating competence. The kind of LL stuff I've seen in interviews skews much more heavily towards Floyd's than simple stuff like list reversal, most likely because the simple stuff is easy. A good interviewer can certainly detect that a candidate just isn't familiar with LLs, and move to a different problem. I think that's an adequate method too: Attempt to screen out the people who aren't competent at logic and recursion and similar concepts, but without filtering out people who have just never been exposed to a particular class of problems. On the other hand, if you think having a candidate flail around for an hour (whether they solve the problem or not) is a good idea, there's no convincing you otherwise. I just think it's a pretty poor choice if your goal is to make the candidate and interviewer come out of the experience looking back on it positively with lots of useful information.

kevingadd 13y ago

My PoV is that even if you have the hour or so that it should take for an average candidate to arrive at Floyd's algorithm or something, is that really the best use of the hour to screen the candidate? If your goal is simply to see whether they can solve problems using linked lists, that's noble, but making a candidate spend the majority of an interview trying to arrive at a solution for a new problem from scratch is a questionable decision, especially if each person in the interview pipeline is going to do the same thing with another problem. For reference, the first time I saw the cycle detection problem it was in an interview, and I had to derive Floyd's algorithm myself. It indeed took about an hour, so your estimate's probably not that far off. The problem is that it's the least optimal environment to solve a new problem for the first time without any assistance or context, which is what you're basically requiring. The candidate is basically left swimming in the deep end of the pool and you watch them flail around and at the end of it, maybe they've come up with a solution to the problem. Maybe they're really close and haven't hit that flash of inspiration yet. Maybe you accidentally misstated one of the problem's constraints and they're never going to figure it out as a result. Pretty lame. For basic stuff like reversing a LL I agree that no reference is needed to work out the optimal answer, but on the other hand I strongly believe those questions are worthless as a way of evaluating competence. The kind of LL stuff I've seen in interviews skews much more heavily towards Floyd's than simple stuff like list reversal, most likely because the simple stuff is easy. A good interviewer can certainly detect that a candidate just isn't familiar with LLs, and move to a different problem. I think that's an adequate method too: Attempt to screen out the people who aren't competent at logic and recursion and similar concepts, but without filtering out people who have just never been exposed to a particular class of problems. On the other hand, if you think having a candidate flail around for an hour (whether they solve the problem or not) is a good idea, there's no convincing you otherwise. I just think it's a pretty poor choice if your goal is to make the candidate and interviewer come out of the experience looking back on it positively with lots of useful information.