11 ms·

What's with all the whiteboard backlash? I ask simple questions and expect people to be able to write code unaided to express their idea. Not "implement a linke

What's with all the whiteboard backlash? I ask simple questions and expect people to be able to write code unaided to express their idea. Not "implement a linked list" or "write quicksort" but basic "You have two arrays - find if a number exists in both arrays" sort of thing, primarily to reason about runtime complexity, and to make sure they can actually write code. If you tell a candidate to prepare, they should be able to come in and do this. If they can't write some simple code unaided, then I don't want to work with them. I was a copy-paste programmer once too.

ljlolel 10y ago
What about just asking the candidate to do the same simple task on a computer that they own?
- chronicx0 10y ago
  Lots of candidates cheat. Especially from China and India.
- bobobjorn 10y ago
  I have used both ways, and i would say the candidates in general respond better to using the whiteboard. I do ofcource not require syntacitly correct code or anything like that. Im looking for ideas not if they are a compiler. Using their own computer way to many struggle with creating a new project or other basic things. And that dont make them comfortable either. It also takes much longer then using the whiteboard.
- pavel_lishin 10y ago
  My office is a satellite of a larger one in Austin; we provide laptops for candidates to use for the "remote" part of the interview, when they interview with someone in Austin. But in general, I think the idea of the whiteboard interview is a chance to see someone "think out loud", to see them reason through a problem. Getting a chunk of source code in an email isn't representative of that. (At worst, they paid someone to do it for them; at best, you have no idea what their approach was. Somewhere in the middle is copying and pasting most of it from SO.)
  - eddieroger 10y ago
    > But in general, I think the idea of the whiteboard interview is a chance to see someone "think out loud", to see them reason through a problem. This is exactly why I do this kind of stuff as well when interviewing. It's not about syntax or the ability to recall (regurgitate?) a function, but how does someone approach a problem and where can the conversation go from there. If you sent someone pre-work to write an array matcher, you'll see a final result, but not how they think through it, and you'll miss potential queues to further the conversation.
  - deadbunny 10y ago
    > At worst, they paid someone to do it for them Which would easily come out at the interview when they fail to answer basic questions about their code. > at best, you have no idea what their approach was So? Did you get code that would pass a code review? Did you get code with good commits/history?
    - stale2002 10y ago
      Not really. It is much easier to talk about a solution, when the solution is right there in front of you, and you read an explanation of the solution online. Regurgitating someone else's solution is fairly easy.
  - vonmoltke 10y ago
    > But in general, I think the idea of the whiteboard interview is a chance to see someone "think out loud", to see them reason through a problem. So thinking out loud while coding is a job requirement now? I have been an engineer for over 14 years, and a software engineer for 10, and I can count on one hand the number of times I have done that outside of an interview. I collaborate all the time, but almost never synchronously while actually writing code.
    - dtech 10y ago
      Reasoning about problems is a very essential job requirement. And doing that out loud is the one of the few ways people can see how/if you do that.
rimliu 10y ago
So you test their ability to write code on the whiteboard. I was once programming with pen and paper too (only had access to computers at university). They I bought my own computer.
- drdaeman 10y ago
  Don't know why this comment is downvoted, because he has a point. Writing actual code on whiteboard is different, unless it's pseudocode without any syntax rules and standard libraries. I'm not a newbie (like, 15 years coding). But I haven't even bothered to properly remember standard libraries peculiarities - since they're different across the languages anyway, and with modern software stacks (that are quite diverse) it's not unusual to write Python but do some C or C++ one day (speed-ups), detour to JavaScript, try out Elm, then have a day patching some Go code that an useful tool is written in, then go learning some Elixir. Is it strpos(substring, string) or strpos(string, substring)? What does base64.encode(blob) returns, again, ASCII bytes blob or a text string? Which module/header file contains/exports that symbol? Maybe I'm doing it all wrong but I honestly never remember such details that for longer than a week or another - a proper tooling always hints those kind of things to me, so I don't even recognize I tend to forget them. On a whiteboard, I'd have some awkward moments.
  - crush_xc 10y ago
    Why does everyone assume that you're asked to write perfect code on a whiteboard? I've been through 15+ interviews and have never been asked to worry about method names being right or signatures of methods being perfect and such. Most of the time people are amicably against me worrying about it. This isn't an issue.
    - mikulas_florek 10y ago
      Exactly! When I was hiring I was even asking question I did not know answers to (not as a canditate, but as an interviewer).
    - kirkdouglas 10y ago
