Writing code on whiteboards is hard | Hacker News Reader

Writing code on whiteboards is hard

ericlippert.com

69 pointslx70 comments

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.

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.

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.

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.

>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-w...

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.

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.

> 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?

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.

> written a popular developer tool for the Mac

> did not know what a binary tree was, did not know what recursion was

Maybe he was just bad at memorizing his terms? I could program and use recursion long before I knew what it was called. A lot of what I know today was learned very quickly on the job. Perhaps that's not the type of person you were looking for, but I do know good hackers / developers that are bad with terms.

>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.

This is a balanced view to have and you seem like a much more reasonable interviewer than a few I've had in the past.

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.

>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.

This is part of it, but also, before about 10-15 years ago, the standard workplace computer was a large tower with a large and heavy tube monitor. Moving a setup like that into and out of a conference room for an interview is cumbersome. But leaving it in a conference room all the time means that a big chunk of the conference room table is continuously occupied by an unused computer.

"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?"

I've been arguing for years that if you don't want to code on a whiteboard in an interview, bring your own computer. To every justification as to why that's a bad idea on the interviewee side, my answer is to fix that before you walk in the door, and to every rationalization about why this is a bad idea for the interviewer, I say they're all pretty easy to fix. (You can tell how well someone thinks on a whiteboard, but if you see them use Intellisense you're suddenly clueless about how they operate? Then ask better or more questions.)

After years of being essentially shouted down, I metaphorically throw up my hands at all of you and say, fine. Insist on programming on the whiteboard in an interview.

But stop whining about it.

The power to fix this is in your hands and for some reason you all refuse to take it.

I'd try that if I cared. (Like I said, I personally enjoy the whiteboard, but I understand that others don't.)

However, would it really help? I imagine most interviewers would just say, no, put your computer away and grab this marker.

It's ultimately the interviewer's choice how to run the interview. We can try to nudge it and we can walk away, but it's ultimately up to them.

That's cool. But the interviewer thereby forfeits the right to complain about not being able to find good candidates.

And how they run the interview may influence whether people accept an offer should they make one. While the power is definitely heavily weighted in the interviewer's favor, it is important for them to remember they are trying to find someone they want to work with, and who will want to work with them.

I'm not proposing this as if it's the magical solution to all interviewing problems. Bad interviewers and bad interviewees will still exist. I'm trying to address a particular problem... if you, as an interviewee, do not like coding on whiteboards, and you're concerned that your skills will be reflected poorly, well... try to solve the problem then. If an interviewer won't let you solve this well-known and acknowledged problem, well, you certainly learned something about the interviewer, too.

But if you didn't even try to solve the problem, don't come whining to me (on the internet).

That said, I would also recommend just dodging all these other technical problems. Maybe spend 30 seconds trying to get the projector going, but if it goes beyond that, just say "Let's just look at the screen here on my laptop". Unless you've being interviewed by more than 3 people, it can be managed. Come equipped with a full battery. Etc. But this is all manageable stuff... I manage to get this right for trips to the airport, surely one can manage for a job interview.

I did that in my last interview. Brought a computer, told them I hate whiteboard tests. They were pretty skeptical from that point on and I didn't get the job. I also bombed the interview for various other reasons that didn't help... but busting out my own computer got a lot of dirty looks.

Perhaps there is a way to introduce the idea without inducing such skepticism. Our meeting rooms have a large TV in each, so one could plug in and mirror your display, but you could also likely bring your own projector. (OK, that's probably outside anyone's budget, especially mine.)

You might pitch it as something like, "I tend to sketch it roughly at first, and refactor heavily while I'm making an initial solution. Since refactoring is so much easier in a programmer's editor, I'd like to write in vim/emacs/pycharm, and project it on the tv/wall so we can discuss it."

... I'm not sure how that would work if they didn't already have conference rooms wired with monitors, though.

If your solution would fit in a screen without scrolling, it probably would work similarly well as a whiteboard.

What would you recommend to someone who don't own a laptop capable of acting as a development machine?

Or what if you're allowed to use your laptop, but aren't allowed network access to reference Google, SO, or even documentation?

"What would you recommend to someone who don't own a laptop capable of acting as a development machine?"

Twenty year ago, this was an important question. Today it's much less important, because machines are very cheap, relative to developer salaries. If you can't, well, it's the whiteboard for you then.

"Or what if you're allowed to use your laptop, but aren't allowed network access to reference Google, SO, or even documentation?"

This would fall under "if this concerns you, fix it then". Granted you can't get arbitrary SO searches, but almost everything has offline/local docs. I prefer them anyhow; the web's latency has not gotten better anywhere near as fast as it should be.

