3 ms·
I used to (and, a few years ago, turned away smart people who failed them), but realized they were the wrong test for a small company. I switched initially to g
by crdb 11y ago
I used to (and, a few years ago, turned away smart people who failed them), but realized they were the wrong test for a small company. I switched initially to getting people to complete a task in their own time with the resources they liked and send us the code, and now entirely on network (i.e. who our CTO has already worked with and knows).
Big companies can't afford that luxury though. If big companies set tasks, the tasks would eventually leak because of the sheer number of people applying (both per position and over time). By necessity, you need the same task for all candidates to compare them effectively (ours was "build an inventory management system in Haskell for shoes", and we checked for things like documenting code, error management, and the sensible shortcuts someone might take), so you can't switch tasks around, and people will eventually learn what you like, work hard at faking the knowledge (e.g. copying and lightly modifying the code from other applicants), and you'll get loads of false positives.
So a big company needs to find relatively generalist questions that correlate roughly with later performance, and it seems that whiteboard CS questions are those by testing existing knowledge; through the sheer breadth of the exercise, it's a lot more time consuming to "revise" to fake that knowledge, and harder when on the spot to prove understanding. Are algorithm (and, less often mentioned, "fit") questions relevant to the job, maybe not, but you have to see the context and the hiring problem facing Microsoft or Google.
Of course, my opinion is that smaller companies asking whiteboard questions are just aping what they know from Google (as I was) and that there are better ways to hire when you have only 10 employees and 2 openings, but I might be wrong or at a local optimum.
I certainly regret not hiring a certain Masters in Statistics from Columbia who was very competent but who wasn't familiar with neural nets and admitted so in the interview/whiteboard... she'd have saved me at least 3 months on things I had to build later! Conversely, I later hired a guy who failed some of the whiteboard questions, but said it had caused him to learn more about the topic, which he did over a few months, at which point he came back to us, demonstrated competence and got an offer.
- liquidcool 11y agoI agree with the work sample test. In similar threads, some found cheaters, but the followup interview exposed them because they can't speak about the process and solution cogently. I imagine that if you look at enough, just reading them will allow you to spot cheaters, and having so many applicants will provide a good selection ethical developers. And a short contract-to-hire or probation period should deal with any who get through.
- crdb 11y agoThe other issue with judging sample code is the sheer amount of time it takes. The two of us took around 3 months (full time, effectively, doing nothing else) to select, interview and make offers to around 10 employees out of a pool of over 100 qualified applicants. You can sort of understand why companies try to develop less time consuming methods, and why experienced developers prefer to hire from their network...
- liquidcool 11y agoThanks for the data on the evaluation time. 9-10 hours per applicant is nontrivial, I agree. If you've worked with someone shoulder to shoulder, I can also see that being as effective. The problem I hear is that depending on the experience and number of the founding team, they can exhaust their network quickly. Peopleware has the idea of auditions, and I thought if you were clear about what you wanted, applicants would be comparable. I'm thinking, "Walk us through a project you did that demonstrates your knowledge of code quality." Or similar, with a clear list of what you're hoping to see.