tyingq 10y ago
I suspect the backlash is mostly because an interview is already stressful. Then, when you ask someone to code with a marker, all of the muscle memory associated with how they usually code is gone...adding to the stress. You may be missing out on good candidates that just don't "whiteboard well". Of course, some interviewers are better than others, and can manage to do things to make it a reasonable experience. You outlined some of the things that you do that make it seem like you're in that camp. I'm not sure there's any one-size-fits-all interview technique that is universally better than others. The homework approach seems popular here, but then there are others that are put off by it. Probably the best thing is an interviewer that's smart enough to change gears when they sense the approach isn't really testing the candidate's skill.
tluyben2 10y ago
> What's with all the whiteboard backlash? As always, some companies spoil it for the rest; whiteboards are fine but the crazy Hackerrank kind of interviewing, coding, on a whiteboard, correct algo's you studied in uni 10+ years ago and so on got a lot of people annoyed. Nothing wrong with having someone sketch an architecture or a brief plan-of-attack on a whiteboard. But demanding someone to write a correct Bailey–Borwein–Plouffe implementation (I read a few months ago someone got that question in an interview; find the nth digit of PI efficiently as you can. How useless.) or something from their brain without a computer is just rather insane imho. Seeing if they can write code would be actually writing code. Behind a laptop with access to internet and time to do it. Also; previous work.
- partycoder 10y ago
  There is a legal framework for interviews (e.g: EEO). Probably they didn't like the candidate and they dismissed that person through a question they weren't expected to answer.
  - tluyben2 10y ago
    What does that entail? I thought the US was not as strict on law for workers / interviews.
    - partycoder 10y ago
      Dismissing someone using an objective/concrete criteria such as a failed programming test is not problematic. On the other hand, if you dismiss someone because "is not a cultural fit" or some other subjective reason, the person can sue you, accuse you of discrimination and challenge you to prove your point over a legal mine field.
      - lostcolony 10y ago
        Most companies avoid that by not giving candidates a reason why they were not hired.
onion2k 10y ago
I think the primary problem with this sort of interview process is that most companies don't hire enough people to discover whether or not it actually works, plus an interview is so much of a multivariate problem that you'll never really know which part of the process is broken if a bad hire gets though. And that's compounded by the fact any false negatives (great candidates who would have fitted in but got rejected) are clearly never going to be discovered. The problem I have with whiteboard coding in interviews is that there just seems to be better alternatives. Using a computer as other people have suggested, but also just talking to them you can figure out if someone knows how to code. If you ask someone how they'd check if a number is in two arrays you can immediately tell a developer from a non-developer (or an inexperienced developer) by the language they use and the questions they ask. If they mention loops then that's a bad sign. If they start talking about whether or not the arrays are sorted, how big they are, whether you could refactor the array building code to return the data as a object index instead ... then it's clear that the person knows how to code simple things, and all without needing to pick up a marker pen.
- runako 10y ago
  > If they start talking about whether or not the arrays are sorted, how big they are, whether you could refactor the array building code to return the data as a object index instead ... then it's clear that the person knows how to code simple things, and all without needing to pick up a marker pen Having worked with people like this, I have to call BS. There are a lot of people with the distinct skill of being able to effectively imitate the speech patterns of actual programmers. Asking questions, engaging in productive discussion, etc. But when faced with an empty editor, they simply cannot produce working code. If you're already talking about coding a really simple problem like your array example, why not let them use a computer language to express a solution? After those 5 minutes, you can move on to richer parts of the interview confident that you're (probably) not going to hire a total bozo.
  - vonmoltke 10y ago
    > Having worked with people like this, I have to call BS. There are a lot of people with the distinct skill of being able to effectively imitate the speech patterns of actual programmers. Asking questions, engaging in productive discussion, etc. But when faced with an empty editor, they simply cannot produce working code. Having never worked with anyone like that, I will have to call BS on this because it is simply too hard to believe, without evidence, that someone can understand this level of detail and not know how to create working code. A parrot cannot engage in productive discussion, and aping speech patterns only goes so far. Plus, if they're so good at aping speech patterns, who says they aren't equally good at aping code patterns?
discordianfish 10y ago
It simply selects for people who can write a simple code unaided in an interview situation while somebody is watching every letter you type. Many people don't have a problem with that, others have.
- ealexhudson 10y ago
  I'm not sure that's true (in terms of explaining the backlash against whiteboarding specifically). From the page: "The companies and teams listed here instead use interview techniques and questions that resemble day-to-day work – for example pairing on a real world problems" I would contend that if you're doing pair programming with a candidate, you're looking at people writing code in an interview situation while somebody is watching every letter you type. In fact, I think hacking on actual code is worse than whiteboarding: everyone knows how to use a pen and board, but don't do so frequently. Different candidates being placed in front of the same computer and IDE, however, may be vastly more comfortable or not - they may know the bindings, etc. If they're not the "driver" in the pair, they still have to grok the codebase and the problem quickly. Whiteboards may be abstract, and people may focus too much on algorithms with them. I don't think that there is much fundamentally different about pairing, and I would have more reservations with pairing personally.
ciqsteve 10y ago
Whiteboarding itself is a skill. What I learned the hard way: - There is no insert. If you need to go back and insert a line of code somewhere you must either erase all the code below it to make room (then rewrite said code), or you draw a line from the insertion point to somewhere else on the white board and write the code there. For the former you waste a lot of time. For the later the code quickly becomes hard to follow. - There is no context driven autocomplete or quick method lookup. If you spend your entire day coding in one language and have done so for the last >3 years you should be fine. If you code in multiple languages and spend time with other tasks (devops for example), you might not realize how much you rely on this. - The white-boarding process works well (given previous two caveats) if you code in a linear style. If you code iteratively the whiteboard is not your friend. My recommendation to someone starting the interview process. Go buy a small whiteboard and use it to code solutions to interview questions you find online.
- whazor 10y ago
  I am assuming that you can use pseudocode
  - sterex 10y ago
    Exactly! The above comment assumes that a linter will be run against the core on the white board. Jeez.
- ryandrake 10y ago
  All your points are good--and they are part of the overall problem with whiteboard coding: A whiteboard is not even close to a realistic modern development environment. How many times, for your job, have you had to code up a solution to a problem, even a trivial one: 1. Just given to you 5 seconds ago 2. With no access to documentation (paper, textbooks, offline or online resources) 3. With no access to mentors or colleagues 4. With an editor crippled as you described 5. Have to get it right within minutes? 6. And then have to defend your code against someone who's had plenty of time to think about the problem. I can tell you, throughout my programming career, the answer is "never".
