4 ms·

He gives a bunch of reasons for what he's actually looking for (the way you problem solve etc) which is the first time I've heard an interviewer give a reason f

He gives a bunch of reasons for what he's actually looking for (the way you problem solve etc) which is the first time I've heard an interviewer give a reason for the whiteboard test. Ultimately the author is after the candidates thinking process and he misguidedly (in my opinion) thinks a whiteboard test will help him get that information. But instead, it will help him find people who are good at whiteboard coding under pressure. People who have practiced for that particular activity which they will not be getting paid to perform on a daily basis... just like asking brain teasers help you find people to hire that are really good at solving brain teasers (but may suck at their actual day to day job). Edit I'm going to use this opportunity to point out that I have been freelancing as a python / node.js / php / front-end (js, html, less etc) for about 4 years full time, 12 years total. I worked for a number of companies (small and large) for around 7 years. I get almost all of my current work through word of mouth and reputation. The interview process is pretty much me telling them what I can do, telling them what I have done, who I know and that's it I'm hired within the same phone call and I make a hell of a lot more money solo than I did when I worked fulltime (I'm getting ready to scale back to 20 hours per week to work on a project of my own). Yet, when I attempt a whiteboard test, a brainteaser or just about any other interview question for a full time position, unless I'm able to get past my crushing depression, social anxiety, interview anxiety etc. I will fail spectacularly. The entire standard interview process (and tech job for that matter) is total bullshit.

mikeash 11y ago
He gives reasons for a coding test, but he gives no reasons for preferring a whiteboard over a computer. The idea of using a computer barely gets mentioned and is never really compared, except for a brief bit where he says of course I won't ding you for forgetting a semicolon or whatever. I really don't see any justification for his use of a whiteboard. He just says it's normal, and that he does it too.
- robotkilla 11y ago
  Ah thanks - i actually skimmed pretty fast through the article because I'm busy and thought his reasons were for whiteboard testing. I still think on site code tests are garbage too... and working in offices when we can easily work from our homes. I like how most of build all this great technology to connect ourselves through the internet and then think its somehow more productive to work in an office setting.
lkrubner 11y ago
>social anxiety, interview anxiety I deal with that too, a circumstance I tried to communicate in my blog post "Embarrassing code I wrote under stress at a job interview". http://www.smashcompany.com/technology/embarrassing-code-i-wrote-under-stress-at-a-job-interview http://www.smashcompany.com/technology/embarrassing-code-i-w...
wil421 11y ago
I suffer from the same problem. Interviews are probably the most stressful experiences of my adult life (similar to going in front of a Judge). Compared to most I am a decent enough programmer but when faced with a whiteboard problem or quick interview coding problem I just clam up and under perform. My normal thought process is thrown out the door when I interview. Most people who know me would never guess I had social anxiety problems. Put me in a room with people I dont know and I am completely different. Add the stresses of an interview and I underperform every time. I hope one day I will have an employer ask me to a quick project related to web dev. Chances are I will shine brighter than figuring out a prisoner's dilemma or some random programming question the interviewer felt was important at the time.
Consultant32452 11y ago
I think it's because they want to get a glimpse at the process, not just the end result. And you want to be able to ask questions along the way to see why they're doing what they're doing. You could put them on a computer, but to get that information you'd have to be watching over their shoulder which has most if not all of the problems you listed for whiteboard coding.
- robotkilla 11y ago
  > think it's because they want to get a glimpse at the process, not just the end result. I absolutely agree that this is what they are after, but it is a very poor way to extract the information. The interviewer basically hands over his preferred tools and asks you to build something sane out of a pile of vague rules under extreme pressure. Its a close metaphor to real-life where a client (in-house or otherwise) will hand you a pile of vaguely defined rules, someone else gives you a particular toolset and then you go about your job, but it is broken. Remotely performed and turned in code tests (if crafted correctly) are a better assessment of a developers abilities along with code samples of his / her work. But I think all of that should be reserved for people without an established work history. I have excellent references. I have a solid work history. i passed the code test. I have code samples and open source code. Why in the holy fuck am i writing with a marker on a board or worse, answering a riddle?
  - ericlippert 11y ago
    Asking people to solve riddles is of course silly, and everyone I know at Microsoft stopped doing that fifteen years ago. I have had several candidates with established work history who were turned down on the basis of their coding work during technical questions in interviews. For example, I once interviewed a candidate who had written a popular developer tool for the Mac; the candidate was applying for a job on a developer tools team and had an excellent resume. And did not know what a binary tree was, did not know what recursion was. Though success in industry may be correlated with ability to solve the most basic problems one faces every day when building the semantic analyzer for a compiler, it is by no means a perfect correlation. Demonstrated ability to take the specification of a simple, recursively-defined property and translate it into two lines of correct code on a whiteboard is a pretty good correlate. And of course, as I pointed out in the article, I am much more interested in how the candidate reasons about the code, not whether they can write two or three lines of correct code on a board, or type them into a computer.
