16 ms·

Writing code on whiteboards is hard

69 points by lx 11y ago

vdnkh 11y ago
Practice On my first real software interview, even though I got 90% of the answers correct, I didn't get an offer. I didn't ask specific enough questions, constrain the problem, or quantify my reasoning to satisfaction. And the funny thing is I knew I needed to do that. I had been preparing a while before the interview, and knew I had to do everything stated in this article, but it just went out the window. And I'm very good at doing this on the job. But at the whiteboard I didn't even realize I wasn't really explaining myself. I knew the answer (more or less) and just blurted it out, happy to be correct. But process is much more important. And it takes discipline to slow down and explain yourself. Now when I'm practicing, I talk to myself while writing on the whiteboard, and I have a little script I follow in the beginning of the problem that ensures I spell out my assumptions, the input/output, and the expected behavior of the algorithm. When I get myself in this mode of breaking down the problem, I find questions just roll off the top of my head.
- facepalm 11y ago
  I dunno - couldn't the interviewer just ask if they want those things from you?
  - vdnkh 11y ago
    You're expected to ask them. It's a minefield, really. But it's really not far off what I do on my job. When I get a spec I always ask questions like that. It's just hard to come up with scenarios when you've been given an isolated algorithm.
  - deleted 11y ago
    [deleted]
- r00fus 11y ago
  Wow, where were you interviewing? Really what you're describing sounds like a fault of the interviewer. If I were in his/her shoes, I'd have been excited that you drove towards an answer, and now changed the scenario (requirements shift!) and asked you to follow along. The idea of an interview as a one-way communication is not useful. It has to be two-way, and that requires a good interviewer (or interview process).
  - vdnkh 11y ago
    I'd rather not say, but they're a moderately trendy mid-sized business marketing company located in NYC. I thought I nailed that interview. The first question I got rather handily; I got the first part off the bat, the second part I needed a small hint. Nothing major. The second guy was what probably did me in; I interrupted his lunch break and he didn't seem thrilled about that. I got the first part of his question easily, but the second part he was expecting an answer with tries that I couldn't get. I was on the right track though. The third interviewer asked me question about a system their team designed. He told me that he deliberately left things out I needed to ask. I got a bunch of them, and ended up designing the exact same system his team did, down to the technologies used. I floundered with the second guy, and it cost me. Oh well. If you're wondering what their explanation was, it was that I wasn't "technical" enough. Whatever that means.
