18 ms·
Exactly. When the evidence clashes with your theory, your theory is wrong. If people who have actually produced vital code aren't passing your interview test,
by waterlesscloud 17y ago
Exactly. When the evidence clashes with your theory, your theory is wrong.
If people who have actually produced vital code aren't passing your interview test, your interview test is poorly conceived.
- JoeAltmaier 17y agoHe mentions some of these candidates get hired and wash out. That seems like a pretty good correlation.
- hga 17y agoIndeed. The issue here is "How easily can you afford a dud hire?" Too many people out there with great resumes can't program their way out of a paper bag. The whiteboard test may be unfair to those who melt under interview pressure, but if the greatest danger is false positives for the "can they code?" test---if it's a startup where the price of one bad hire is very possibly if not likely the failure of the entire venture---it's the best test we've got. Note that the test doesn't have to be "tricky" or anything like that, e.g. a simple "reverse a doubly linked list" will weed out a surprising number of candidates. My three basic tests, back when C/C++ were the only choices to use, were that one (tests groking pointers), do a recursive factorial (any language will do for that), and "find the errors in this block of code". Mistakes in doing any of the above are perfectly fine, what you're looking for first and foremost is "do they have a clue?" Or use another higher level test from one of the best managers I ever had: if you have any doubt about the candidate, don't hire them. And if you doubt they can really code....