5 ms·
This is the first article I've seen which mentions something that should be fairly obvious to interviewers — expecting people to code on whiteboards is a common
by calibraxis 15y ago
This is the first article I've seen which mentions something that should be fairly obvious to interviewers — expecting people to code on whiteboards is a common mistake. As an interviewer, I totally cringe when I imagine filtering out good people this way.
(I say that as someone who enjoys interview puzzles, and have always succeeded at them. But that pleasure's probably pathological. For many people, it's a nerve-wracking ritual which pointlessly damages self-esteem. As a gatekeeper, my job is to help them succeed at my silly little games. Assist them in reaching their limits.)
A lot of the mind is in one's hands, as many emacs users might tell you. That intelligence can disappear in the alien environment of the whiteboard, for those unused to it. Many bright people maybe can't even afford a decent whiteboard, and haven't worked in an environment which uses them.
There's a huge amount of good tips for good people to get past the gatekeepers — and negotiate good terms. If you can not just beat the interview, but kill it, you'll often have a more powerful bargaining position.
- InclinedPlane 15y agoI'm ok with coding on a whiteboard in an interview but I prefer it to be at a casual-ish level. I want to get high level data out of the process, not running code. I want to see how someone thinks through the process of transitioning from problem solving to coding. I want to see how they firm up requirements for the solution. I want to see people's code habits, I want to see their abilities to analyze and critique their own code. I tend to use pretty easy problems for such things (like factorial) so I can focus on those other bits. I find it works pretty well.