zallarak 11y ago
Agreed. I write a lot slower than I type, especially when writing a programming language. This messes me up. I also tend to write a general structure then insert code. Doing this on a whiteboard is hard because you can't move text around, you can just erase it. That said, with a calm mind and practice, its not that bad.
mikeash 11y ago
So why are you having candidates use a whiteboard? I don't understand why this approach is so popular for interviewing. If you want to give the candidate a practical programming test (and why not? seems wise to me) why not have him actually write some code on an actual computer, in a normal programming environment? Personally, I have no problem with whiteboard programming. I think it's fun and it doesn't stress me. But I don't understand why we do it instead of letting people use an actual freakin' keyboard. Imagine if you were interviewing a car mechanic and you said, OK, on this whiteboard here, draw out how you would change an oil filter. You'd have to be completely mad! If you want to test his ability to change an oil filter (and why not? that's something they should be able to do) then get a car and say, show me. I can't see any advantage to the whiteboard, so why do we do it? The only thing I can see is that it would have saved on capital costs back in the ancient days of yore when computer hardware was expensive and quantities were limited and getting every candidate in front of a computer wasn't practical. Thankfully that's not remotely true now.
- robotkilla 11y ago
  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.
serve_yay 11y ago
Writing code on whiteboards is hard, writing code on an unfamiliar computer in an unfamiliar room while a stranger watches on is hard, writing code in the middle of a job interview is hard (and unrealistic since we never do that during the course of normal work). So maybe you should stop making candidates do it. Give them a coding test they can work on in their own time, or whatever works for your situation.
- jasonmp85 11y ago
  And how many employees doing these interviews can actually write code on a board? Not to sound too wimpy, but holding your arms up like this is physically taxing for the unpracticed. Unless you're pulling in a lecturer for an interview, it's just not natural for an actual programmer. And why would you want to disadvantage actual programmers when you're hiring one? It just makes no sense. Whiteboards are for argumentation during design discussions. They're great for high-level block diagrams and all that. They're NOT great for long runs of text, and especially bad for code. If you're in-person, pair program. If you're remote, find a good online code-friendy (syntax-highlighting, monospace) scratchpad and use it with a voice or video chat solution. And if you can't schedule time with them, ask them to submit a repository with a solution to a harder problem. If they need to explain why they did something, that's what commit messages and READMEs are for. If they don't understand that, that's a mark against them. It's already enough of a conceit to ask someone to e.g. reverse a linked list when they're practically never going to be doing that in their day job. To ask them to do so using a dry-erase marker writing with 4" lettering on a whiteboard while standing is crossing into the ludicrous.
  - lfowles 11y ago
    If there's one thing I'm thankful for, it's my fourth grade teacher telling me to write with my elbow, not my wrist, on the blackboard.
  - serve_yay 11y ago
    Well, part of my point is that the whiteboard isn't really the issue, it's just the most egregious aspect of the situation. You say if you're in person, pair program. But where, on what computer, doing what, in what editor, etc? All these things plus the inherent pressure of the situation make the experience unpleasant enough, and the results unreliable enough, that you just shouldn't do it in my opinion.
iamcurious 11y ago
A word of advice: writing code on whiteboards is hard. Practice! Yes. If you are able, try to get some experience teaching. If you do it well, it will give you plenty of experience writing code while discussing its relative merits. Hell, spend enough time with academics and you will get in the habit of writing code on paper first and only typing it later as an after thought. And wait till you get one know-it-all student! They act like sufficiently smart compilers, correcting both syntax and semantics. They will make sure you follow what you teach! All this sounds hard, but the curve doesn't have to be more steep than you want it to. The world is full of programmers who could use a few minutes of your time to understand that pesky algorithm that you know backward and forward.
- qmalxp 11y ago
  I totally agree. IMO it doesn't even have to be a CS course; my experience TAing calculus helped immensely with whiteboard interviews. I think it's the process of pacing yourself through the problem. If I see some fancy integral, I might be able to solve it in one or two lines. But if I want the students to understand, I'm not allowed to skip steps so it'll take more like 15 lines, and I'll have to verbally explain each line as I write it. It's getting used to switching back and forth between dictation and logical process.
nijiko 11y ago
Best thing I've found is to get someone to tackle a problem you've recently faced or are going to face and see how they handle it. Not on a whiteboard, but with actual code and examples. Some companies will pay for this, and others just take it as a part of the initiation process. It really lets you see what people focus on, how they handle it (time, code, style, design, etc), and how dedicated they are to the actual problems you face.
genericuser 11y ago
When white board coding is required, I really feel it is better suited to allow a fair bit of psuedo code to be used in it. This article basically says they will take into account the lack of things like InteliSense, but their example is of what would be a pretty minor syntactical error. I mean I guess I fail to understand why if you show that you know the algorithms you are trying to implement, and the data structures needed to do so, what does it matter if you rely heavily on auto complete to give you the correct method calls off of those objects when programming? I realize a programmer using auto-complete which knows the method signatures well enough to not use auto-complete, will have a slight speed advantage while developing over someone who actually needs auto-complete. But there have to be better ways to test for development speed if that is truly your concern. Similarly I realize the interviewer would like to see how you respond when you can't remember or don't know something, do you get frazzled and frustrated or do you ask questions. However there are definitely far situations you can create to to watch for these type of reactions than simply expecting someone to know the syntax of a language well enough to write it on a white board. Honestly what am I missing?
jarnix 11y ago
And it's even harder to draw on a keyboard :) It's stressful to write code during an interview but it's necessary since it really helps understanding how the developer thinks when he's trying to solve a problem. I usually ask candidates to write code on paper, or even speak the code they want to write. If they know the algorithm but not the function names I don't care. This test is done after the first part of the interview where the candidate is given multiple questions so, usually, I already know if the candidate is good or not ;)
- genericuser 11y ago
  "it really helps understanding how the developer thinks when he's trying to solve a problem." How does it do this over watching them code on computer? Could you please provide examples of how this helps more than say them bringing in their own laptop (being provided with one for use if they don't have one) and you hooking it up to another display and watching what they write as they write it in the same room with them?
  - ericlippert 11y ago
    I have tried that as well in the eleven years since I wrote this article. It is much more work for me to set up a development environment, get the monitoring software working, blah blah blah, and there are many points of failure, but if the candidate feels more comfortable doing it that way I'm willing to do so. The problems that I ask are so easy that it really does not make a difference whether the candidate is writing on a whiteboard or typing on a computer; most of the problems I ask can be solved in fewer than six lines of code. I am using the code as a starting point for the conversation, not the end point.
MarcScott 11y ago
Writing code on a whiteboard is something I'm perversely good at. It's because I'm a teacher and not a developer, and I often end up shoving quick Python or Pseudocode algorithms up on my classroom whiteboard. I also encourage my students to code on whiteboards. I have a class set of mini-whiteboards that they can use at their desks to jot down bits of code, flowcharts or just their thoughts. I've noticed when touring tertiary academic institutions (Edinburgh School of Informatics for instance), that every room and office has whiteboards filled with scrawled code. So maybe this is just a practice from academia that has trickled down into industry.
arihant 11y ago
Why is this approach used? I have never, in my life, have coded on a whiteboard while actually building a product. I draw, I brainstorm, I even write plain English steps, but never code. It's extremely weird that companies are trying to act like S.H.I.E.L.D., and every interviewer thinking he is Fury. And they are almost always wrong. You're recruiting to someone to do a job, not to transform them into something. If they will likely never do something in the actual job, it is mindless testing them on something. Founders should be aiming to hire people better than themselves. Fury is awesome for hiring Avengers, not field agents. And no Tony Stark is coding on whiteboard happily. > It’s hard in part because you don’t have IntelliSense or syntax colouring or any of the other tools at your disposal that you normally do when writing code. I know that, and I’ll take that into account. This is weird. In what conceivable situation would one not have access to those tools on job site? Hell, I've seen a lot of programmers quickly check API available to them in a new language before forming a mental map of it. While the author may think he knows what he is doing. My personal guess is that he is alienating a lot of amazing people. If you test Lance Armstrong on his ability to ride a unicycle, you might miss out on him. That is essentially what you're doing with whiteboard coding.
- cmdrfred 11y ago
  I pretty much always check the documentation when I'm doing something. (Not basic file IO and things I've done a million times, but anything I've done less than 5 times. If I do it more than that I likely have a snippet I wrote on git hub I'll start with) I just like to look at some example code as I picture what I'm going to do.
- ericlippert 11y ago
  I take it into account by asking a problem that is so simple and straightforward that you do not need google, intellisense, or any other tool to solve the problem. As I mentioned in another comment above, I have asked problems as simple as "add and subtract four numbers". A candidate who needs to use Google to determine how to add and subtract doubles in C++ will not be successful. Now, perhaps I am alienating candidates, but first, I am very willing to accommodate any candidate who wishes to demonstrate their coding skills to me in some other way, and second, my primary goal is to prevent bad hires. If good hires go to the competition, that's too bad, but it is way more important to prevent a bad hire. What I am not willing to do is fail to test candidates on their coding ability; I have had candidates -- some with advanced degrees -- show up who had no demonstrable ability to solve practical problems.
exratione 11y ago
It remains crazy that whiteboarding in interviews is even a thing. We don't test to see how well candidates perform interpretive dance, and that bears about as much semblance to real work in this profession as does a whiteboard exercise. https://www.exratione.com/2012/09/whiteboard-exercises-are-a-terrible-way-to-investigate-coding-ability/ https://www.exratione.com/2012/09/whiteboard-exercises-are-a...
piyush_soni 11y ago
Whiteboard tests are already stupid, but some companies take it to another level. The last time I went to get interviewed by Amazon, they told me to write a complete, syntactically correct, "ready to go into production" code (I was literally told this). I didn't get that job. They did even worse when my friend was interviewed by them. He was told to write production quality code on a whiteboard, and when he did that, they asked for an explanation, and clicked a photo of it through their smartphone to evaluate it later, probably on a real compiler. Really, when you can't even understand production quality code on a whiteboard by yourself, how do you expect people to write it in a tense setting?
- aniket_ray 11y ago
  The photo was probably clicked to attach it to some sort of internal candidate feedback form. Photos ensure that the interviewer does not make a typographical mistake while entering it in. Also production quality code is usually interview speak for "Your code should be more robust i.e. check inputs and return values from library functions. Fix it."
- ericlippert 11y ago
  I usually take a photo of the candidate's work, but not to evaluate whether it is correct or not; I already know that. I take the photo primarily because the board is about to be erased for the next candidate, and I want to make sure that my notes are accurate when I describe the candidate's strengths and weaknesses. Having a photo also allows me to compare the candidate's work against that of previous candidates, so that I can ensure that my interview process is well-calibrated. It is also a preventative measure, so that when a no-hire candidate sues the company claiming discrimination in hiring practices against whatever protected class they are in, I have more evidence than my notes and fallible memory. Fortunately I have never actually needed to use that.
ljlolel 11y ago
Never write on the whiteboard: http://www.jperla.com/blog/post/don-t-write-on-the-whiteboard http://www.jperla.com/blog/post/don-t-write-on-the-whiteboar...
kstenerud 11y ago
A number of years ago, I got into the habit of bringing my laptop to any job interview. If I couldn't convince them over the course of the interview the merits of writing code on a computer and running it vs a whiteboard, I didn't accept the job offer.
spydum 11y ago
really the whiteboard interview is about telling the story of development.. not solving the problem. it would be interesting to see two scenarios up online in video format: scenario 1: dev writes out very elevant well crafted/optimized solution quickly and explains it and is done. scenario 2: dev makes elaborate song and dance routine explaining the problem space, then writing some code, then changing the code, then optimizing the code. the whole time, very compelling/emotionally engaged and "passionate". Have community vote on who is the better developer to hire. I have my suspicion of who would win.
wolfgke 11y ago
I really don't understand the hate that whiteboard coding has on HN. In Germany, this is used a lot in the programming tutorials on universities. It's not that there isn't a projector in about any larger seminar room. But most exercise instructor will strongly prefer whiteboard coding for explaining how to design an algorithm that solves the given exercise. The strong advantage is that you can easily draw pictures at some other corner of the whiteboard that illustrate the idea of the algorithm lines that you just wrote. This is also the preferred way for students to explain their implementation of the exercises. They could easily just show the source code on their laptop that they implemented. But I (and many other students and exercise instructors) see that the explanations are a lot more easy to follow if they have to build their implementation step by step on the whiteboard explaining their ideas thereby. On the other hand, if you have no idea how to solve the algorithm you can still write a skeleton of the algorithm and draw pictures by the sides to show where problems might occur. Most exercise instructors would say that only really good students are able to directly write an algorithm down into the computer. On the other hand, any student should be able to draw, say, a flowchart, of the algorithm. If you have done that (and are confident that it looks correct), then you can write a code snippet next to each box of the flowchart that implements (this is only one example. There are exercise instructors that prefer other ways than flowcharts. For example when you instead use recursion, there are other, better, methods). This way you wrote down an algorithm using the flowchart as an intermediate abstraction to simplify the problem. It might be that in the US a different way is used to teach programming (I really don't know which). Also in the internship whiteboards were regularly used when discussing about the best way to implement an algorithm (in about the same way they were used in the programming tutorials with the only difference that once everybody understood the idea, all got back to their computer to implement the algorithm). I never had to whiteboard code anything in job interviews, though. So I really claim that I wouldn't be really worse in whiteboard coding than if I were coding on a computer. I also have reasoned why whiteboard coding is a lot more comfortable in particular in the case when you don't have an idea how the complete algorithm even has to look like (than things that you can be done on a whiteboard, as drawing pictures, drawing flowcharts or writing down recursion equations can badly be done directly in a source code editor). Thus the only explanation that I have for the (nearly) universal hate of whiteboard coding on HN is that many people (me too) have difficulties writing code under stress situations (say, job interview). But this also applies if you write the code on a computer. Thus I believe the hate on whiteboard coding is rather a scapegoat for a lack of programming skills. If it were replaced by another method of a systematic assessment of programming skills, they wouldn't fare better (they just wouldn't have the scapegoat of whiteboard coding anymore).
zxcvvcxz 11y ago
Here's a story. I interviewed for Amazon a while back, online whiteboard (laptop + phone interview). They asked me to code up some esoteric binary tree algorithm that I definitely didn't remember. In "real life" I would do the responsible thing and google/wikipedia this algorithm, re-teach myself how it works, etc. But nope, gotta do it on the spot. Alright sure - open up a new tab (while on the phone), google it, and proceed to rewrite someone's StackOverflow answer, explaining it along the way. Now that I believe takes skill, especially since you gotta fake out the interviewer and make your discovery process seem "realistic". Suffice to say, I decided not to follow up with them for the next interview. If this is what they look for in their workforce, go hire kids who waste their time memorizing "Cracking the Coding Interview". I'd rather write useful software with my time, thank you very much.
dba7dba 11y ago
IMHO, any interview (phone or onsite) for a tech job that rejects a candidate because of some deficiency is found in technical skills during the interview, whoever scheduled the interview is at fault. That manager/HR-person just cost the company easily a few hundred dollars. Such determination of one's technical chop should've been made well early in the screening process, from past work or online tests or coding example (like take home project type). Interview process is expensive. It takes 1-5 hours of manhour from your company. It takes similar or more from the candidate. Think about how much you pay each engineer. just my 2 cents.
superuser2 11y ago
I'd disagree with wanting candidates to be confident in their solutions. You should be confident in a solution when the tests pass - and maybe, not even then.

