5 ms·
This is a false dichotomy. Having the interviewee give a brief talk and following with a dialogue about something they've worked on in the past is absolutely vi
by lbrandy 18y ago
This is a false dichotomy. Having the interviewee give a brief talk and following with a dialogue about something they've worked on in the past is absolutely vital. An interview consisting of that exclusively is probably better than an interview consisting solely of brain teasers. However, that's a silly comparison.
Way too many questions get labeled (on the internets) as "puzzles" and "brain teasers" when they are simply abstract algorithm questions. Crossing rivers with chickens and wolves, and/or figuring out the prisoners with the one room and the light-bulbs and all that crap are brain teasers and are totally useless. Impossible questions are not brain teasers. If I asked you how many tires are in the city of Chicago, and you said 1000, what should I think? What does that tell me?
Even still, way too many programmers decide to get intellectually offended (at least on the internet) when they hear about some problem that may involve, say, dropping light bulbs off a building to find the highest floor from which they can be safely dropped. This is nothing but an algorithm development question for a problem that doesn't have an off-the-shelf solution. This is testing your algorithmic thinking skills.
And as always I hear that phrasing such and such algorithm question "in real terms" is better than phrasing it abstractly. I've never seen a compelling argument that this is true except for this faux outrage that people have about puzzle questions. Phrasing it abstractly is quicker, simpler, and clearer. It removes all the hemming and hawing about implementation details. It removes answers like "doesn't intel have a library that does that?". It gets to the point, and quickly.
There is a second problem with that angst, and comments like: "I just can't muster any enthusiasm for completely random arbitrary puzzles in the face of so many actual, real world problems.". It is that we are computer scientists and abstract problem solving is something we should care about. Abstraction shouldn't be some barrier that makes it hard for you to think about a simple problem. Abstracting the real-world details away from you shouldn't get you emotional.
Besides, if I had an interview that was only a water cooler talk about something in the past, Jeff Atwood would smack that out of the park. And then I'd end up with a shop full of Jeff Atwoods. wink.
- jerf 18y agoI think this is another "In theory, theory and practice are the same. In practice, they are not." issue. In theory, theoretical questions are great. In practice, they are fidgety little things that must be asked precisely correctly to have the same "correct" answer that the interviewer has memorized and are frequently botched, almost invariably involve a "gotcha" answer in such a way that honestly I do not want to see a coder actually code, and have a laser-like focus on an aspect of the job that in most cases will involve less than 1% of your job, no exaggeration. I've done some algorithms work at my job, but in all my years it has always been replacing O(n^2) or O(n^3) solutions with O(n) or O(n log n) in very straightforward ways. Had I chosen an O(n log log n) answer, it would have been wrong for being radically more complicated. Basically, my problem with the puzzle questions is they show a misplaced priority. You could be asking gotcha puzzle questions (that, by the way, I've probably already read and memorized the answer...), or you could ask the interviewee to write a script in their favorite language to count the words or whatever, and learn both everything the puzzle question would have taught you and whether they can code. This may be a side effect of the fact that I refuse to spend eight hours interviewing someone. I want it done in less than half an hour unless there's a good reason to make it go longer (which does happen). Puzzle questions are a waste of time in that context. I guess if you're planning on wasting a candidate's entire day, you can afford wasting time on puzzles. (I have read the science that says we make decisions on the hiring issue far faster than in eight hours, which matches my experience, so why sit there and fiddle around all day when the decision has been made?)
- raganwald 18y agoI guess if you're planning on wasting a candidate's entire day, you can afford wasting time on puzzles. (I have read the science that says we make decisions on the hiring issue far faster than in eight hours, which matches my experience, so why sit there and fiddle around all day when the decision has been made?) I find it easy to believe that many people make a decision in far less than eight hours of interviewing, however I do not believe that all interview processes lasting eight hours are a waste of time for the candidate and for the interviewers. To pick an example, what about a process involving twelve different interviewers, each of whom takes between a half hour and an hour, with the process spread over a certain amount of elapsed time? Can we really assert that we cannot make a better decision with this process than with having one interviewer spend thirty minutes with the candidate?
- jerf 18y agoI don't interview alone. We used to do interviews alone in sequence but realized we were just wasting time. You also skipped out on something I explicitly mentioned, which is that there are times I go over when it is called for. (Recall that the median interview result is "obviously no".) Also bear in mind when I talk about "wasting time", I'm also concerned about the candidates time. Spending 8 hours interviewing someone that you decided "no" on in the first 30 seconds is doing nobody favors. That people defend this practice boggles my mind. (I don't know if you're defending that or not, but I've seen it defended elsewhere.) (Also note I did not say you should turn them out in 30 seconds, that's not respectful either. They should have a chance to convince you you are wrong. It's rare, but it happens. But the third hour vs. the fourth hour is unlikely to produce any changes.) Time is money, and that includes the candidate's time. The idea of flying people out for a two-day interview cycle actually sort of angers me unless they're planning on compensating me for it, and I mean with more than a few free meals and a hotel stay.
- raganwald 18y agoYou also skipped out on something I explicitly mentioned, which is that there are times I go over when it is called for. I didn't ignore that, I was thinking about it when I suggested people taking a variable amount of time to perform an interview. Spending 8 hours interviewing someone that you decided "no" on in the first 30 seconds is doing nobody favors. That people defend this practice boggles my mind. (I don't know if you're defending that or not, but I've seen it defended elsewhere.) I am absolutely not defending that practice. If, for example, you plan to have six people do consecutive interviews and you also give each person a veto, there is no reason to have person two through five do the interview if person one votes "NO HIRE." On the other hand, if your policy is to have a discussion after each interview where the interviewer raises concerns that subsequent interviewers may wish to address, then person one might terminate their interview but persons two through five might feel it's still worthwhile to continue. Or perhaps not. The idea of flying people out for a two-day interview cycle actually sort of angers me unless they're planning on compensating me for it, and I mean with more than a few free meals and a hotel stay I think you are mixing your strategy for getting hired with a discussion about the best strategy for hiring. I always try to remember that it is not my job to hire myself, therefore when putting together an interview process it may make sense to do things that would cause me personally to decline to pursue the opportunity. To give a very simple example, I personally do not like writing code in an interview. I strongly dislike trying to "Guess the coding style the interviewer is thinking of." I never know if what I write will be not clever enough or too clever, especially when given something ridiculously trivial to implement. I feel a lot of pressure. Nevertheless... I have had very good results asking candidates to write code in the interview process. Oh well!