|
|
|
|
|
by gjm11
5946 days ago
|
|
Reversing a linked list is not an Alan-Turing-level problem. I've used the reverse-a-list problem (and others of a broadly similar kind) in interviews. It shouldn't matter at all if a candidate hasn't read or written any list-manipulation code in years; that gives them the chance to sit and scribble some diagrams for me and work out how to do it. I don't mind much if they don't end up with a beautifully neat solution. I want to know things like: Did they check for edge cases? Did they blunder around trying things until they got code they couldn't prove was wrong, or did they work out something that ought to work and then implement it, or what? Did they ask themselves questions like "what facts ought always to be true at this point in the code?"? If they produce an inelegant or inefficient solution and I say "So what happens if you do X?" or "Could you do anything about Y?", do they panic and freeze or do they get thinking about the question? These are not a matter of having crammed their heads with algorithm esoterica. They're a matter of being reasonably comfortable with code, and being a problem-solver rather than a copy-and-paste artist. I'm quite sure there are plenty of software developer jobs that can in fact be done by someone who's fundamentally not very comfortable thinking about code, and/or who has little interest in problem-solving or little aptitude for it. It happens that those aren't the jobs I've interviewed people for, but they're real enough and collectively they probably account for a majority of the value added to society by software development. But when you're interviewing for a job that does call for independent thinking and fluent code reading and writing, that sort of question -- if used correctly -- is very valuable. Of course, an interviewer who thinks the point is to say "Write me some code that reverses a linked list" and then vote yes if the candidate does it on the spot and no otherwise, is going to reject some good candidates and accept some bad ones. But an interviewer who thinks that way is going to get lousy results regardless. |
|
I'm not suggesting that it is. The problem is, people are asking much harder questions -- questions that require "aha" brilliance -- and using it as a proxy for intelligence. That's stupid.
Hell...it's not even a deal-breaker if someone has to struggle a little to work out the algorithm for reversing a list, so long as they get it right. The problem is that if you spend more than 5 minutes (or whatever) doing it, 99% of nerds are going to flip the idiot bit on you, and it's time for "Do You Have Any Questions For Me?"
Once you've set up the game such that a candidate has to memorize the answer to "easy" questions to perform, there's no end to the regurgitation that could be required. Before long, people are committing obscure algorithms to memory, because "someone might ask", and they don't want to appear to be stupid. It's a waste of time and energy for everyone involved.