69 points by lx 11y ago

vdnkh 11y ago

Practice On my first real software interview, even though I got 90% of the answers correct, I didn't get an offer. I didn't ask specific enough questions, constrain the problem, or quantify my reasoning to satisfaction. And the funny thing is I knew I needed to do that. I had been preparing a while before the interview, and knew I had to do everything stated in this article, but it just went out the window. And I'm very good at doing this on the job. But at the whiteboard I didn't even realize I wasn't really explaining myself. I knew the answer (more or less) and just blurted it out, happy to be correct. But process is much more important. And it takes discipline to slow down and explain yourself. Now when I'm practicing, I talk to myself while writing on the whiteboard, and I have a little script I follow in the beginning of the problem that ensures I spell out my assumptions, the input/output, and the expected behavior of the algorithm. When I get myself in this mode of breaking down the problem, I find questions just roll off the top of my head.

facepalm 11y ago
I dunno - couldn't the interviewer just ask if they want those things from you?
- vdnkh 11y ago
  You're expected to ask them. It's a minefield, really. But it's really not far off what I do on my job. When I get a spec I always ask questions like that. It's just hard to come up with scenarios when you've been given an isolated algorithm.
- deleted 11y ago
  [deleted]
r00fus 11y ago
Wow, where were you interviewing? Really what you're describing sounds like a fault of the interviewer. If I were in his/her shoes, I'd have been excited that you drove towards an answer, and now changed the scenario (requirements shift!) and asked you to follow along. The idea of an interview as a one-way communication is not useful. It has to be two-way, and that requires a good interviewer (or interview process).
- vdnkh 11y ago
  I'd rather not say, but they're a moderately trendy mid-sized business marketing company located in NYC. I thought I nailed that interview. The first question I got rather handily; I got the first part off the bat, the second part I needed a small hint. Nothing major. The second guy was what probably did me in; I interrupted his lunch break and he didn't seem thrilled about that. I got the first part of his question easily, but the second part he was expecting an answer with tries that I couldn't get. I was on the right track though. The third interviewer asked me question about a system their team designed. He told me that he deliberately left things out I needed to ask. I got a bunch of them, and ended up designing the exact same system his team did, down to the technologies used. I floundered with the second guy, and it cost me. Oh well. If you're wondering what their explanation was, it was that I wasn't "technical" enough. Whatever that means.