> What would you recommend to someone who don't own a laptop capable of acting as a development machine?

If you want to be a developer, buy one. While building very large projects on low-end devices is still problematic, almost any laptop today can be used for basic development tasks.

The problems I ask are not amenable to solution by searching Google, and frankly, I am not actually interested in the solution. The problems I give are so easy that someone who cannot solve them by writing the code from top to bottom in one go is unlikely to be successful. The problem is a starting point for a larger conversation about modern software development.

For example, I used to give a question where the solution was literally: take two pairs of numbers, find their differences, add the differences together. (The problem involves computing the difference between two times represented in an unusual format.) A candidate who is unable to take the differences of two pairs of numbers and add them together is going to be unsuccessful -- and I have had candidates show up in my office claiming to be "9 out of 10" C++ programmers who could not write correct code that added and subtracted four numbers. The vast majority of programmers will solve the problem correctly, and that is step one; I want to know how are you going to test it, can you prove that it is correct, if the times were in different time zones how would you change the signature of the method, should the method return an error for invalid inputs... I want to know if the candidate can actually reason about code.

If you want to reason about code, why not give them the solution and ask them how they would implement it - discussing with them about how they would implement the solution would be more enlightening. When you are being interviewed, the first hurdle is 'solving' the problem - coming up with a solution. Evaluating a developer on 'how they solve' a problem in highly stressful situation seems somewhat unreasonable - after all, what is more important in their day-to-day job is the ability to write maintainable, easy-to-understand code. In real life, problems are often solved via brainstorming with the team, going through iterations of getting/clarifying requirements

I agree; a problem I often give -- which I will discuss on my blog next week -- is "here's an existing solution to a problem, it is full of security holes and bad programming practices, describe to me some techniques you would use to fix this code without changing the public interface". That's problem people face in real-world development all the time: bunch of code, works when callers are benign, badly broken when callers are hostile, the client has shipped so we can't change the interface, fix the problem.

In the same interview I wrote about in this thread, I also had a computer question. Had an hour to complete it. I knew the answer from the outset, and just had to work out a few details (was working in Mono for the first time). And you know what? It took took me the whole hour. My solution worked great, but it wasn't my best code. I didn't leverage OOP enough and made it too procedural. On a whiteboard this would be fine; logic is really the only grading factor. But on the computer, you don't really have much more time but your answer has to be so much better. And the way it was done for me, I was alone on the computer, not able to give any rationale for my code. And when they reviewed it, they probably ripped it a new one without knowing why I did what I did. I could have easily explained why I made each choice and how to make it better. In the best case, a computer question would be much better. But done sloppily, it's pretty unfair. Reminds me of this Dilbert http://dilbert.com/strip/2013-02-24

You say that the result on a computer has to be so much better. Why? Why not apply the exact same standards as you would for a whiteboard question, but do it on a computer? It's not like typing out pseudocode is some crazy idea.

There's many more grading points to a computer solution. You're not graded for code style on the whiteboard; from what I've gathered, having an algorithm + code to implement is sufficient (not counting the verbal part). On the computer, however, you bet they're going to grade you on style, syntax, leverage of oop. etc. It's not something I realized when I did it which is why it probably (they never actually told me the result) failed. I just did an easy solution- I had good seperation of functions, leveraged access modifiers, etc but I didn't wow them.

Right, I can't speak for my interviewers but I was given several whiteboard questions and a computer question. They probably wanted to see what my code was actually like on the computer, while they tested my problem solving skills on the whiteboard. I guess if you chose just the computer as an exam you'd treat it more like a whiteboard.

You're talking about what people do, and I'm talking about what people ought to do. I accept that people might grade more harshly, but I'm saying there's no reason to do that, and if you want to apply whiteboard-style scoring to a typed solution, that seems like it would be a good idea and there's no reason you couldn't.

"I don’t remember that stuff either. I don’t care if you forget semis or make other syntactical gaffes. I’m not looking for people who can spit out syntactically perfect code at the drop of a hat; that’s not the point of the coding exercise at all. I’m trying to find out how you solve problems."

I don't really know how I'd do flowcharts and data flow diagrams and data structures and walk thru algos with a keyboard, although on paper or whiteboard its pretty easy. List of questions that need to be answered. Lists of good test to be run in the integrated testing system. Lists of "important points" to be put in to the docs or comments.

I mean it can technically be done with ASCII art and comments or maybe a cad program or good ole visio, but I'd rather just scribble some stuff down.

