The worst part of the whiteboard in my opinion is not that it's a poor tool for the job, which it is, but that it adds both unnecessary social pressure and the need to constantly explain what's going on (presumably because the interviewers are bored so for their amusement) while simultaneously trying to think, write, and edit out a solution. The fact that you can't run or even edit code very efficiently on a whiteboard (or paper) alone makes it a terrible tool to judge anything about a candidate, but combined, the two make the whole exercise pointless and quite frustrating for the interviewee.
There's no bad interview question, but there are certainly bad interview _processes_. We use a whiteboard session as the last step in the technical interview, and we're really not looking for someone to write functioning code, we're looking for the candidate's thought process as they lay out a design for a simple OO program.
For the type of programming I'm involved in hiring (iOS/Android) it's silly to expect someone not to lean on frameworks/IDEs. It's also unrealistic to expect that every single candidate has a laptop fully set up with their preferred environment. That's what take-home questions are for.
In what way is announcing that he was going to try and game someone else's interview process insightful?
Not only that but it's not even clear the person he/she is responding to actually is part of an interview process as opposed to just explaining the reasoning behind the interview question.
Personally I found it needlessly rude and even rather bitter but if you feel like it provided some value then I'm glad it was useful.
It is insightful because gaming the system is exactly what people do. When someone asks me, "What is your greatest weakness," I typically say something stupid like, "I guess my greatest weakness is that I don't spend enough time with my family because I tend to work all the time," instead of the reality, which is, "I fantasize about having meaningless sex with every woman I meet. Even the homely ones."
When someone asks, "Why do you want to work here?" I might say, "Because I find the way your company puts input fields on a web page to be fascinating, and I want to be a part of it." The reality, however, is I want a damn paycheck and I couldn't care less what the company does.
The point here is that nobody answers these questions honestly. Nobody. So what on Earth is the point of asking them? There isn't one. These questions just fill up space during the allotted hour of interview time, and are used by the interviewer to justify the opinion they formed within the first few seconds of the interview.
Fair enough. I thought it was obvious that people try to game the system, but I can see how if others didn't think the same way it would be insightful.
On the other hand, what's the point of asking anything during an interview if people can lie then? I imagine these questions are still being asked because it's not all that easy to lie and still sound authentic. I also agree with you though. I think this whole idea of trying to find people to work at a company because this is their dream company is just a silly fantasy for 99.9% of companies. Unless you're Google, chances are slim that working is nothing more than a job.
This whole craze over wanting to love your work and being "passionate" and "excited" is getting out of hand. I feel like I see the word "excited" thrown around everywhere now.
I try to be more pragmatic in my interview process. I don't expect candidates to be passionate because the company isn't their dream. I expect the owner to be passionate, but the rest of us are just here to pay the bills. Therefore, I don't bother looking for passion. What I do want is somebody who has coding experience and someone I'd enjoy working with. I focus all my questions around those two goals, with a greater emphasis on the second.
I did. In no way did the parent comments indicate that the situation described would be more susceptible than normal to gaming in the way the poster described.
Pretending to be very in-demand seems a common way to game most interview processes. But I would think that presenting yourself as being very in-demand, while not having any particular answer to "why us", could come off as having no particular reason to be loyal and work against you.
and lo, there was much rejoicing throughout the land.
Whiteboard coding is a terrible practice that should have died 15 years ago. 1 hour of pair programming on a real computer (even locked down with no network access) should tell you all you need to know about a person's skills.
See, this is where 'different strokes' thing comes in handy. I HATE HATE HATE pair programming. If you tell me I have to do 1 hour of pair programming on a job interview, I won't go. Not because I'll get nervous or anything, I just don't like a few things about it, a couple:
a) I hate having people in my personal space I don't know well. It may seem I'm being an asshole, but I'm very very very very sensitive to smells to the point that I can't concentrate. Your cologne or just body smell will probably be my number one focus throughout that hour.
b) while I don't have OCD/am a germaphobe, again I HATE HATE HATE using a keyboard that isn't new or mine. The stickiness of the keys, the dirt around them... makes me go crazy.
I always carry my laptop to interviews with me nowadays to at least avoid B.
So, for me, a whiteboard is great (for some reason, I don't care much about a dirty board/pens) and I do amazingly well on them. I also do very well in public speaking situations so maybe I'm just comfortable at that kind of interaction/distance.
I think the best is to truly ask the person what they prefer. If they want a laptop, great, if a whiteboard, cool as well, I've done both both as an interviewer and interviewee, and noticed that as well, some people prefer a whiteboard, others a laptop. Give them what they are more comfortable with.
Pair programming physically side by side is not great. Pair programming or integrating/coding together remote over Skype/Gotomeeting/etc screen sharing is great when needed.
It is like having another programmer in your head and you can't see each other type so there are less jibs/jabs. Plus both people can eat, drink, do things rather than just stand around one workstation like people did with TV in the 50s and one person can't see the screen.
I can't remember the last time I pair programmed in person over remote even in the same office/building. Occasionally you need to be in the same room or desk to draw something up but mostly it is more efficient remotely especially during an integration.
Pair programming remotely is like "hey you got a bug on line 441", pair programming side by side physically is like "dude you got a bug down there, btw just just use this hotkey" or doesn't even see it because you can't see the screen.
I agree. I work remotely and do this a lot with team members, but when people suggest pair programming, they are (usually) referring to 2 seats on 1 keyboard kind of thing, which I hate and would probably quit if I had to do it on a day to day basis.
If you haven't figured out what you need to know in 5 to 10 minutes of pair programming, you're doing it wrong. There's absolutely no reason to subject yourself or others to an interview that is over an hour long.
When I conduct interviews, I make every effort to keep them to 15 minutes. If we end up chatting for longer than that, that's fine, but the planned and structured part of my interviews are no more than 15 minutes long.
The way I look at it, if a company can't respect my time and can't optimize theirs, I don't want to work for them anyway.
We did "whiteboard" coding up until just a couple years ago but I've been pushing all our dev teams to switch to actual real "on computer" coding for interviews. At first there was some concern, but really, it works out a lot better.
The biggest still valid objection is "it won't be setup the way they are used to and so it will take too long for them to be productive even for a toy problem". Maybe. It seems like even they are used to a different color scheme or IDE plugins or whatever they should be able to figure out a default setup enough to write a toy algorithm. Maybe not.
> For the past few decades, most engineers require candidates to code on a whiteboard.
Citation needed for the first sentence. I have always heard of whiteboard coding interviews, but I have never heard that they are common and certainly not the majority.
I've been programming since I was four. Was doing 6502 machine code at eight or nine. I know over ten languages pretty fluently, and have done everything from high level web and desktop stuff to bare metal kernel hacking.
I can't code on a white board to save my life. It all just falls out of my head.
I've heard others say the same thing, so I suspect I'm not at all unique here.
Google still seems to love their whiteboard interviews, to the point where you have to write syntactically correct Java, under pressure, for a rather difficult problem in only 45 minutes. It's stressful as hell, and has almost certainly driven off lots of good programmers. My company does sit-down interviews with a computer (usually a Mac) and the interviewer's choice of IDE. We get much better results that way - coding under pressure is still hard, but at least the IDE can save you from making easy mistakes under pressure, and you get immediate feedback about how you're doing, rather than just going on the ambivalent nodding of an interviewer.
Also, one of the issues of providing an interview candidate with a computer is that some people are very particular with their environment.
For example, even if you let them use an IDE they are familiar with, maybe they really don't like using Macs. Or worse, they don't even use a qwerty keyboard.
In my company nobody uses an IDE, I use vim and the other developers use emacs or sublime. I think we all have our own little plugins/settings that we use as well.
Of course you could solve all of this by letting employees bring their own computer, although not everyone has a laptop either. To be completely honest, I really like the whiteboard but I definitely can see why others don't like it and get the impression I'm in the minority.
I spent a day interviewing last week one of those companies. 3 whiteboard interviews during the process. I'd say it's far from dead.
I was asked to write syntactically correct code in a specific language on a whiteboard with a time limit. That's very far from how I work on a daily basis. I could understand writing pseudo-code or explaining architecture but what possible data can you gather from how well I draw curly braces on a dry erase board?
Does Google really expect people to write syntactically correct Java? I've assumed Google is fairly similar to other tech companies I've interviewed at, where the primary thing is describing a correct algorithm and language is secondary.
Thus the whiteboard coding exercise has materialized for me perhaps twice in the past decade, and both times have been a reminder of just how terrible it is as an interview strategy.
It is Slow, Slow, Slow
I am actually greatly in favor of short programming exercises as a framing strategy for interviews. A sort of ersatz pair programming is the way I like to interview candidates: dive straight in with two seats at a machine and get to know the fellow over the course of either a bug hunt on the system he is being hired to work with, or if that's impossible for legal or other reasons then some small, fun coding exercise. Such as, say, "implement the world's worst way to represent and then reverse a linked list," or anything that starts with "you have an infinite tongue floating on a lake of a coffee and a piercing tool..."
Ditching the keyboard in favor of a whiteboard dramatically increases the time taken to evaluate any one shard of the programming experience, however. What can be accomplished neatly with a simple text editor in ten minutes can take a painful hour or more with a pen. Whiteboarding is simply not suited for the exploratory way in which most people code. All that wasted time would be put to far better use in talking, asking questions, and more deeply exploring the interviewee's approach to coding as a profession - touching on the many, many vital aspects of being a developer that cannot be tested in an hour with a text editor and a compiler.
Whiteboarding Primarily Tests for the Ability to Whiteboard
Most folk don't spend their lives working on how to most efficiently and effectively use a whiteboard. There are good reasons for this: we have computers now, with editing and presentation software that is ten thousand times more useful and functional than the combination of pen and whiteboard. Why would anyone choose to practice and optimize a skill that is never going to be used in the ordinary course of their professional life?
Nonetheless, there exist a small number of people who can whip up really great presentations on a whiteboard from scratch, even over the course of a discussion that swings around all over the map, and has no predetermined outcome. These talented folk will make great use of space, have little need to erase and redo, and will generally look good while doing it. But guess what? That skill, while very occasionally useful, has absolutely nothing to do with code or programming.
Most people, given a whiteboard and a free-ranging discussion or problem to solve, will produce an ugly-looking hash of notes and require frequent large-scale reordering of the content on the board to make sense of it all. If you weren't there, it might as well be Hebrew or hieroglyphics. If you were there, it still requires an additional investment of effort to follow what is happening - effort that might otherwise be going to more productive interview strategies.
Erasure and Exploration are Punished Aggressively
People are very individualistic when it comes to that aspect of development that involves the choice, design, and implementation of algorithms - the sort of thing that might take a few minutes to an hour and will typically be just a small part of a larger task. There are as many different approaches as there are types of personality. For my part, actually writing code is exactly equivalent to thinking about the problem: I plunge in and start writing, as that is the process by which I get a handle on what the eventual solution has to involve and how it will be organized. I'd guess that I probably write at least two to three times as many lines of code as eventually exist in any given small solution, and it is the rare module that isn't aggressively refactored or otherwise turned inside-out at some point within the first thirty minutes to an hour of its existence.
In a text editor, this is a very rapid process. It goes about as fast as I can type. On a whiteboard? Not so great. Forcing code away from an editor and into a whiteboard ...
I generally agree with the article in regards to social pressure/anxiety being very high for a whiteboard style interview.
However I disagree with its sentiment that coding resources are free and have no cost. I think this attitude leads to poor quality code. My reasoning is that if you don't have to spend any effort to write code than you will write the laziest code possible. This code might work but it will only work because it evolved from the wrong solution to a barely working solution. If compute time was more of a scare resource developers would spend more time writing correct code instead of iterating until something works.
I don't mean that all developers code poorly because of the decrease in the time of the iteration loop but I feel that it does lead to poor code in the general case.
The whiteboard is actually not the main problem, it's the other things that often come with whiteboard coding. The main problem is that these type of interviews expect you to master the skill of talking, thinking, and coding simultaneously. The reason given is to "see how you think" but there's no reason this must be in real-time, questions could be asked after allowing the candidate some quiet privacy to work on a solution. To illustrate the main issue, replace the whiteboard with a computer connected to a projector instead. The main issue is still there. A group of engineers silently sitting there, judging, watching every move, and expecting you to keep talking while thinking and coding. This is NOT how programmers work. Most programmers sit down, think about a problem silently, then try out a few quick code snippets to explore the problem, then create a design, and then begin coding.
It would be a huge improvement if companies just gave the candidate a problem, left the room, and came back an hour later. Then they can discuss the solution, ask questions about the code, etc. The key thing is, let them do some quiet alone thinking instead of having to worry about someone watching every move and expecting constant talking.
I think conducting any kind of test during an interview is a waste of time. If someone comes in with a resume that clearly demonstrates years of relevant experience, a Github account with examples of things they've worked on, and if they can talk intelligently about the problems I'm trying to solve, that's all I really need to know about their skills.
I couldn't care less how someone thinks. What I want to know is do they have experience writing code and more importantly, are they the sort of person I would enjoy working with. Both of these questions can be answered in more effective ways than a test or whiteboard question.
I don't see why the whiteboard is so unpopular here. Isn't it a good way to see how people are able to discuss solutions and share ideas with their colleagues?
The way I see it, one could start to find a solution on the whiteboard, possibly with some help from the interviewer. And next stage is writing the actual code, which can be done easily on the whiteboard if it's a short program.
There are myriad problems with whiteboard questions:
1. The questions are always esoteric and have absolutely nothing to do with the company's business (unless, of course, they are in the business of generating Fibonacci numbers or CSS flags).
2. The situation itself is completely unrealistic and in no way demonstrates "how a person thinks" in a programming situation; which is weird since that is, after all, the universal rationalization for asking whiteboard questions in the first place.
3. Most, if not all, interviewers have no idea what to do with the information they observe in a whiteboard situation, so regardless of the result, it just becomes a confirmation of whatever opinion they formed within the first 30 seconds of the interview.
In my experience, whiteboard questions demonstrate a lack of interviewing skills and are a waste of time for everyone involved. I refuse to interview people that way, and I'll walk out of an interview if someone asks me to solve something on a whiteboard. If you want to see my code, go to my Github account. If you want to see how I solve real-world problems, I use past experience, Vim, a debugger, a terminal, my gists, Dash, and Google. There. Did we really have to waste an hour of everyone's lives to get to that answer? Absolutely not!
The whiteboard interview attempts to be used as a way to figure out a developers thought flow, however it is a flawed system....
Many programmers are introverted and not always the best at speaking in front of people they just met, most people aren't.
The skill the whiteboard is checking is not the skill that will be used on the job, it is overly focused on an extroverted personality and how well this developer can present to new people. An introverted developer might mess up in an interview but be making the best designs, products and presentations to the team later when the team is known.
The true test is in the trenches and no test in an interview by a select few people in the company can ever tell product delivery and developer skill, the interview steps are just some litmus tests. Companies want the best and brightest but many are getting cut off at the pass from a whiteboard. Is the interview really where we determine who is the best, not the work? What costs more, losing a good developer to an interview process or letting someone in you determine isn't a good fit 1-2 months in on a small project.
I was asked to write code to solve this problem during an interview once:
"You are driving at a constant speed. After a while, you pass a mile marker with a two-digit number on it. One hour later, you pass another mile marker with the same two numbers on it, but in reverse order. In another hour, you pass a third mile marker with the same two digits separated by a zero. How many miles per hour are you traveling and what numbers were on each of the mile markers?"
When I started working at the company, what was the first thing they had me do? Convert all the tabs in their Ruby source files into spaces.
That right there is the problem with whiteboard questions.
I was asked to do whiteboard interview once. I simply laughed and thanked for wasting my time. This was a company that knew me from previous jobs and they still insisted on this pointless exercise (1). From that point on I start by asking first, I dont do whiteboards, I dont do quizzes, I dont do personality/aptitude evaluations or out of the box tests. There is no point in asking me what some silly obscure acronym means when google is 2 seconds away, or testing if Im a team player if Im being hired to sit in the basement and staple patch cords together.
Google can pull this BS because they pay good money and are at the top of their game. But 100 employees boring 9-5? lol no. Lets face it, I dont need you, you need me. You came to me first.
1/ I returned twice as a contractor to fix shit build by new employee screened with white board :). This wasnt even a big company with strict corporate ruleset, they were just clueless :/
"Back in the ‘60s and ‘70s, when microcomputers like the Apple II were all the rage, computer time was expensive, pressure-packed and cumbersome."
Does no one fact check anything anymore? If you're going to base part of your argument around technology that was around before you were born maybe do a little more research? And also... get off my lawn? Am I really that old?
Also it should be mentioned that the author is a co-founder of HackerRank.com , which is trying to be the testing platform for new interview candidates.
From the article, I didn't get any information on why or what or if there is a "Looming Fall" of the whiteboard for testing engineering candidates.
At InterviewKickstart.com, we train candidates on various interviewing styles.
We believe, that a whiteboard is here to stay for some time, however much we hate it. Why?
1. Coding is perceived to be a commoditized skill, but engineering is not. Most companies worth their salt, hire engineers and not coders.
In today's world of nearly everything available readily, coding is maybe 30% of an engineer's job. Rest is designing, explaining and thinking in a collaborative setting to arrive at the right solution/design/spec. There is no better tool for collaborative working than a whiteboard, and you want to see those skills in an interview.
2. It's really easy to discuss a system-design question. Reading code samples and documents doesn't give you a good idea of how a system is designed, as much/fast as talking to the person does. When talking about such high-level concepts, a block-diagram on a whiteboard is inevitable.
3. Coding doesn't happen at speed of thought. Whiteboarding does. When you are trying to assess someone's thought-process, you need a tool that caters to that speed.
4. Whiteboards are way more "visible" and life-size. They force you to stand up and hence pay attention.
5. A more subtle and controversial reason: White-boarding allows for approximation in a solution, which can be a good thing for an interviewer. Most interviewers are only concerned with high-level aspect of code and don't want to take the time to read a solution in detail. Whiteboard provides that out.
6. When writing code in an assessment tool, it is not sufficient that the test-cases pass. You also have to pay attention to the time and space complexity. And when that complexity is not what you want, you feel like discussing it with the candidate, instead of just rejecting him/her. Whiteboarding allows the interviewer to pay attention to those things quickly.
7. Google does it! So everyone is going to keep following that :-)
Pair programming is a great alternative to whiteboarding. But still it doesn't replace a whiteboard, which is just so fast, collaborative and convenient.
Is the whiteboard interview perfect? No, there is no perfect method.
Disclaimer, I give lots of white board interviews. What am I looking for?
Syntax? Nope, I let the candidate use any language they want, they can even make it up as they go, as long as its consistent and doesn't contain magic. Most of my questions are simple and operate on arrays.
A good talker? Not really, although someone who freezes up and can't talk might be an issue discussing their ideas in a group, but its not disqualification. The number of people who have been actively anxious to the point they can't code anything on the whiteboard? Never encountered it, I've given maybe 500 white board questions.
My question revolves around iterating through an array, keeping track of a couple of pointers, and doing some simple swaps, its a sorting problem. I'm looking for people who can think 'step by step', people who can look at a very simple program, and keep track of how its executing.
You might say, you have an IDE to do that! IMHO, Any decent programmer can look at 8 lines of code and step through that . Most of the time, when I'm debugging something in prod, I only have a stack trace and the source code. I have to figure out how the trace could have been thrown, and I have to step through a bunch of code to figure that out.
Finally, Whiteboard coding is a skill, just like how to debug or how to import a project into an IDE; its a necessary skill to get a job. Plus, when I look around my room, I can spot 3-4 whiteboards, all of them have code and diagrams written on them. None of those came from an interview, those are all the result of one engineer communicating to others about their ideas.
edit: Last thing, the alternatives, side by side keyboard coding, a take home project. All of these have cons, keyboard anxiety is just a prevalent as whiteboard, just a different medium. Take home projects are nice, if you expect a candidate to spend a weekend coding for your interview. Just as people have walked out because of a whiteboard interview (something I've never encountered), I've actually dropped pursuing a company when they gave me a fairly complex take home project when I was at the offer stage at a different one. Fuck spending a day working on some throw away work and not get the job.
>Finally, Whiteboard coding is a skill, just like how to debug or how to import a project into an IDE; its a necessary skill to get a job.
I mean... it's a necessary skill to get a job from you. It's far from universal, as evidenced by the fact that I have been employed as a software engineer for quite some time and have never done whiteboard coding in my life.
I've choked so bad on whiteboarding interviews that I've felt ashamed for weeks; yes, I am one of those people. But then when I broke the anxiety after practice, they became easy. The key is understanding that it's the process over the solution.
However, I'm quite proud of the fact that where I currently work we never ask someone to code on a whiteboard. Rather, we ask them to complete a take home test and then, when they're ready, invite them in to discuss their choices and augment it functionally. This practice is, in my opinion, holistically far more effective at gauging a candidate's competence and ability.
That is a far superior method for conducting an interview. Even though I'm not terrible at whiteboard interviews, I absolutely hate working while someone who already knows the answers watches over me waiting for a mistake.
Sadly I was able to find various great solutions to my take home programming assignments after the fact. I submitted my own original solutions, but I'm sure there are others that didn't bother/know how and submitted the other solutions they found online. I'd like to think the interviewer had an exhaustive list of Google search results for the problem, but I sadly doubt it.
What I mean about take home test is "build an app that does x y and z, write tests, talk about your choices" -- something that you can't quite google. Take home tests for questions like "explain how to use fn.apply()" wouldn't work :)
I don't think it's a problem with the whiteboard specifically or even public speaking. It's a unique situation where you're trying to solve a problem, while simultaneously explaining it to a person you've never met before, who happens to already know the answer.
Explaining something on a whiteboard to a group of co-workers is an entirely different skill.
> Fuck spending a day working on some throw away work and not get the job.
You can easily make a shorter take home project. You're already going to have to spend a day on interviews. Why not spend half a day on interviews, and half a day at home on a take home project?
#1 I introduce myself and what the project(s) entail and how things get done.
#2 I ask them some questions about their experiences, and ask them to tell me a story about some past memorable experience.
#3 I ask them to do a simple coding exercise (5 - 10 mins tops). If they bomb it, I don't care, what I want to see is how they _react_ to feedback. Some people will get belligerent during the interview, and that is definitely a red flag that I will not enjoy working with them.
#4 I let them ask me any questions they have and then wrap things up.
I think hiring engineers with a specific skill is great for a contracting position. But if you want to hire someone in a full time position, some learning on the engineer's part is to be expected.
Just like many programmers fail at FizzBuzz, many interviewers have no business conducting interviews. Also remember that these practices will continue until someone educates them. So, the next time you're given 45 minutes to code up a radix sort in a whiteboard, instead start a discussion about interview techniques. The socratic method goes a long way to making people realize just how much they are cargo culting.
God, programmers are the biggest whiners in the world when it comes to interviewing. Do you know the shit doctors and lawyers have to go through to get hired? If you did, you'd thank Jesus that all you have to do is solve problems on a whiteboard. If you can't do it, then here's a simple and effective solution for you: practice!
My impression for law interviews is that they're not super technical. They're all "Tell me about yourself," "What's your interest in the organization," "What did you think of the way your law school taught" — the kind of questions that only have wrong answers, which is its own special hell, but a different hell. No one's asking for precedents or deep incisive analysis, really, but I guess they can count on the bar exam to ensure a minimum level of competence. Is my understanding of this wrong?
Yeah once time at the beginning of their career. A programmer can have 10 years of experience and a huge body of prior work up on Github for everyone to see, and yet he still has to get up in front of a whiteboard and answer questions about dropping eggs from a building, or reversing strings.
Doctors and lawyers do have to go through a long and expensive process to become doctors and lawyers, but once they pass the bar/finish their residency their hiring process is much the same as anyone else. They are certainly not made to do some weird Kabuki theater demonstration where they are forced to quickly solve some difficult problem that has little or nothing to do with their work.
Peoples' assessments of the difficulty of work depends on how much they enjoy it. Most lawyers would probably consider passing the bar exam, while difficult, to be easier than learning a programming language. If they were told that our normal hiring process consists of being made to hand-write on a whiteboard, in Java or C++, the most optimal algorithm for a randomly-chosen complex mathematical problem, in 30 minutes or less, with someone watching and critiquing you the entire time, and if your answer is in any way suboptimal you aren't hired, no matter how impressive your previous body of work - then they (the doctor or lawyer) would undoubtedly wonder why we would ever put up with such a thing.
Amen. And don't forget the "learn just enough to be dangerous" coding academies out there. Plus all of the developers that just Google their problem and use the blog/SO code from the first hit as their work. Finally we've got plenty of IDE's and plugins for said IDE's that can generate all the code you need, though without understanding why it was generated that way, what it really does, and how it will fail.
In short, it's far too easy to fake being a coder. The Whiteboard is a great way to see if they can hack it, and hence it's been around for two decades or more.
But then there are all the introverted Google search coders out there that don't like talking with other human beings. For them, whiteboard coding and being asked "why" they used this or that method is too much to handle, hence the cheers of "down with the whiteboard!"
In the case of doctors, yes, I do. They demonstrate that they have a medical degree, have completed their residency, have passed their boards, and then provide proof of prior work experience. What they don't have to do is perform some esoteric and completely irrelevant surgical procedure on a gourd.
The reason the practical among us are complaining about whiteboard questions is:
1. They are arcane and esoteric and do not reflect the day-to-day activities of the company.
2. Programming is an iterative process complete with tools, visual feedback, and documentation. A whiteboard question takes away all these things and puts the engineer in an unrealistic situation. Using you doctor example, it would be like asking a doctor to prove their medical skills by performing a microtia repair on a banana using a bra and a bouncy house. Fun, of course, but completely irrelevant.
3. They are the sign of an unskilled interviewer.
Personally, I have no interest in practicing to master the impractical, irrelevant, and incompetent whiteboard question skill when I can simply go interview with a company who knows how to conduct an effective interview. Maybe the prestige of working at Google or Microsoft is worth it to people to slog their way through those kinds of interviews. Personally, I went through Microsoft's interview process and ended up working there for over a year. I've had better jobs and I still think their interview process is retarded. I certainly wouldn't put myself through it again.
> They demonstrate that they have a medical degree, have completed their residency, have passed their boards, and then provide proof of prior work experience.
Oh, you mean that's all they have to do? If you think being judged by a whiteboard problem is arbitrary, imagine being judged by your score on a fill in the bubble boards exam. And even after getting their degree and passing the boards, doctors still have to go through an interview that would make the average programmer cry. I worked directly with doctors for several years, and almost tried to become one myself. The shit they have to deal with is on a whole other order of magnitude from anything programmers go through.
I have worked with surgeons and anesthesiologists for the last 12 years, so I know what they have to do as well.
One important thing to keep in mind is that a surgeon or anesthesiologist is taking their patients' health, and even their lives, into their hands when they operate. I've written code for 25 years and nobody's life has ever been at stake.
Furthermore, when something is stupid and a waste of time, it should be discussed, dealt with, and eliminated; regardless of how many other stupid things exist in life.
I just switched to coderpad.io, and so far I really like it - it takes the place of a phone interview. I'm looking for JS engineers, so I've set up a series of stub functions representing problems - with corresponding tests for each of them. If they can make all of the tests pass within half an hour, they advance. They can ask all the questions they want, search the internet, whatever gets the job done.
For the in-person interview, I sit them in front of a laptop and give them one hour to develop a ToDo app from scratch. Bonus points for things like test cases, mobile deployment, multi-user support, you get the idea.
Here's the thing though. I find these sorts of tasks a waste of my time. I know from personal experience that I can ditch your interview and go get hired by numerous other companies who don't waste my time with drawn out interview processes. Therefore, you're not really testing my skills as much as you are my patience, and I simply don't want to be bothered. I know a lot of other engineers who feel the same way.
Now, if you want to pay me $80 an hour to code a bunch of fluff for you, great! Otherwise, I'm more inclined to look for shorter paths to entry elsewhere.
"Whiteboard problems were never meant to be fast, scalable or simulate real-world problems to ensure high-quality hires."
No "problems" can simulate a real world situation, real world development is not a set of questions to solve. Not even the popular problems where the person is asked to do stuff like write a zigzag binary tree traversal or put ant on a chess board.
Also I still have to understand why interviewing has to be a scalable process. Are we interviewing 1000s of candidates at a time at some company ? From all I can think that is totally not the right place for a company to be.
Granted there are millions of upcoming jobs, they are distributed across too many companies/teams , so the number of interviewees per head would be more or less constant.
"Programmers in this era were just used to the idea of writing code on paper. "
So no one in current age group is comfortable planning on a whiteboard ? Does the author think that things are not planned on a whiteboard in real life ? I am 27 years old (maybe too old according to the article but still I was never a part of the punched card generation ) but how does that count as a reason not to ask someone younger to explain his/her approach or how they incorporate feedback on a whiteboard ? Whiteboard interviews are not meant to check if a interviewee can memorize the language constructs properly as being portrayed by the article, if such is the case, the candidate better walk away.
75 comments
[ 2.8 ms ] story [ 129 ms ] threadFor the type of programming I'm involved in hiring (iOS/Android) it's silly to expect someone not to lean on frameworks/IDEs. It's also unrealistic to expect that every single candidate has a laptop fully set up with their preferred environment. That's what take-home questions are for.
"I need a paycheck" is a great answer for some positions, but a person in demand would have choices, so it's valid to ask "why us?".
Not only that but it's not even clear the person he/she is responding to actually is part of an interview process as opposed to just explaining the reasoning behind the interview question.
Personally I found it needlessly rude and even rather bitter but if you feel like it provided some value then I'm glad it was useful.
When someone asks, "Why do you want to work here?" I might say, "Because I find the way your company puts input fields on a web page to be fascinating, and I want to be a part of it." The reality, however, is I want a damn paycheck and I couldn't care less what the company does.
The point here is that nobody answers these questions honestly. Nobody. So what on Earth is the point of asking them? There isn't one. These questions just fill up space during the allotted hour of interview time, and are used by the interviewer to justify the opinion they formed within the first few seconds of the interview.
On the other hand, what's the point of asking anything during an interview if people can lie then? I imagine these questions are still being asked because it's not all that easy to lie and still sound authentic. I also agree with you though. I think this whole idea of trying to find people to work at a company because this is their dream company is just a silly fantasy for 99.9% of companies. Unless you're Google, chances are slim that working is nothing more than a job.
This whole craze over wanting to love your work and being "passionate" and "excited" is getting out of hand. I feel like I see the word "excited" thrown around everywhere now.
I try to be more pragmatic in my interview process. I don't expect candidates to be passionate because the company isn't their dream. I expect the owner to be passionate, but the rest of us are just here to pay the bills. Therefore, I don't bother looking for passion. What I do want is somebody who has coding experience and someone I'd enjoy working with. I focus all my questions around those two goals, with a greater emphasis on the second.
Whiteboard coding is a terrible practice that should have died 15 years ago. 1 hour of pair programming on a real computer (even locked down with no network access) should tell you all you need to know about a person's skills.
a) I hate having people in my personal space I don't know well. It may seem I'm being an asshole, but I'm very very very very sensitive to smells to the point that I can't concentrate. Your cologne or just body smell will probably be my number one focus throughout that hour.
b) while I don't have OCD/am a germaphobe, again I HATE HATE HATE using a keyboard that isn't new or mine. The stickiness of the keys, the dirt around them... makes me go crazy.
I always carry my laptop to interviews with me nowadays to at least avoid B.
So, for me, a whiteboard is great (for some reason, I don't care much about a dirty board/pens) and I do amazingly well on them. I also do very well in public speaking situations so maybe I'm just comfortable at that kind of interaction/distance.
I think the best is to truly ask the person what they prefer. If they want a laptop, great, if a whiteboard, cool as well, I've done both both as an interviewer and interviewee, and noticed that as well, some people prefer a whiteboard, others a laptop. Give them what they are more comfortable with.
It is like having another programmer in your head and you can't see each other type so there are less jibs/jabs. Plus both people can eat, drink, do things rather than just stand around one workstation like people did with TV in the 50s and one person can't see the screen.
I can't remember the last time I pair programmed in person over remote even in the same office/building. Occasionally you need to be in the same room or desk to draw something up but mostly it is more efficient remotely especially during an integration.
Pair programming remotely is like "hey you got a bug on line 441", pair programming side by side physically is like "dude you got a bug down there, btw just just use this hotkey" or doesn't even see it because you can't see the screen.
When I conduct interviews, I make every effort to keep them to 15 minutes. If we end up chatting for longer than that, that's fine, but the planned and structured part of my interviews are no more than 15 minutes long.
The way I look at it, if a company can't respect my time and can't optimize theirs, I don't want to work for them anyway.
One pager.
The biggest still valid objection is "it won't be setup the way they are used to and so it will take too long for them to be productive even for a toy problem". Maybe. It seems like even they are used to a different color scheme or IDE plugins or whatever they should be able to figure out a default setup enough to write a toy algorithm. Maybe not.
A fucking whiteboard.
Citation needed for the first sentence. I have always heard of whiteboard coding interviews, but I have never heard that they are common and certainly not the majority.
I can't code on a white board to save my life. It all just falls out of my head.
I've heard others say the same thing, so I suspect I'm not at all unique here.
Also, one of the issues of providing an interview candidate with a computer is that some people are very particular with their environment.
For example, even if you let them use an IDE they are familiar with, maybe they really don't like using Macs. Or worse, they don't even use a qwerty keyboard.
In my company nobody uses an IDE, I use vim and the other developers use emacs or sublime. I think we all have our own little plugins/settings that we use as well.
Of course you could solve all of this by letting employees bring their own computer, although not everyone has a laptop either. To be completely honest, I really like the whiteboard but I definitely can see why others don't like it and get the impression I'm in the minority.
I was asked to write syntactically correct code in a specific language on a whiteboard with a time limit. That's very far from how I work on a daily basis. I could understand writing pseudo-code or explaining architecture but what possible data can you gather from how well I draw curly braces on a dry erase board?
It is Slow, Slow, Slow
I am actually greatly in favor of short programming exercises as a framing strategy for interviews. A sort of ersatz pair programming is the way I like to interview candidates: dive straight in with two seats at a machine and get to know the fellow over the course of either a bug hunt on the system he is being hired to work with, or if that's impossible for legal or other reasons then some small, fun coding exercise. Such as, say, "implement the world's worst way to represent and then reverse a linked list," or anything that starts with "you have an infinite tongue floating on a lake of a coffee and a piercing tool..."
Ditching the keyboard in favor of a whiteboard dramatically increases the time taken to evaluate any one shard of the programming experience, however. What can be accomplished neatly with a simple text editor in ten minutes can take a painful hour or more with a pen. Whiteboarding is simply not suited for the exploratory way in which most people code. All that wasted time would be put to far better use in talking, asking questions, and more deeply exploring the interviewee's approach to coding as a profession - touching on the many, many vital aspects of being a developer that cannot be tested in an hour with a text editor and a compiler.
Whiteboarding Primarily Tests for the Ability to Whiteboard
Most folk don't spend their lives working on how to most efficiently and effectively use a whiteboard. There are good reasons for this: we have computers now, with editing and presentation software that is ten thousand times more useful and functional than the combination of pen and whiteboard. Why would anyone choose to practice and optimize a skill that is never going to be used in the ordinary course of their professional life?
Nonetheless, there exist a small number of people who can whip up really great presentations on a whiteboard from scratch, even over the course of a discussion that swings around all over the map, and has no predetermined outcome. These talented folk will make great use of space, have little need to erase and redo, and will generally look good while doing it. But guess what? That skill, while very occasionally useful, has absolutely nothing to do with code or programming.
Most people, given a whiteboard and a free-ranging discussion or problem to solve, will produce an ugly-looking hash of notes and require frequent large-scale reordering of the content on the board to make sense of it all. If you weren't there, it might as well be Hebrew or hieroglyphics. If you were there, it still requires an additional investment of effort to follow what is happening - effort that might otherwise be going to more productive interview strategies.
Erasure and Exploration are Punished Aggressively
People are very individualistic when it comes to that aspect of development that involves the choice, design, and implementation of algorithms - the sort of thing that might take a few minutes to an hour and will typically be just a small part of a larger task. There are as many different approaches as there are types of personality. For my part, actually writing code is exactly equivalent to thinking about the problem: I plunge in and start writing, as that is the process by which I get a handle on what the eventual solution has to involve and how it will be organized. I'd guess that I probably write at least two to three times as many lines of code as eventually exist in any given small solution, and it is the rare module that isn't aggressively refactored or otherwise turned inside-out at some point within the first thirty minutes to an hour of its existence.
In a text editor, this is a very rapid process. It goes about as fast as I can type. On a whiteboard? Not so great. Forcing code away from an editor and into a whiteboard ...
However I disagree with its sentiment that coding resources are free and have no cost. I think this attitude leads to poor quality code. My reasoning is that if you don't have to spend any effort to write code than you will write the laziest code possible. This code might work but it will only work because it evolved from the wrong solution to a barely working solution. If compute time was more of a scare resource developers would spend more time writing correct code instead of iterating until something works.
I don't mean that all developers code poorly because of the decrease in the time of the iteration loop but I feel that it does lead to poor code in the general case.
It would be a huge improvement if companies just gave the candidate a problem, left the room, and came back an hour later. Then they can discuss the solution, ask questions about the code, etc. The key thing is, let them do some quiet alone thinking instead of having to worry about someone watching every move and expecting constant talking.
I couldn't care less how someone thinks. What I want to know is do they have experience writing code and more importantly, are they the sort of person I would enjoy working with. Both of these questions can be answered in more effective ways than a test or whiteboard question.
The way I see it, one could start to find a solution on the whiteboard, possibly with some help from the interviewer. And next stage is writing the actual code, which can be done easily on the whiteboard if it's a short program.
1. The questions are always esoteric and have absolutely nothing to do with the company's business (unless, of course, they are in the business of generating Fibonacci numbers or CSS flags).
2. The situation itself is completely unrealistic and in no way demonstrates "how a person thinks" in a programming situation; which is weird since that is, after all, the universal rationalization for asking whiteboard questions in the first place.
3. Most, if not all, interviewers have no idea what to do with the information they observe in a whiteboard situation, so regardless of the result, it just becomes a confirmation of whatever opinion they formed within the first 30 seconds of the interview.
In my experience, whiteboard questions demonstrate a lack of interviewing skills and are a waste of time for everyone involved. I refuse to interview people that way, and I'll walk out of an interview if someone asks me to solve something on a whiteboard. If you want to see my code, go to my Github account. If you want to see how I solve real-world problems, I use past experience, Vim, a debugger, a terminal, my gists, Dash, and Google. There. Did we really have to waste an hour of everyone's lives to get to that answer? Absolutely not!
Many programmers are introverted and not always the best at speaking in front of people they just met, most people aren't.
The skill the whiteboard is checking is not the skill that will be used on the job, it is overly focused on an extroverted personality and how well this developer can present to new people. An introverted developer might mess up in an interview but be making the best designs, products and presentations to the team later when the team is known.
The true test is in the trenches and no test in an interview by a select few people in the company can ever tell product delivery and developer skill, the interview steps are just some litmus tests. Companies want the best and brightest but many are getting cut off at the pass from a whiteboard. Is the interview really where we determine who is the best, not the work? What costs more, losing a good developer to an interview process or letting someone in you determine isn't a good fit 1-2 months in on a small project.
"You are driving at a constant speed. After a while, you pass a mile marker with a two-digit number on it. One hour later, you pass another mile marker with the same two numbers on it, but in reverse order. In another hour, you pass a third mile marker with the same two digits separated by a zero. How many miles per hour are you traveling and what numbers were on each of the mile markers?"
When I started working at the company, what was the first thing they had me do? Convert all the tabs in their Ruby source files into spaces.
That right there is the problem with whiteboard questions.
Google can pull this BS because they pay good money and are at the top of their game. But 100 employees boring 9-5? lol no. Lets face it, I dont need you, you need me. You came to me first.
1/ I returned twice as a contractor to fix shit build by new employee screened with white board :). This wasnt even a big company with strict corporate ruleset, they were just clueless :/
Does no one fact check anything anymore? If you're going to base part of your argument around technology that was around before you were born maybe do a little more research? And also... get off my lawn? Am I really that old?
From the article, I didn't get any information on why or what or if there is a "Looming Fall" of the whiteboard for testing engineering candidates.
Because its a product placement article (selling HackerRank).
We believe, that a whiteboard is here to stay for some time, however much we hate it. Why?
1. Coding is perceived to be a commoditized skill, but engineering is not. Most companies worth their salt, hire engineers and not coders.
In today's world of nearly everything available readily, coding is maybe 30% of an engineer's job. Rest is designing, explaining and thinking in a collaborative setting to arrive at the right solution/design/spec. There is no better tool for collaborative working than a whiteboard, and you want to see those skills in an interview.
2. It's really easy to discuss a system-design question. Reading code samples and documents doesn't give you a good idea of how a system is designed, as much/fast as talking to the person does. When talking about such high-level concepts, a block-diagram on a whiteboard is inevitable.
3. Coding doesn't happen at speed of thought. Whiteboarding does. When you are trying to assess someone's thought-process, you need a tool that caters to that speed.
4. Whiteboards are way more "visible" and life-size. They force you to stand up and hence pay attention.
5. A more subtle and controversial reason: White-boarding allows for approximation in a solution, which can be a good thing for an interviewer. Most interviewers are only concerned with high-level aspect of code and don't want to take the time to read a solution in detail. Whiteboard provides that out.
6. When writing code in an assessment tool, it is not sufficient that the test-cases pass. You also have to pay attention to the time and space complexity. And when that complexity is not what you want, you feel like discussing it with the candidate, instead of just rejecting him/her. Whiteboarding allows the interviewer to pay attention to those things quickly.
7. Google does it! So everyone is going to keep following that :-)
Pair programming is a great alternative to whiteboarding. But still it doesn't replace a whiteboard, which is just so fast, collaborative and convenient.
Disclaimer, I give lots of white board interviews. What am I looking for?
Syntax? Nope, I let the candidate use any language they want, they can even make it up as they go, as long as its consistent and doesn't contain magic. Most of my questions are simple and operate on arrays.
A good talker? Not really, although someone who freezes up and can't talk might be an issue discussing their ideas in a group, but its not disqualification. The number of people who have been actively anxious to the point they can't code anything on the whiteboard? Never encountered it, I've given maybe 500 white board questions.
My question revolves around iterating through an array, keeping track of a couple of pointers, and doing some simple swaps, its a sorting problem. I'm looking for people who can think 'step by step', people who can look at a very simple program, and keep track of how its executing.
You might say, you have an IDE to do that! IMHO, Any decent programmer can look at 8 lines of code and step through that . Most of the time, when I'm debugging something in prod, I only have a stack trace and the source code. I have to figure out how the trace could have been thrown, and I have to step through a bunch of code to figure that out.
Finally, Whiteboard coding is a skill, just like how to debug or how to import a project into an IDE; its a necessary skill to get a job. Plus, when I look around my room, I can spot 3-4 whiteboards, all of them have code and diagrams written on them. None of those came from an interview, those are all the result of one engineer communicating to others about their ideas.
edit: Last thing, the alternatives, side by side keyboard coding, a take home project. All of these have cons, keyboard anxiety is just a prevalent as whiteboard, just a different medium. Take home projects are nice, if you expect a candidate to spend a weekend coding for your interview. Just as people have walked out because of a whiteboard interview (something I've never encountered), I've actually dropped pursuing a company when they gave me a fairly complex take home project when I was at the offer stage at a different one. Fuck spending a day working on some throw away work and not get the job.
I mean... it's a necessary skill to get a job from you. It's far from universal, as evidenced by the fact that I have been employed as a software engineer for quite some time and have never done whiteboard coding in my life.
However, I'm quite proud of the fact that where I currently work we never ask someone to code on a whiteboard. Rather, we ask them to complete a take home test and then, when they're ready, invite them in to discuss their choices and augment it functionally. This practice is, in my opinion, holistically far more effective at gauging a candidate's competence and ability.
Explaining something on a whiteboard to a group of co-workers is an entirely different skill.
> Fuck spending a day working on some throw away work and not get the job.
You can easily make a shorter take home project. You're already going to have to spend a day on interviews. Why not spend half a day on interviews, and half a day at home on a take home project?
#1 I introduce myself and what the project(s) entail and how things get done.
#2 I ask them some questions about their experiences, and ask them to tell me a story about some past memorable experience.
#3 I ask them to do a simple coding exercise (5 - 10 mins tops). If they bomb it, I don't care, what I want to see is how they _react_ to feedback. Some people will get belligerent during the interview, and that is definitely a red flag that I will not enjoy working with them.
#4 I let them ask me any questions they have and then wrap things up.
I think hiring engineers with a specific skill is great for a contracting position. But if you want to hire someone in a full time position, some learning on the engineer's part is to be expected.
For doctors I have no idea.
Peoples' assessments of the difficulty of work depends on how much they enjoy it. Most lawyers would probably consider passing the bar exam, while difficult, to be easier than learning a programming language. If they were told that our normal hiring process consists of being made to hand-write on a whiteboard, in Java or C++, the most optimal algorithm for a randomly-chosen complex mathematical problem, in 30 minutes or less, with someone watching and critiquing you the entire time, and if your answer is in any way suboptimal you aren't hired, no matter how impressive your previous body of work - then they (the doctor or lawyer) would undoubtedly wonder why we would ever put up with such a thing.
In short, it's far too easy to fake being a coder. The Whiteboard is a great way to see if they can hack it, and hence it's been around for two decades or more.
But then there are all the introverted Google search coders out there that don't like talking with other human beings. For them, whiteboard coding and being asked "why" they used this or that method is too much to handle, hence the cheers of "down with the whiteboard!"
The reason the practical among us are complaining about whiteboard questions is:
1. They are arcane and esoteric and do not reflect the day-to-day activities of the company.
2. Programming is an iterative process complete with tools, visual feedback, and documentation. A whiteboard question takes away all these things and puts the engineer in an unrealistic situation. Using you doctor example, it would be like asking a doctor to prove their medical skills by performing a microtia repair on a banana using a bra and a bouncy house. Fun, of course, but completely irrelevant.
3. They are the sign of an unskilled interviewer.
Personally, I have no interest in practicing to master the impractical, irrelevant, and incompetent whiteboard question skill when I can simply go interview with a company who knows how to conduct an effective interview. Maybe the prestige of working at Google or Microsoft is worth it to people to slog their way through those kinds of interviews. Personally, I went through Microsoft's interview process and ended up working there for over a year. I've had better jobs and I still think their interview process is retarded. I certainly wouldn't put myself through it again.
Oh, you mean that's all they have to do? If you think being judged by a whiteboard problem is arbitrary, imagine being judged by your score on a fill in the bubble boards exam. And even after getting their degree and passing the boards, doctors still have to go through an interview that would make the average programmer cry. I worked directly with doctors for several years, and almost tried to become one myself. The shit they have to deal with is on a whole other order of magnitude from anything programmers go through.
One important thing to keep in mind is that a surgeon or anesthesiologist is taking their patients' health, and even their lives, into their hands when they operate. I've written code for 25 years and nobody's life has ever been at stake.
Furthermore, when something is stupid and a waste of time, it should be discussed, dealt with, and eliminated; regardless of how many other stupid things exist in life.
For the in-person interview, I sit them in front of a laptop and give them one hour to develop a ToDo app from scratch. Bonus points for things like test cases, mobile deployment, multi-user support, you get the idea.
Now, if you want to pay me $80 an hour to code a bunch of fluff for you, great! Otherwise, I'm more inclined to look for shorter paths to entry elsewhere.
Also I still have to understand why interviewing has to be a scalable process. Are we interviewing 1000s of candidates at a time at some company ? From all I can think that is totally not the right place for a company to be. Granted there are millions of upcoming jobs, they are distributed across too many companies/teams , so the number of interviewees per head would be more or less constant.
"Programmers in this era were just used to the idea of writing code on paper. " So no one in current age group is comfortable planning on a whiteboard ? Does the author think that things are not planned on a whiteboard in real life ? I am 27 years old (maybe too old according to the article but still I was never a part of the punched card generation ) but how does that count as a reason not to ask someone younger to explain his/her approach or how they incorporate feedback on a whiteboard ? Whiteboard interviews are not meant to check if a interviewee can memorize the language constructs properly as being portrayed by the article, if such is the case, the candidate better walk away.