zallarak 11y ago

Agreed. I write a lot slower than I type, especially when writing a programming language. This messes me up. I also tend to write a general structure then insert code. Doing this on a whiteboard is hard because you can't move text around, you can just erase it. That said, with a calm mind and practice, its not that bad.

mikeash 11y ago

So why are you having candidates use a whiteboard? I don't understand why this approach is so popular for interviewing. If you want to give the candidate a practical programming test (and why not? seems wise to me) why not have him actually write some code on an actual computer, in a normal programming environment? Personally, I have no problem with whiteboard programming. I think it's fun and it doesn't stress me. But I don't understand why we do it instead of letting people use an actual freakin' keyboard. Imagine if you were interviewing a car mechanic and you said, OK, on this whiteboard here, draw out how you would change an oil filter. You'd have to be completely mad! If you want to test his ability to change an oil filter (and why not? that's something they should be able to do) then get a car and say, show me. I can't see any advantage to the whiteboard, so why do we do it? The only thing I can see is that it would have saved on capital costs back in the ancient days of yore when computer hardware was expensive and quantities were limited and getting every candidate in front of a computer wasn't practical. Thankfully that's not remotely true now.

robotkilla 11y ago
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.

serve_yay 11y ago

Writing code on whiteboards is hard, writing code on an unfamiliar computer in an unfamiliar room while a stranger watches on is hard, writing code in the middle of a job interview is hard (and unrealistic since we never do that during the course of normal work). So maybe you should stop making candidates do it. Give them a coding test they can work on in their own time, or whatever works for your situation.

jasonmp85 11y ago
And how many employees doing these interviews can actually write code on a board? Not to sound too wimpy, but holding your arms up like this is physically taxing for the unpracticed. Unless you're pulling in a lecturer for an interview, it's just not natural for an actual programmer. And why would you want to disadvantage actual programmers when you're hiring one? It just makes no sense. Whiteboards are for argumentation during design discussions. They're great for high-level block diagrams and all that. They're NOT great for long runs of text, and especially bad for code. If you're in-person, pair program. If you're remote, find a good online code-friendy (syntax-highlighting, monospace) scratchpad and use it with a voice or video chat solution. And if you can't schedule time with them, ask them to submit a repository with a solution to a harder problem. If they need to explain why they did something, that's what commit messages and READMEs are for. If they don't understand that, that's a mark against them. It's already enough of a conceit to ask someone to e.g. reverse a linked list when they're practically never going to be doing that in their day job. To ask them to do so using a dry-erase marker writing with 4" lettering on a whiteboard while standing is crossing into the ludicrous.
- lfowles 11y ago
  If there's one thing I'm thankful for, it's my fourth grade teacher telling me to write with my elbow, not my wrist, on the blackboard.
- serve_yay 11y ago
  Well, part of my point is that the whiteboard isn't really the issue, it's just the most egregious aspect of the situation. You say if you're in person, pair program. But where, on what computer, doing what, in what editor, etc? All these things plus the inherent pressure of the situation make the experience unpleasant enough, and the results unreliable enough, that you just shouldn't do it in my opinion.

iamcurious 11y ago

A word of advice: writing code on whiteboards is hard. Practice! Yes. If you are able, try to get some experience teaching. If you do it well, it will give you plenty of experience writing code while discussing its relative merits. Hell, spend enough time with academics and you will get in the habit of writing code on paper first and only typing it later as an after thought. And wait till you get one know-it-all student! They act like sufficiently smart compilers, correcting both syntax and semantics. They will make sure you follow what you teach! All this sounds hard, but the curve doesn't have to be more steep than you want it to. The world is full of programmers who could use a few minutes of your time to understand that pesky algorithm that you know backward and forward.

qmalxp 11y ago
I totally agree. IMO it doesn't even have to be a CS course; my experience TAing calculus helped immensely with whiteboard interviews. I think it's the process of pacing yourself through the problem. If I see some fancy integral, I might be able to solve it in one or two lines. But if I want the students to understand, I'm not allowed to skip steps so it'll take more like 15 lines, and I'll have to verbally explain each line as I write it. It's getting used to switching back and forth between dictation and logical process.

nijiko 11y ago

Best thing I've found is to get someone to tackle a problem you've recently faced or are going to face and see how they handle it. Not on a whiteboard, but with actual code and examples. Some companies will pay for this, and others just take it as a part of the initiation process. It really lets you see what people focus on, how they handle it (time, code, style, design, etc), and how dedicated they are to the actual problems you face.

genericuser 11y ago

When white board coding is required, I really feel it is better suited to allow a fair bit of psuedo code to be used in it. This article basically says they will take into account the lack of things like InteliSense, but their example is of what would be a pretty minor syntactical error. I mean I guess I fail to understand why if you show that you know the algorithms you are trying to implement, and the data structures needed to do so, what does it matter if you rely heavily on auto complete to give you the correct method calls off of those objects when programming? I realize a programmer using auto-complete which knows the method signatures well enough to not use auto-complete, will have a slight speed advantage while developing over someone who actually needs auto-complete. But there have to be better ways to test for development speed if that is truly your concern. Similarly I realize the interviewer would like to see how you respond when you can't remember or don't know something, do you get frazzled and frustrated or do you ask questions. However there are definitely far situations you can create to to watch for these type of reactions than simply expecting someone to know the syntax of a language well enough to write it on a white board. Honestly what am I missing?

jarnix 11y ago

And it's even harder to draw on a keyboard :) It's stressful to write code during an interview but it's necessary since it really helps understanding how the developer thinks when he's trying to solve a problem. I usually ask candidates to write code on paper, or even speak the code they want to write. If they know the algorithm but not the function names I don't care. This test is done after the first part of the interview where the candidate is given multiple questions so, usually, I already know if the candidate is good or not ;)

genericuser 11y ago
"it really helps understanding how the developer thinks when he's trying to solve a problem." How does it do this over watching them code on computer? Could you please provide examples of how this helps more than say them bringing in their own laptop (being provided with one for use if they don't have one) and you hooking it up to another display and watching what they write as they write it in the same room with them?
- ericlippert 11y ago
  I have tried that as well in the eleven years since I wrote this article. It is much more work for me to set up a development environment, get the monitoring software working, blah blah blah, and there are many points of failure, but if the candidate feels more comfortable doing it that way I'm willing to do so. The problems that I ask are so easy that it really does not make a difference whether the candidate is writing on a whiteboard or typing on a computer; most of the problems I ask can be solved in fewer than six lines of code. I am using the code as a starting point for the conversation, not the end point.

MarcScott 11y ago

Writing code on a whiteboard is something I'm perversely good at. It's because I'm a teacher and not a developer, and I often end up shoving quick Python or Pseudocode algorithms up on my classroom whiteboard. I also encourage my students to code on whiteboards. I have a class set of mini-whiteboards that they can use at their desks to jot down bits of code, flowcharts or just their thoughts. I've noticed when touring tertiary academic institutions (Edinburgh School of Informatics for instance), that every room and office has whiteboards filled with scrawled code. So maybe this is just a practice from academia that has trickled down into industry.

arihant 11y ago

Why is this approach used? I have never, in my life, have coded on a whiteboard while actually building a product. I draw, I brainstorm, I even write plain English steps, but never code. It's extremely weird that companies are trying to act like S.H.I.E.L.D., and every interviewer thinking he is Fury. And they are almost always wrong. You're recruiting to someone to do a job, not to transform them into something. If they will likely never do something in the actual job, it is mindless testing them on something. Founders should be aiming to hire people better than themselves. Fury is awesome for hiring Avengers, not field agents. And no Tony Stark is coding on whiteboard happily. > It’s hard in part because you don’t have IntelliSense or syntax colouring or any of the other tools at your disposal that you normally do when writing code. I know that, and I’ll take that into account. This is weird. In what conceivable situation would one not have access to those tools on job site? Hell, I've seen a lot of programmers quickly check API available to them in a new language before forming a mental map of it. While the author may think he knows what he is doing. My personal guess is that he is alienating a lot of amazing people. If you test Lance Armstrong on his ability to ride a unicycle, you might miss out on him. That is essentially what you're doing with whiteboard coding.

cmdrfred 11y ago
I pretty much always check the documentation when I'm doing something. (Not basic file IO and things I've done a million times, but anything I've done less than 5 times. If I do it more than that I likely have a snippet I wrote on git hub I'll start with) I just like to look at some example code as I picture what I'm going to do.
ericlippert 11y ago
I take it into account by asking a problem that is so simple and straightforward that you do not need google, intellisense, or any other tool to solve the problem. As I mentioned in another comment above, I have asked problems as simple as "add and subtract four numbers". A candidate who needs to use Google to determine how to add and subtract doubles in C++ will not be successful. Now, perhaps I am alienating candidates, but first, I am very willing to accommodate any candidate who wishes to demonstrate their coding skills to me in some other way, and second, my primary goal is to prevent bad hires. If good hires go to the competition, that's too bad, but it is way more important to prevent a bad hire. What I am not willing to do is fail to test candidates on their coding ability; I have had candidates -- some with advanced degrees -- show up who had no demonstrable ability to solve practical problems.

exratione 11y ago

It remains crazy that whiteboarding in interviews is even a thing. We don't test to see how well candidates perform interpretive dance, and that bears about as much semblance to real work in this profession as does a whiteboard exercise. https://www.exratione.com/2012/09/whiteboard-exercises-are-a-terrible-way-to-investigate-coding-ability/ https://www.exratione.com/2012/09/whiteboard-exercises-are-a...

piyush_soni 11y ago

Whiteboard tests are already stupid, but some companies take it to another level. The last time I went to get interviewed by Amazon, they told me to write a complete, syntactically correct, "ready to go into production" code (I was literally told this). I didn't get that job. They did even worse when my friend was interviewed by them. He was told to write production quality code on a whiteboard, and when he did that, they asked for an explanation, and clicked a photo of it through their smartphone to evaluate it later, probably on a real compiler. Really, when you can't even understand production quality code on a whiteboard by yourself, how do you expect people to write it in a tense setting?

aniket_ray 11y ago
The photo was probably clicked to attach it to some sort of internal candidate feedback form. Photos ensure that the interviewer does not make a typographical mistake while entering it in. Also production quality code is usually interview speak for "Your code should be more robust i.e. check inputs and return values from library functions. Fix it."
ericlippert 11y ago
I usually take a photo of the candidate's work, but not to evaluate whether it is correct or not; I already know that. I take the photo primarily because the board is about to be erased for the next candidate, and I want to make sure that my notes are accurate when I describe the candidate's strengths and weaknesses. Having a photo also allows me to compare the candidate's work against that of previous candidates, so that I can ensure that my interview process is well-calibrated. It is also a preventative measure, so that when a no-hire candidate sues the company claiming discrimination in hiring practices against whatever protected class they are in, I have more evidence than my notes and fallible memory. Fortunately I have never actually needed to use that.

ljlolel 11y ago

Never write on the whiteboard: http://www.jperla.com/blog/post/don-t-write-on-the-whiteboard http://www.jperla.com/blog/post/don-t-write-on-the-whiteboar...

kstenerud 11y ago

A number of years ago, I got into the habit of bringing my laptop to any job interview. If I couldn't convince them over the course of the interview the merits of writing code on a computer and running it vs a whiteboard, I didn't accept the job offer.

spydum 11y ago

really the whiteboard interview is about telling the story of development.. not solving the problem. it would be interesting to see two scenarios up online in video format: scenario 1: dev writes out very elevant well crafted/optimized solution quickly and explains it and is done. scenario 2: dev makes elaborate song and dance routine explaining the problem space, then writing some code, then changing the code, then optimizing the code. the whole time, very compelling/emotionally engaged and "passionate". Have community vote on who is the better developer to hire. I have my suspicion of who would win.

wolfgke 11y ago

I really don't understand the hate that whiteboard coding has on HN. In Germany, this is used a lot in the programming tutorials on universities. It's not that there isn't a projector in about any larger seminar room. But most exercise instructor will strongly prefer whiteboard coding for explaining how to design an algorithm that solves the given exercise. The strong advantage is that you can easily draw pictures at some other corner of the whiteboard that illustrate the idea of the algorithm lines that you just wrote. This is also the preferred way for students to explain their implementation of the exercises. They could easily just show the source code on their laptop that they implemented. But I (and many other students and exercise instructors) see that the explanations are a lot more easy to follow if they have to build their implementation step by step on the whiteboard explaining their ideas thereby. On the other hand, if you have no idea how to solve the algorithm you can still write a skeleton of the algorithm and draw pictures by the sides to show where problems might occur. Most exercise instructors would say that only really good students are able to directly write an algorithm down into the computer. On the other hand, any student should be able to draw, say, a flowchart, of the algorithm. If you have done that (and are confident that it looks correct), then you can write a code snippet next to each box of the flowchart that implements (this is only one example. There are exercise instructors that prefer other ways than flowcharts. For example when you instead use recursion, there are other, better, methods). This way you wrote down an algorithm using the flowchart as an intermediate abstraction to simplify the problem. It might be that in the US a different way is used to teach programming (I really don't know which). Also in the internship whiteboards were regularly used when discussing about the best way to implement an algorithm (in about the same way they were used in the programming tutorials with the only difference that once everybody understood the idea, all got back to their computer to implement the algorithm). I never had to whiteboard code anything in job interviews, though. So I really claim that I wouldn't be really worse in whiteboard coding than if I were coding on a computer. I also have reasoned why whiteboard coding is a lot more comfortable in particular in the case when you don't have an idea how the complete algorithm even has to look like (than things that you can be done on a whiteboard, as drawing pictures, drawing flowcharts or writing down recursion equations can badly be done directly in a source code editor). Thus the only explanation that I have for the (nearly) universal hate of whiteboard coding on HN is that many people (me too) have difficulties writing code under stress situations (say, job interview). But this also applies if you write the code on a computer. Thus I believe the hate on whiteboard coding is rather a scapegoat for a lack of programming skills. If it were replaced by another method of a systematic assessment of programming skills, they wouldn't fare better (they just wouldn't have the scapegoat of whiteboard coding anymore).