The part that trips me out is I haven't done ultra low level stuff since school. In industry nobody writes their own NIH stack or NIH rational number library, that would be completely insane and get you fired so you never think about it anymore. Some of the little brain teasers do look kind of like fun, by "shuffle an array" you mean implementing a physical vegas style card shuffle with cutting the deck and everything, that sounds awesome fun, I'm sure you could do it "the boring, right, way" but implementing a little vegas dealer robot that cuts and shuffles exactly X times sounds like fun. Maybe some times the perfect alternating shuffle isn't. And the cut needs sensible limits to be kinda in the middle third-ish not the extremes. Imagine the unit tests to verify enough random-ness.

Here's one thats simple and fun and more interesting than the provided array example for stats. You're allowed private variables BTW. Implement an object that can be streamed any arbitrary quantity of incoming numbers while streaming out the min max and avg at any time so far. Thats a classic where you keep the running subtotal and count in private variables in addition to the obvious min and max. You could use that as the back end to the question in the article, just strip elements off the array one at a time and feed them to the super duper streaming calculator. In "the old days" this algorithm was how cheap scientific calculators did arbitrary statistics without holding all data points and calculating the whole thing ab inito every step.

Why not do the parts suited best for paper and a whiteboard on that and the parts suited best for a computer on that. You know give the person both sets of tools and see how they make use of their tools, like they actually will when employed...

When people started testing programmer candidates on whiteboards people actually did program on paper as part of their normal workflow because computers were expensive: http://programmers.stackexchange.com/questions/51286/how-did...

However, it is strange that the practice is still so widespread long after people stopped programming on paper.

In our company we do not test candidates on whiteboards as part of our hiring process since I find it rather ridiculous and do not want to communicate to our candidates that we follow conventions even when they are obviously stupid.

> I don't understand why this approach is so popular for interviewing.

Some skills are probably transferable. Like swimming https://www.youtube.com/watch?v=MnKoQbFXemE.

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.

I dunno - couldn't the interviewer just ask if they want those things from you?

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.

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).

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.

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.

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.

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.

> I have had candidates -- some with advanced degrees -- show up who had no demonstrable ability to solve practical problems.

For real? I'm assuming you imply advanced degrees for reputable university? From my experience in CMU, it is hard to imagine someone slip through the system without an extreme command on general programming.

Maybe it can happen at a research focused Masters, but someone with a BS in Computer Science from the top 5 should not flunk an interview.

Oh yes really.

I have had candidates with PhDs in computer science who had a deep understanding of static analysis of programming languages, but who did not know how many bytes were in a pointer on a 64 bit operating system, who thought that there was an algorithm for compressing any 64 bit number into a 32 bit number, who could not describe the possible consequences of a buffer overrun in C, and who had no idea whatsoever what a virtual function table was.

Now, to be fair, as Dijkstra is said to have pointed out, astronomers are not experts on telescope building. People with deep knowledge in one small area of a field are often ignorant of other areas, even closely related areas. In those cases it's even more important to get a sense for how the candidate approaches problem solving, whether they can learn on the job, and so on, because you know that they are going to be deeply in problem solving mode very quickly when faced with their first real-world problems.

I hold up myself as a case in point; I helped build the JavaScript engine that was in Internet Explorer in the 1990s, but know practically nothing about HTML, the browser DOM, CSS, and so on. If I were interviewing someone like me for a web developer position, I would have to be convinced that the candidate could learn quickly.

Not everybody goes to a top 5...

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.

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.

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.

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.

I take your point, but I have been interviewed with the "pair programming" concept and found it much easier.

It also tells the interviewer how you really interact with a computer.

I find the whiteboard stressful. I'm tempted to use short variable and function names to save writing. I can't easily insert more lines of code. The code tends to get cramped and illegible.

In a text editor I'm more likely to make huge changes as the concept evolves.

A significant proportion of good programmers use vi or emacs. I realize there are outliers who just have to have Sublime Text set up the right way.

Most places do a coding test, whiteboard test, 5 phone interviews and 1 to 3 in person interviews with various members of various teams. Oh and you get shoved in what is essentially a giant playpen with other socially retarded "adults" in what is called an "open floor plan" and made to feel like shit for a few weeks or months based on your newness status, and made to feel like you're going to get fired always by the people above you, and paid like shit, and told when you get a holiday.

Awesome life.

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.

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.

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?

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."

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.

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.

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.

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?

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.

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 ;)

"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?

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.

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...

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.

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.

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.

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

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.

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.

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).

Reply on news.ycombinator.com