FLUX-YOU 10y ago
>If they can't write some simple code unaided, then I don't want to work with them. I was a copy-paste programmer once too. Lovely. Someone put up with you, but now you won't do the same and offer to teach.
- flavor8 10y ago
  If you want to learn on the job and are happy to accept an intern's salary, that's great. Most organizations will be able to accomodate you. If you want $140k and can't code productively, most early startups won't want you. Larger organizations may be able to accomodate you. There are a shocking number of candidates who apply to senior positions who flat out cannot code. I have hired in the past without doing the whiteboard exercise and been burned by this; never again. The whiteboard is a filter to eliminate people who misrepresent their abilities.
  - FLUX-YOU 10y ago
    >I have hired in the past without doing the whiteboard exercise and been burned by this; never again. You should consider offering multiple technical tests and letting the candidate choose. Ideally the choices would range from whiteboard, take-home project, quiz site (hackerrank), or pair coding.
- icebraining 10y ago
  Or maybe ninjakeyboard skilled up before applying for a job.
StringEpsilon 10y ago
We do technical interviews on conceptual levels. One manager, one HR, one programmer (not always all three at the same time) and the interviewee. We ask them about their experience with the tech we use / plan to use and test what they tell us with specific questions. If you tell us you know ASP.NET, I might ask you to describe the default routing or some specifics about razor views. If you tell me you are a git expert, I might ask you about interactive rebases and cherry-picking to find out when and how you'd use them. General know-how is usually more viable than the ability to write working code in a pinch. The closest thing to a whiteboard test we have is giving you a page of code to ask you what's wrong with it (although, we don't do that often).
sgdread 10y ago
I've got pretty complicated exercises in whiteboarding sessions: some problems with graphs or dynamic programming. The way how I solve those in my daily work is totally different to the way I go in 45 min whiteboard interviews: in 45 min you always have to do it in top-down manner, otherwise you will fail by writing non-relevant parts of the code and running out of time. I usually prefer opposite: bottom-up approach. It's a skill. Very artificial and very dumb to my opinion since you never work this way, but interview supposed to test how you do you work.
at-fates-hands 10y ago
>> What's with all the whiteboard backlash? Here's the deal. As a developer, I have about 30 repos out on GitHub with plenty of examples I've done in the last three years. If you want to interview me, then go look at my code first. I have a pretty specific style so all the code is consistent. Go look at my code, dissect it, ask me questions about it, ask me why did this instead of that, why I prefer some library over another one, etc. If you feel like my skill set is what you're looking for, then bring me in and then we can see if we're a good fit for each other. If you don't like what you see, then don't bring me in - it's really that easy. Having one or two whiteboard examples will never, ever, show someone the depth of your skill set. You have to look at their code, which will give you insights a whiteboard interview never will. All the things you mentioned about "basic skills" are obvious when you look at someone's code. Did they use classic or prototypal inheritance? Did they know what closures are? Did they use a factory pattern? Are they using ES6 yet? What tools are they using for their projects? All this and a ton more simply from looking at their code. And if you're a developer, you should have an account on codeplex, or github, or bitbucket where interviewers can go look at what you're working on and the stuff you're building. It completely cuts out the "coding" part of the interview and should simplify the whole process.
- snissn 10y ago
  A business wants to hire you to solve business problems. Coding is the manifestation of the solutions. To me the white board session is to understand if you can take new problems and understand them enough to sketch out a solution. As a hiring manager, I'm glad you've written code before, I want to understand on a day to day basis if you can transform business problems into solutions.
  - lostboys67 10y ago
    exactly the code is just a means to an end ie solving a real world problem
  - logfromblammo 10y ago
    At most of the companies I have worked for, the difficult part of my job is taking the pre-existing code that barely works under the old internal proprietary framework and rehabilitating it into the new internal proprietary framework with a bare minimum of new development. Showing off that I know how to write (or recognize and copy) good code from scratch does not signal for that. I can't tell you how many times I have had to code something that is objectively incorrect because the old version did it that way, and the customer doesn't want the new version to be different. The problem with the whiteboard interview is that you can't show an old, crufty code base on it, and ask the candidate to sketch out how to implement a simple feature request without overhauling the whole thing to use industry best practices. And you can't show an existing relational database schema that is pathetically ill-designed and ask about a new report for the customer. Those are the sorts of problems businesses have. They don't suck it up and pay the big bucks for a software pro until after the amateurs have already tried fixing it with an Excel spreadsheet or an Access database. And they don't want you to mess up the solution they already have, no matter how much baling wire and duct tape is holding it together. Not everyone that can write code can also work well within an existing codebase. The only situation in the wild that I would trust to indicate that skill for my company is someone who actively contributes to an open-source project with a lot of other active contributors. A one-person side project that shows off everything you can do all by yourself won't reassure me. In fact, if it's too good, I might be worried that you will want to overhaul working code just because it's really, really ugly, and you can detect multiple code smells when you look at it.
lhnz 10y ago
Part of this is that a lot of interview practices (including whiteboarding) exclude people that suffer from social anxiety. Just because somebody freezes up when being watched and critiqued by an Evaluator, doesn't mean that they are 'copy-and-paste programmers'. There are probably a lot of extremely good engineers who find this style of interview difficult. People that call 'whiteboarding' a skill don't really get it. If you have irrational fear over people's judgements and this manifests when you're being interviewed, you can't merely expose yourself to this fear often to lessen it. It is very difficult to change how your mind and body react to uncomfortable situations. Of course, you need to test ability, but you should also accommodate people's preferences on the environment that they are evaluated in. You can negotiate whatever this is by speaking to them: they might have a Github with projects which they can discuss with you, or they might be happy to do a small project, etc. You need to keep your standards high, while also ensuring that they feel that they are able to do their best.
- ninjakeyboard 10y ago
  "People that call 'whiteboarding' a skill don't really get it. If you have irrational fear over people's judgements and this manifests when you're being interviewed, you can't merely expose yourself to this fear often to lessen it. It is very difficult to change how your mind and body react to uncomfortable situations. " I disagree on a few levels. I can't back anything with data but I'll point to where you can find many people who will offer their anecdotal stories of desensitizing themselves. Being able to talk and interact with people is a part of the role. Software is not written in isolation - it is done best with a lot of collaboration and critical review of work. Being able to communicate and give and receive critical feedback are cornerstone traits. Good code is not written in isolation and giving and receiving critical feedback is not comfortable. If I interview for those traits and qualities, I hope that I'm not discriminating against social anxiety but I spent 5 years in toastmaster's throwing myself in uncomfortable situations until I could come out of it. I feel like interviewing is becoming this PC thing where we try to form to evaluate people in the way that is comfortable for them, where we live in a world where people need to break out of their comfort zone and learn to shape themselves into their environments. Go to Toastmasters, speak in front of people, keep going and you'll improve your skills - yes the soft ones too. You'll become comfortable - you will - ask anyone who stands and speaks confidently in front of you in those rooms if they were always that calm and composed while speaking in front of people. They were not and they learned to speak 'off the cuff' on topics they were not prepared for or subjects they didn't expect in there. Maybe I'm alone in my thoughts but I'm looking for people who will grow. I want someone who will stand strong if I give them a critical code review - I want someone who will hang their ego at the door and be able to talk about what we're working on objectively. If I'm still coming off too hard on this, what if I say that it's a consulting company that I'm hiring for and that the staff will be in front of customers who will interview and drill them every day? Ultimately, we can grow and change. I know we can because I have grown and changed. I want my staff to have a growth mentality, not a fixed view of themselves.
notacoward 10y ago
If somebody has been promoted multiple times in programming roles, and especially if they have a visible open-source corpus (not necessarily GitHub BTW), then you know they can code. Making them do it in a highly artificial environment is pointless at best. Other words like "insulting" and "demeaning" also come to mind. Asking people to reason about complexity is great, but that's not the way such interviews usually go. More often, the interviewer asks about complexity only so that they can compare to their own solution copied from the best of a hundred other candidates and then hand-tuned for days. It's a gigantic ego trip, and not even a fair fight. Candidates can see that, and it tells them a lot about what kind of person the interviewer is. Hint: it's not a pretty picture. I was fortunate to go through an interview process recently where I had to do coding interviews, and it wasn't just a big ego trip. Second time in thirty years, vs. dozens upon dozens (all passed) of the worse kind. I could tell the interviewers had actually been trained, because I've been on the other side of that desk. They didn't care about the code I wrote, so much as how I approached a new problem, dealt with edge cases, explained various decisions, responded to challenges, etc. That's how it should be, but doing this stuff right is hard. Very few who pretend to do it have invested the time to do it properly, so they get results that are worse than useless. That's why there's so much hatred of the approach. Most people have never seen this kind of interview done right, and it's not their fault that's the case. It's on people who went from copy-paste programming to copycat interviewing.
- noxToken 10y ago
  > If somebody has been promoted multiple times in programming roles...then you know they can code That's not necessarily true. There are people in "tenure" roles as I like to call them. They're not ostensibly bad, but they're far from good. They get promoted to senior developer and have pay raises each year. They're not bad enough to be let go, but after 5 years, they're still around and earn a senior title. They're not really in charge, but they're technically in charge with time at the company and the title. I'm not saying throw deep algo questions at them, but promotions don't mean coding chops.
  - notacoward 10y ago
    You do have to look at the role. If their role is to code, and they've been promoted recently, I stand by my claim. If they've moved into more of an "architecture" role or the promotion was more than a couple of years ago, then yeah, they might have lost it.
emidln 10y ago
I've had interviews where someone expected me to write "compiles and runs code" in languages such as Python, Java, and C. I've also had interviews where "solve the program on the whiteboard with any language you feel comfortable with" means "exactly Java 5/6/7" because that's what the interviewer happens to know best. I'm decent with a whiteboard. I routinely use one for brainstorming and discussing problems at work. I don't mind writing code on a whiteboard, even specific language code and including stupid shit like semicolons. I also understand that despite the fact that I can do it (and even enjoy it), it's a miserable experience for some people and expecting everyone to remember minor details that their editor/IDE takes care of for them isn't looking for the right thing.
silverbax88 10y ago
You'd better be looking for psuedocode, because if you're looking for syntax, no strong programmer with experience is going to take you seriously. Honestly, whiteboard interviews are for lightweight startups with very little programming knowledge. You should be looking at logic, not syntax. You should be looking at how the person thinks, not if they can memorize a specific language to do a simple task.
- toephu2 10y ago
  Have you ever interviewed at Google? They care about syntax, psuedocode will not cut it in the interviews... and Google has a lot of strong programmers.
  - tchaffee 10y ago
    Google has the name to attract strong programmers. I'd like to see stats on how few (or many) strong programmers their interview process misses. Especially when that interview process is used at a company without such a huge name.

ljlolel 10y ago

What about just asking the candidate to do the same simple task on a computer that they own?

chronicx0 10y ago
Lots of candidates cheat. Especially from China and India.
bobobjorn 10y ago
I have used both ways, and i would say the candidates in general respond better to using the whiteboard. I do ofcource not require syntacitly correct code or anything like that. Im looking for ideas not if they are a compiler. Using their own computer way to many struggle with creating a new project or other basic things. And that dont make them comfortable either. It also takes much longer then using the whiteboard.
pavel_lishin 10y ago
My office is a satellite of a larger one in Austin; we provide laptops for candidates to use for the "remote" part of the interview, when they interview with someone in Austin. But in general, I think the idea of the whiteboard interview is a chance to see someone "think out loud", to see them reason through a problem. Getting a chunk of source code in an email isn't representative of that. (At worst, they paid someone to do it for them; at best, you have no idea what their approach was. Somewhere in the middle is copying and pasting most of it from SO.)
- eddieroger 10y ago
  > But in general, I think the idea of the whiteboard interview is a chance to see someone "think out loud", to see them reason through a problem. This is exactly why I do this kind of stuff as well when interviewing. It's not about syntax or the ability to recall (regurgitate?) a function, but how does someone approach a problem and where can the conversation go from there. If you sent someone pre-work to write an array matcher, you'll see a final result, but not how they think through it, and you'll miss potential queues to further the conversation.
- deadbunny 10y ago
  > At worst, they paid someone to do it for them Which would easily come out at the interview when they fail to answer basic questions about their code. > at best, you have no idea what their approach was So? Did you get code that would pass a code review? Did you get code with good commits/history?
  - stale2002 10y ago
    Not really. It is much easier to talk about a solution, when the solution is right there in front of you, and you read an explanation of the solution online. Regurgitating someone else's solution is fairly easy.
- vonmoltke 10y ago
  > But in general, I think the idea of the whiteboard interview is a chance to see someone "think out loud", to see them reason through a problem. So thinking out loud while coding is a job requirement now? I have been an engineer for over 14 years, and a software engineer for 10, and I can count on one hand the number of times I have done that outside of an interview. I collaborate all the time, but almost never synchronously while actually writing code.
  - dtech 10y ago
    Reasoning about problems is a very essential job requirement. And doing that out loud is the one of the few ways people can see how/if you do that.

rimliu 10y ago

So you test their ability to write code on the whiteboard. I was once programming with pen and paper too (only had access to computers at university). They I bought my own computer.

drdaeman 10y ago
Don't know why this comment is downvoted, because he has a point. Writing actual code on whiteboard is different, unless it's pseudocode without any syntax rules and standard libraries. I'm not a newbie (like, 15 years coding). But I haven't even bothered to properly remember standard libraries peculiarities - since they're different across the languages anyway, and with modern software stacks (that are quite diverse) it's not unusual to write Python but do some C or C++ one day (speed-ups), detour to JavaScript, try out Elm, then have a day patching some Go code that an useful tool is written in, then go learning some Elixir. Is it strpos(substring, string) or strpos(string, substring)? What does base64.encode(blob) returns, again, ASCII bytes blob or a text string? Which module/header file contains/exports that symbol? Maybe I'm doing it all wrong but I honestly never remember such details that for longer than a week or another - a proper tooling always hints those kind of things to me, so I don't even recognize I tend to forget them. On a whiteboard, I'd have some awkward moments.
- crush_xc 10y ago
  Why does everyone assume that you're asked to write perfect code on a whiteboard? I've been through 15+ interviews and have never been asked to worry about method names being right or signatures of methods being perfect and such. Most of the time people are amicably against me worrying about it. This isn't an issue.
  - mikulas_florek 10y ago
    Exactly! When I was hiring I was even asking question I did not know answers to (not as a canditate, but as an interviewer).
  - kirkdouglas 10y ago

tyingq 10y ago

I suspect the backlash is mostly because an interview is already stressful. Then, when you ask someone to code with a marker, all of the muscle memory associated with how they usually code is gone...adding to the stress. You may be missing out on good candidates that just don't "whiteboard well". Of course, some interviewers are better than others, and can manage to do things to make it a reasonable experience. You outlined some of the things that you do that make it seem like you're in that camp. I'm not sure there's any one-size-fits-all interview technique that is universally better than others. The homework approach seems popular here, but then there are others that are put off by it. Probably the best thing is an interviewer that's smart enough to change gears when they sense the approach isn't really testing the candidate's skill.

tluyben2 10y ago

> What's with all the whiteboard backlash? As always, some companies spoil it for the rest; whiteboards are fine but the crazy Hackerrank kind of interviewing, coding, on a whiteboard, correct algo's you studied in uni 10+ years ago and so on got a lot of people annoyed. Nothing wrong with having someone sketch an architecture or a brief plan-of-attack on a whiteboard. But demanding someone to write a correct Bailey–Borwein–Plouffe implementation (I read a few months ago someone got that question in an interview; find the nth digit of PI efficiently as you can. How useless.) or something from their brain without a computer is just rather insane imho. Seeing if they can write code would be actually writing code. Behind a laptop with access to internet and time to do it. Also; previous work.

partycoder 10y ago
There is a legal framework for interviews (e.g: EEO). Probably they didn't like the candidate and they dismissed that person through a question they weren't expected to answer.
- tluyben2 10y ago
  What does that entail? I thought the US was not as strict on law for workers / interviews.
  - partycoder 10y ago
    Dismissing someone using an objective/concrete criteria such as a failed programming test is not problematic. On the other hand, if you dismiss someone because "is not a cultural fit" or some other subjective reason, the person can sue you, accuse you of discrimination and challenge you to prove your point over a legal mine field.
    - lostcolony 10y ago
      Most companies avoid that by not giving candidates a reason why they were not hired.

onion2k 10y ago

I think the primary problem with this sort of interview process is that most companies don't hire enough people to discover whether or not it actually works, plus an interview is so much of a multivariate problem that you'll never really know which part of the process is broken if a bad hire gets though. And that's compounded by the fact any false negatives (great candidates who would have fitted in but got rejected) are clearly never going to be discovered. The problem I have with whiteboard coding in interviews is that there just seems to be better alternatives. Using a computer as other people have suggested, but also just talking to them you can figure out if someone knows how to code. If you ask someone how they'd check if a number is in two arrays you can immediately tell a developer from a non-developer (or an inexperienced developer) by the language they use and the questions they ask. If they mention loops then that's a bad sign. If they start talking about whether or not the arrays are sorted, how big they are, whether you could refactor the array building code to return the data as a object index instead ... then it's clear that the person knows how to code simple things, and all without needing to pick up a marker pen.

runako 10y ago
> If they start talking about whether or not the arrays are sorted, how big they are, whether you could refactor the array building code to return the data as a object index instead ... then it's clear that the person knows how to code simple things, and all without needing to pick up a marker pen Having worked with people like this, I have to call BS. There are a lot of people with the distinct skill of being able to effectively imitate the speech patterns of actual programmers. Asking questions, engaging in productive discussion, etc. But when faced with an empty editor, they simply cannot produce working code. If you're already talking about coding a really simple problem like your array example, why not let them use a computer language to express a solution? After those 5 minutes, you can move on to richer parts of the interview confident that you're (probably) not going to hire a total bozo.
- vonmoltke 10y ago
  > Having worked with people like this, I have to call BS. There are a lot of people with the distinct skill of being able to effectively imitate the speech patterns of actual programmers. Asking questions, engaging in productive discussion, etc. But when faced with an empty editor, they simply cannot produce working code. Having never worked with anyone like that, I will have to call BS on this because it is simply too hard to believe, without evidence, that someone can understand this level of detail and not know how to create working code. A parrot cannot engage in productive discussion, and aping speech patterns only goes so far. Plus, if they're so good at aping speech patterns, who says they aren't equally good at aping code patterns?

discordianfish 10y ago

It simply selects for people who can write a simple code unaided in an interview situation while somebody is watching every letter you type. Many people don't have a problem with that, others have.

ealexhudson 10y ago
I'm not sure that's true (in terms of explaining the backlash against whiteboarding specifically). From the page: "The companies and teams listed here instead use interview techniques and questions that resemble day-to-day work – for example pairing on a real world problems" I would contend that if you're doing pair programming with a candidate, you're looking at people writing code in an interview situation while somebody is watching every letter you type. In fact, I think hacking on actual code is worse than whiteboarding: everyone knows how to use a pen and board, but don't do so frequently. Different candidates being placed in front of the same computer and IDE, however, may be vastly more comfortable or not - they may know the bindings, etc. If they're not the "driver" in the pair, they still have to grok the codebase and the problem quickly. Whiteboards may be abstract, and people may focus too much on algorithms with them. I don't think that there is much fundamentally different about pairing, and I would have more reservations with pairing personally.

ciqsteve 10y ago

Whiteboarding itself is a skill. What I learned the hard way: - There is no insert. If you need to go back and insert a line of code somewhere you must either erase all the code below it to make room (then rewrite said code), or you draw a line from the insertion point to somewhere else on the white board and write the code there. For the former you waste a lot of time. For the later the code quickly becomes hard to follow. - There is no context driven autocomplete or quick method lookup. If you spend your entire day coding in one language and have done so for the last >3 years you should be fine. If you code in multiple languages and spend time with other tasks (devops for example), you might not realize how much you rely on this. - The white-boarding process works well (given previous two caveats) if you code in a linear style. If you code iteratively the whiteboard is not your friend. My recommendation to someone starting the interview process. Go buy a small whiteboard and use it to code solutions to interview questions you find online.

whazor 10y ago
I am assuming that you can use pseudocode
- sterex 10y ago
  Exactly! The above comment assumes that a linter will be run against the core on the white board. Jeez.
ryandrake 10y ago
All your points are good--and they are part of the overall problem with whiteboard coding: A whiteboard is not even close to a realistic modern development environment. How many times, for your job, have you had to code up a solution to a problem, even a trivial one: 1. Just given to you 5 seconds ago 2. With no access to documentation (paper, textbooks, offline or online resources) 3. With no access to mentors or colleagues 4. With an editor crippled as you described 5. Have to get it right within minutes? 6. And then have to defend your code against someone who's had plenty of time to think about the problem. I can tell you, throughout my programming career, the answer is "never".

FLUX-YOU 10y ago

>If they can't write some simple code unaided, then I don't want to work with them. I was a copy-paste programmer once too. Lovely. Someone put up with you, but now you won't do the same and offer to teach.

flavor8 10y ago
If you want to learn on the job and are happy to accept an intern's salary, that's great. Most organizations will be able to accomodate you. If you want $140k and can't code productively, most early startups won't want you. Larger organizations may be able to accomodate you. There are a shocking number of candidates who apply to senior positions who flat out cannot code. I have hired in the past without doing the whiteboard exercise and been burned by this; never again. The whiteboard is a filter to eliminate people who misrepresent their abilities.
- FLUX-YOU 10y ago
  >I have hired in the past without doing the whiteboard exercise and been burned by this; never again. You should consider offering multiple technical tests and letting the candidate choose. Ideally the choices would range from whiteboard, take-home project, quiz site (hackerrank), or pair coding.
icebraining 10y ago
Or maybe ninjakeyboard skilled up before applying for a job.

StringEpsilon 10y ago

We do technical interviews on conceptual levels. One manager, one HR, one programmer (not always all three at the same time) and the interviewee. We ask them about their experience with the tech we use / plan to use and test what they tell us with specific questions. If you tell us you know ASP.NET, I might ask you to describe the default routing or some specifics about razor views. If you tell me you are a git expert, I might ask you about interactive rebases and cherry-picking to find out when and how you'd use them. General know-how is usually more viable than the ability to write working code in a pinch. The closest thing to a whiteboard test we have is giving you a page of code to ask you what's wrong with it (although, we don't do that often).

sgdread 10y ago

I've got pretty complicated exercises in whiteboarding sessions: some problems with graphs or dynamic programming. The way how I solve those in my daily work is totally different to the way I go in 45 min whiteboard interviews: in 45 min you always have to do it in top-down manner, otherwise you will fail by writing non-relevant parts of the code and running out of time. I usually prefer opposite: bottom-up approach. It's a skill. Very artificial and very dumb to my opinion since you never work this way, but interview supposed to test how you do you work.

at-fates-hands 10y ago

>> What's with all the whiteboard backlash? Here's the deal. As a developer, I have about 30 repos out on GitHub with plenty of examples I've done in the last three years. If you want to interview me, then go look at my code first. I have a pretty specific style so all the code is consistent. Go look at my code, dissect it, ask me questions about it, ask me why did this instead of that, why I prefer some library over another one, etc. If you feel like my skill set is what you're looking for, then bring me in and then we can see if we're a good fit for each other. If you don't like what you see, then don't bring me in - it's really that easy. Having one or two whiteboard examples will never, ever, show someone the depth of your skill set. You have to look at their code, which will give you insights a whiteboard interview never will. All the things you mentioned about "basic skills" are obvious when you look at someone's code. Did they use classic or prototypal inheritance? Did they know what closures are? Did they use a factory pattern? Are they using ES6 yet? What tools are they using for their projects? All this and a ton more simply from looking at their code. And if you're a developer, you should have an account on codeplex, or github, or bitbucket where interviewers can go look at what you're working on and the stuff you're building. It completely cuts out the "coding" part of the interview and should simplify the whole process.

snissn 10y ago
A business wants to hire you to solve business problems. Coding is the manifestation of the solutions. To me the white board session is to understand if you can take new problems and understand them enough to sketch out a solution. As a hiring manager, I'm glad you've written code before, I want to understand on a day to day basis if you can transform business problems into solutions.
- lostboys67 10y ago
  exactly the code is just a means to an end ie solving a real world problem
- logfromblammo 10y ago
  At most of the companies I have worked for, the difficult part of my job is taking the pre-existing code that barely works under the old internal proprietary framework and rehabilitating it into the new internal proprietary framework with a bare minimum of new development. Showing off that I know how to write (or recognize and copy) good code from scratch does not signal for that. I can't tell you how many times I have had to code something that is objectively incorrect because the old version did it that way, and the customer doesn't want the new version to be different. The problem with the whiteboard interview is that you can't show an old, crufty code base on it, and ask the candidate to sketch out how to implement a simple feature request without overhauling the whole thing to use industry best practices. And you can't show an existing relational database schema that is pathetically ill-designed and ask about a new report for the customer. Those are the sorts of problems businesses have. They don't suck it up and pay the big bucks for a software pro until after the amateurs have already tried fixing it with an Excel spreadsheet or an Access database. And they don't want you to mess up the solution they already have, no matter how much baling wire and duct tape is holding it together. Not everyone that can write code can also work well within an existing codebase. The only situation in the wild that I would trust to indicate that skill for my company is someone who actively contributes to an open-source project with a lot of other active contributors. A one-person side project that shows off everything you can do all by yourself won't reassure me. In fact, if it's too good, I might be worried that you will want to overhaul working code just because it's really, really ugly, and you can detect multiple code smells when you look at it.

lhnz 10y ago

Part of this is that a lot of interview practices (including whiteboarding) exclude people that suffer from social anxiety. Just because somebody freezes up when being watched and critiqued by an Evaluator, doesn't mean that they are 'copy-and-paste programmers'. There are probably a lot of extremely good engineers who find this style of interview difficult. People that call 'whiteboarding' a skill don't really get it. If you have irrational fear over people's judgements and this manifests when you're being interviewed, you can't merely expose yourself to this fear often to lessen it. It is very difficult to change how your mind and body react to uncomfortable situations. Of course, you need to test ability, but you should also accommodate people's preferences on the environment that they are evaluated in. You can negotiate whatever this is by speaking to them: they might have a Github with projects which they can discuss with you, or they might be happy to do a small project, etc. You need to keep your standards high, while also ensuring that they feel that they are able to do their best.

ninjakeyboard 10y ago
"People that call 'whiteboarding' a skill don't really get it. If you have irrational fear over people's judgements and this manifests when you're being interviewed, you can't merely expose yourself to this fear often to lessen it. It is very difficult to change how your mind and body react to uncomfortable situations. " I disagree on a few levels. I can't back anything with data but I'll point to where you can find many people who will offer their anecdotal stories of desensitizing themselves. Being able to talk and interact with people is a part of the role. Software is not written in isolation - it is done best with a lot of collaboration and critical review of work. Being able to communicate and give and receive critical feedback are cornerstone traits. Good code is not written in isolation and giving and receiving critical feedback is not comfortable. If I interview for those traits and qualities, I hope that I'm not discriminating against social anxiety but I spent 5 years in toastmaster's throwing myself in uncomfortable situations until I could come out of it. I feel like interviewing is becoming this PC thing where we try to form to evaluate people in the way that is comfortable for them, where we live in a world where people need to break out of their comfort zone and learn to shape themselves into their environments. Go to Toastmasters, speak in front of people, keep going and you'll improve your skills - yes the soft ones too. You'll become comfortable - you will - ask anyone who stands and speaks confidently in front of you in those rooms if they were always that calm and composed while speaking in front of people. They were not and they learned to speak 'off the cuff' on topics they were not prepared for or subjects they didn't expect in there. Maybe I'm alone in my thoughts but I'm looking for people who will grow. I want someone who will stand strong if I give them a critical code review - I want someone who will hang their ego at the door and be able to talk about what we're working on objectively. If I'm still coming off too hard on this, what if I say that it's a consulting company that I'm hiring for and that the staff will be in front of customers who will interview and drill them every day? Ultimately, we can grow and change. I know we can because I have grown and changed. I want my staff to have a growth mentality, not a fixed view of themselves.

notacoward 10y ago

If somebody has been promoted multiple times in programming roles, and especially if they have a visible open-source corpus (not necessarily GitHub BTW), then you know they can code. Making them do it in a highly artificial environment is pointless at best. Other words like "insulting" and "demeaning" also come to mind. Asking people to reason about complexity is great, but that's not the way such interviews usually go. More often, the interviewer asks about complexity only so that they can compare to their own solution copied from the best of a hundred other candidates and then hand-tuned for days. It's a gigantic ego trip, and not even a fair fight. Candidates can see that, and it tells them a lot about what kind of person the interviewer is. Hint: it's not a pretty picture. I was fortunate to go through an interview process recently where I had to do coding interviews, and it wasn't just a big ego trip. Second time in thirty years, vs. dozens upon dozens (all passed) of the worse kind. I could tell the interviewers had actually been trained, because I've been on the other side of that desk. They didn't care about the code I wrote, so much as how I approached a new problem, dealt with edge cases, explained various decisions, responded to challenges, etc. That's how it should be, but doing this stuff right is hard. Very few who pretend to do it have invested the time to do it properly, so they get results that are worse than useless. That's why there's so much hatred of the approach. Most people have never seen this kind of interview done right, and it's not their fault that's the case. It's on people who went from copy-paste programming to copycat interviewing.

noxToken 10y ago
> If somebody has been promoted multiple times in programming roles...then you know they can code That's not necessarily true. There are people in "tenure" roles as I like to call them. They're not ostensibly bad, but they're far from good. They get promoted to senior developer and have pay raises each year. They're not bad enough to be let go, but after 5 years, they're still around and earn a senior title. They're not really in charge, but they're technically in charge with time at the company and the title. I'm not saying throw deep algo questions at them, but promotions don't mean coding chops.
- notacoward 10y ago
  You do have to look at the role. If their role is to code, and they've been promoted recently, I stand by my claim. If they've moved into more of an "architecture" role or the promotion was more than a couple of years ago, then yeah, they might have lost it.

emidln 10y ago

I've had interviews where someone expected me to write "compiles and runs code" in languages such as Python, Java, and C. I've also had interviews where "solve the program on the whiteboard with any language you feel comfortable with" means "exactly Java 5/6/7" because that's what the interviewer happens to know best. I'm decent with a whiteboard. I routinely use one for brainstorming and discussing problems at work. I don't mind writing code on a whiteboard, even specific language code and including stupid shit like semicolons. I also understand that despite the fact that I can do it (and even enjoy it), it's a miserable experience for some people and expecting everyone to remember minor details that their editor/IDE takes care of for them isn't looking for the right thing.

silverbax88 10y ago

You'd better be looking for psuedocode, because if you're looking for syntax, no strong programmer with experience is going to take you seriously. Honestly, whiteboard interviews are for lightweight startups with very little programming knowledge. You should be looking at logic, not syntax. You should be looking at how the person thinks, not if they can memorize a specific language to do a simple task.

toephu2 10y ago
Have you ever interviewed at Google? They care about syntax, psuedocode will not cut it in the interviews... and Google has a lot of strong programmers.
- tchaffee 10y ago
  Google has the name to attract strong programmers. I'd like to see stats on how few (or many) strong programmers their interview process misses. Especially when that interview process is used at a company without such a huge name.