zxcvvcxz 11y ago

Here's a story. I interviewed for Amazon a while back, online whiteboard (laptop + phone interview). They asked me to code up some esoteric binary tree algorithm that I definitely didn't remember. In "real life" I would do the responsible thing and google/wikipedia this algorithm, re-teach myself how it works, etc. But nope, gotta do it on the spot. Alright sure - open up a new tab (while on the phone), google it, and proceed to rewrite someone's StackOverflow answer, explaining it along the way. Now that I believe takes skill, especially since you gotta fake out the interviewer and make your discovery process seem "realistic". Suffice to say, I decided not to follow up with them for the next interview. If this is what they look for in their workforce, go hire kids who waste their time memorizing "Cracking the Coding Interview". I'd rather write useful software with my time, thank you very much.

dba7dba 11y ago

IMHO, any interview (phone or onsite) for a tech job that rejects a candidate because of some deficiency is found in technical skills during the interview, whoever scheduled the interview is at fault. That manager/HR-person just cost the company easily a few hundred dollars. Such determination of one's technical chop should've been made well early in the screening process, from past work or online tests or coding example (like take home project type). Interview process is expensive. It takes 1-5 hours of manhour from your company. It takes similar or more from the candidate. Think about how much you pay each engineer. just my 2 cents.

superuser2 11y ago

I'd disagree with wanting candidates to be confident in their solutions. You should be confident in a solution when the tests pass - and maybe, not even then.