ericlippert 11y ago
Something I did not mention in this article -- which I note I wrote eleven years ago -- is that in the time since I have occasionally had candidates say "I get anxious when writing on a whiteboard, can we do technical questions on my computer?" In those cases I have gone to the extra trouble to set up a problem on a computer, and then had the candidate explain their solution to me. So I have tried it both ways, and I see very little difference in the outcome. For example, I give a problem on detecting whether a tree is out of balance. A great many candidate makes the same bug; they check to see if the subtrees are balanced without also checking to see if the subtrees are of similar height. They make this mistake whether they are writing the code on the whiteboard or on a computer, because the error has nothing to do with how you are writing the code, it has to do with the thought process that happens when trying to translate a clearly-written specification into one line of bug-free code. Candidates who are informed that they have a bug solve (or don't) the same way on a whiteboard or a computer: by reviewing their code, re-reading the specification and thinking about test cases.
deleted 11y ago
[deleted]

mikeash 11y ago

He gives reasons for a coding test, but he gives no reasons for preferring a whiteboard over a computer. The idea of using a computer barely gets mentioned and is never really compared, except for a brief bit where he says of course I won't ding you for forgetting a semicolon or whatever. I really don't see any justification for his use of a whiteboard. He just says it's normal, and that he does it too.

robotkilla 11y ago
Ah thanks - i actually skimmed pretty fast through the article because I'm busy and thought his reasons were for whiteboard testing. I still think on site code tests are garbage too... and working in offices when we can easily work from our homes. I like how most of build all this great technology to connect ourselves through the internet and then think its somehow more productive to work in an office setting.

lkrubner 11y ago

>social anxiety, interview anxiety I deal with that too, a circumstance I tried to communicate in my blog post "Embarrassing code I wrote under stress at a job interview". http://www.smashcompany.com/technology/embarrassing-code-i-wrote-under-stress-at-a-job-interview http://www.smashcompany.com/technology/embarrassing-code-i-w...

wil421 11y ago

I suffer from the same problem. Interviews are probably the most stressful experiences of my adult life (similar to going in front of a Judge). Compared to most I am a decent enough programmer but when faced with a whiteboard problem or quick interview coding problem I just clam up and under perform. My normal thought process is thrown out the door when I interview. Most people who know me would never guess I had social anxiety problems. Put me in a room with people I dont know and I am completely different. Add the stresses of an interview and I underperform every time. I hope one day I will have an employer ask me to a quick project related to web dev. Chances are I will shine brighter than figuring out a prisoner's dilemma or some random programming question the interviewer felt was important at the time.

Consultant32452 11y ago

I think it's because they want to get a glimpse at the process, not just the end result. And you want to be able to ask questions along the way to see why they're doing what they're doing. You could put them on a computer, but to get that information you'd have to be watching over their shoulder which has most if not all of the problems you listed for whiteboard coding.

robotkilla 11y ago
> think it's because they want to get a glimpse at the process, not just the end result. I absolutely agree that this is what they are after, but it is a very poor way to extract the information. The interviewer basically hands over his preferred tools and asks you to build something sane out of a pile of vague rules under extreme pressure. Its a close metaphor to real-life where a client (in-house or otherwise) will hand you a pile of vaguely defined rules, someone else gives you a particular toolset and then you go about your job, but it is broken. Remotely performed and turned in code tests (if crafted correctly) are a better assessment of a developers abilities along with code samples of his / her work. But I think all of that should be reserved for people without an established work history. I have excellent references. I have a solid work history. i passed the code test. I have code samples and open source code. Why in the holy fuck am i writing with a marker on a board or worse, answering a riddle?
- ericlippert 11y ago
  Asking people to solve riddles is of course silly, and everyone I know at Microsoft stopped doing that fifteen years ago. I have had several candidates with established work history who were turned down on the basis of their coding work during technical questions in interviews. For example, I once interviewed a candidate who had written a popular developer tool for the Mac; the candidate was applying for a job on a developer tools team and had an excellent resume. And did not know what a binary tree was, did not know what recursion was. Though success in industry may be correlated with ability to solve the most basic problems one faces every day when building the semantic analyzer for a compiler, it is by no means a perfect correlation. Demonstrated ability to take the specification of a simple, recursively-defined property and translate it into two lines of correct code on a whiteboard is a pretty good correlate. And of course, as I pointed out in the article, I am much more interested in how the candidate reasons about the code, not whether they can write two or three lines of correct code on a board, or type them into a computer.

ericlippert 11y ago

Something I did not mention in this article -- which I note I wrote eleven years ago -- is that in the time since I have occasionally had candidates say "I get anxious when writing on a whiteboard, can we do technical questions on my computer?" In those cases I have gone to the extra trouble to set up a problem on a computer, and then had the candidate explain their solution to me. So I have tried it both ways, and I see very little difference in the outcome. For example, I give a problem on detecting whether a tree is out of balance. A great many candidate makes the same bug; they check to see if the subtrees are balanced without also checking to see if the subtrees are of similar height. They make this mistake whether they are writing the code on the whiteboard or on a computer, because the error has nothing to do with how you are writing the code, it has to do with the thought process that happens when trying to translate a clearly-written specification into one line of bug-free code. Candidates who are informed that they have a bug solve (or don't) the same way on a whiteboard or a computer: by reviewing their code, re-reading the specification and thinking about test cases.

deleted 11y ago

[deleted]