46 ms·

Engineering whiteboard interviews: yay or nay?

• bradenb 8y ago
  VP of Engineering at Eaze, previously CTO at Getable and engineer at Yammer. No, not at all. Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. Engineers on my team never have to code on a whiteboard (whiteboards are really bad at running code), why would I make candidates do something that I don't ask the engineers already on my team to do? This comes close, but I think the real issue that most of these reasons aren't hitting on is that software development is typically done asynchronously. Whether it's a whiteboard or a computer connected to a projector or TV or a live peer coding session it doesn't matter: if done in the interview, it puts the candidate on the spot in a way that they rarely (if ever) will be on the job. Developers typically are able to take time by themselves or with trusted/known colleagues to solve a problem. There are very few opportunities to get over performance anxiety related to coding in front of others that we don't know.
  • pavel_lishin 8y ago
    Minor kvetch: quoting the way you did it makes long lines very difficult to read. I usually quote like this: > I am a quote This makes the quotation doubly-distinct, and still readable on mobile devices. === To the actual point I wanted to make: plenty of engineers at companies code on a whiteboard. They schedule a meeting, grab a room, and talk things out, while making notes, diagrams and sometimes even actually writing out some code on a whiteboard. I hope nobody asks people to write compilable code on a whiteboard, but asking a person to talk through a problem and jot down some pseudocode doesn't seem like an awful thing to me. Communication is a pretty critical part of our job.
    • pmiller2 8y ago
      “Jotting down some code on a whiteboard” with a colleague is a much lower stress scenario than deriving and writing down, under a time limit, some DP algorithm you might not have used since college, and proving its correctness and run time to some stranger who may be barely out of college themselves.
      • recursive 8y ago
        Interviews are necessarily more stressful than typical work. That's not just a property of whiteboard coding.
        • pmiller2 8y ago
          More stressful, sure. For many people, whiteboard coding is disproportionately more stressful than typical work, and that’s the problem.
          • lfowles 8y ago
            One particular expectation when whiteboard coding for an interview is that there is little/no downtime, you must be making progress or talking about your thoughts. Incidentally, 50% of my thought process then becomes "How do I talk about what I'm thinking about? Oh no, I'm only thinking about talking about what I'm thinking about..."
            • ubernostrum 8y ago
              I'm working on a large-ish project right now, and into one of the more tricky bits literally today. And you know what? I take breaks. I go read something on the internet or post a comment, or I go for a walk, or I go do one of the smaller housekeeping tickets I keep in my queue to give my brain a rest from continually focusing on the hard parts of the problem. Can't do that in a whiteboard session.
              • hackits 8y ago
                Most of the time their technology stack with be vastly different than anything else you've worked with. There will be other people you will need to discuss and coordinate with. Articulating your thoughts and expressing yourself clearly and concisely is more important. Vast majority of the technical problems have been solved and its delivery a solution to a business problem that is the most important aspect.
            • 8y ago
    • ubernostrum 8y ago
      "Whiteboard interview" typically does not mean "sketch a general design of a system", or the other things whiteboards get actually used for on the job. It means "here's an algorithm challenge, solve it by writing the code on the whiteboard, and we'll flunk you if you make any mistakes". Not always a whiteboard, either; one of the best engineers I ever knew flunked a Google interview because of a situation where he had to write a bash script and read it over the phone to the interviewer, who apparently didn't transcribe it correctly on the other end. But "they only hire the best", you know, and their practices are rock-solid and proven.
      • lfowles 8y ago
        Oof, I've had that experience during a technical phone screen with a different "hires only the best" company. I was asked to write (over the phone) a trivial statistical algorithm and started to describe the algorithm: "Function F returns a double and has two parameters, pointer to the start of the double array P and integer N for length of array." Apparently on the other end of the line was a human compiler that kept rejecting my input and preferred "double F open parens double star P comma int n close parens"!
        • scarejunba 8y ago
          This is hilarious! Such a strong indicator that you, as a candidate, should reject the employer.
          • lfowles 8y ago
            Yes, it was the final straw and led to me rejecting that industry as a whole :)
            • pavel_lishin 8y ago
              What are you doing now?
              • 8y ago
    • privacypoller 8y ago
      I don't doubt lots of companies do this, but I skeptical about the coding on a whiteboard. They talk in person, sketch out diagrams, highlight important aspects - why? because these things are all easier on a fluid analog medium like a whiteboard or piece of paper. Actual Code? Not a chance. Portability, Durability, Efficiency - It's the worst of all worlds.
    • BinaryIdiot 8y ago
      I've worked at quite a lot of companies. Many of us will, occasionally, grab a room / whiteboard to go over something but 99% of the time it's a sort of flow or UX type thing. I've _never_ seen someone, or have asked to participate in, some sort of whiteboard coding thing. Even with pseudo code. That just doesn't seem helpful to me, at all.
      • tluyben2 8y ago
        Agreed; when there is code talking, we share screen on a projector/flatscreen and do it that way. How is writing code on a whiteboard good for anyone? Cumbersome and not reusable.
    • bradenb 8y ago
      Thank you for the quote pointed. I will remember that for next time! As to you’re point, I think others have covered it well, but I will add my agreement that communicating in an environment where you are comfortable and familiar with the topics ahead of time and won’t have your career prospects put in the line is much easier. Some people like myself simply can’t prepare for an infinite number of possible whiteboard scenarios and look competent.
  • teachrdan 8y ago
    There's some logic to that. It's the one of the same reasons we have high stakes exams in school: to show what the individual can do under pressure. In an interview setting you can't simulate what it's like to be at the end of a high-intensity sprint, but you can ask the candidate to answer a tough question on a whiteboard and (ideally) get a notion of how they work when the going gets tough.
    • jriot 8y ago
      As a former air traffic controller and now data scientist, nothing in this career field is ever done under any real pressure.
      • dylanrw 8y ago
        But what about that one time on Swordfish!? /s
      • java-man 8y ago
        tremendous respect to air traffic controllers. i cannot imagine the level of professionalism and responsibility these people must have! no amount of monetary compensation is enough, in my opinion.
        • jriot 8y ago
          Thanks. While everything you said is true, its also a hell of rush. Hardest part of changing careers ... no rush with a daily dose of dopamine.
    • romaniv 8y ago
      The pressure of a whiteboard interview has nothing in common with the pressure of a short deadline. It's like testing people for Tour de France by putting them on a unicycle.
      • ztjio 8y ago
        Now there's a prologue I'd actually watch.
  • toast0 8y ago
    I guess it depends on the job, but for outage response, being able to understand a problem, and update or write new code in a reasonable amount of time is kind of a useful skill. Discussing it on a board with others can be useful, if the code isn't complex. Of course, that also depends on the environment; if you're in an environment can't actually push any code, even emergency fixes, quickly, then it doesn't help a lot.
    • romaniv 8y ago
      Do you design clever search algorithms during outages?
      • toast0 8y ago
        If the existing search algorithm is the cause of the outage, maybe. If I a clever search algorithm will help me filter the data so I can reduce the scope of the outage, yes.
        • throwawayboye 8y ago
          Are there no existing tools to search through data?
          • toast0 8y ago
            Everything is already implemented, let's close the patent office.
  • remoteorbust 8y ago
    > Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams? I hate this concept that if it's not typing code into an editor then it's not "real work". I absolutely communicate with my coworkers using a whiteboard and pseudocode. I reject the idea that being put on the spot is necessarily "artificial". To the contrary, I think that the number of engineering jobs where you can assume you'll never be put on the spot or have to communicate complex ideas verbally or visually is relatively low. Now if this particular skill isn't interesting to an employer and they'd rather spend the time talking about some other candidate capability, that's a whole different story.
    • java-man 8y ago
      even then, this is not what's being tested with the whiteboard. thinking and presenting are two separate skills, and, in my opinion, can rarely be executed at the same time.
      • vymague 8y ago
        So if you're looking for someone who can execute both at the same time, whiteboard coding is ok?
        • swsieber 8y ago
          If your looking for someone who can think, code and present at the same time, yes.
      • deleted 8y ago
        [deleted]
    • jdc 8y ago
      The point is that the interview style in question overemphasizes on-the-spot responses. How is prowess in a game of "gotcha" an important indicator of engineering skill?
  • techwraith 8y ago
    VPE at Eaze here (the original author of the quote above) - You're 100% correct. We give our candidates the choice between working through a problem at the office (on the spot as you say) or doing a take home project asynchronously. Not everyone has the time to do homework, but not everyone wants to do an in person coding interview either. We try to stay flexible.
    • mattnewton 8y ago
      How do you compare the resulting apples & oranges? I can do a lot more at home (especially if I cheat on time, which everyone who really wants your job and can afford to do will do)
      • techwraith 8y ago
        We're less concerned with the resulting code than we are about your ability to explain the code that you wrote and your ability to prove to us that you have good judgement when making technical decisions. Also, we're growing fast enough that we're rarely comparing candidates. If we can hire both the apple and the orange (assuming both candidates are evaluated to be good for the role), we will.
        • loxias 8y ago
          I'm actively looking/interviewing and really like the "cut of your jib". (both your answers here, plenty of aspects of Eaze as a company, the prospect of moving back to SF...) For both the sr backend and devops positions, how important to the roles is familiarity/experience with your technical stack? I might have some of the skill set/experience you're looking for -- sr backend engineer, sr systems engineer, devops are all positions I've held -- but honestly I don't know JS, .NET, or Chef. Bluntly, I don't want to waste your (or my) time. ;) <tiny>Also, I wish HN supported private replies</>
          • techwraith 8y ago
            We care less about your particular technical skills than we do about your generalized engineering skills. Specific stacks are easy to teach; fundamentals, emotional intelligence, and social skills are harder to teach. In fact, if someone is too into their stack, we see that as a bad sign. So I'd be super excited if you decided to apply :)
  • mrep 8y ago
    Really? I have multiple in person discussions per week about how we are going to tackle some problem where everyone chips in and those are just the weekly problems we are working towards. There are also the much larger design docs and while some of the feedback on those happens asynchronously, a lot also happens in real time during meeting reviews. Oh, and both of those problems are decently well covered by your standard interviews (the former generally being data structure/algorithm design, the latter generally being system design).
  • sieabahlpark 8y ago
    When's the next 50% off sale?
  • ndesaulniers 8y ago
    A team I was on at Google (XLA, the compiler for TPUs) used whiteboards almost daily to express algorithms to each other. Definitely helpful for us, but I can see that just being a single team's dynamic. No comment on it being an effective interview process.
  • deleted 8y ago
    [deleted]
  • nitely 8y ago
    I've aced every whiteboarding interview when the problem was the same or similar to some problem I solved before, and I failed pretty much every interview when the problem was new to me (except when the problem was trivial, ala fizzbuzz). I think that proves how whiteboarding just tests whiteboarding skills and nothing else.
  • fatnoah 8y ago
    It's funny, when I saw the title I immediately thought "Hell yeah, whiteboard interviews are absolutely necessary". As I read the article, I realized it meant actually making people code on whiteboards, which is absurd. I've always used whiteboards for high level design and architecture questions, and there mostly to aid the candidate in organizing their thoughts. If I want to see someone's code, I'll ask them to provide a code sample.
• GenerocUsername 8y ago
  I actually really like whiteboarding problems and it is a common and effective real-world problem solving skill. I still only do OK at whiteboarding in interviews.
• expertentipp 8y ago
  Honestly I’m not afraid of whiteboards as earlier in the career. The interviever is whether some fresh graduate smartass trained in a narrow domain and it’s easy to route the discussion out of their comfort zone, or someone with particular problem - well, I’m not able to pull out immediately answers to the world problems and if this is the case I’ll just admit it. In the worse case I’ll not get hired - I hadn’t got hired too many times in my life to care.
• megaman22 8y ago
  Nay. I do not understand the obsession with whiteboards. I've had coworkers that went gaga when they discovered that whiteboard paint was a thing, and they could cover their office in whiteboard surface. Doodles and doodles and doodles all over the place, but not very much working code ever makes its way into production from those offices. Lots and lots of movement and noise and grandiose planning, signifying nothing, too often. Lock me in a dark closet under the stairs with just the glow from a couple LCDs and throw pizza and requirements documents through the slot, like you're feeding the Rancor. /s
• devy 8y ago
  Serious question, if whiteboard interview aren't the best or helpful at all, what are the successful/useful alternatives for engineering interviews?
  • romaniv 8y ago
    Letting candidates to do actual coding on a computer.
    • jonathankoren 8y ago
      Yeah, but that's also stupid. All to often it comes down to "Make standup a completly working client server system for this arbitrary problem from scratch in 30 minutes, starting... NOW!" You end up spending all your time dicking around with missed semicolons and looking up library routines and shit like that. Sure, it's all stuff you have to do as part of a job, but it's also all trivial stuff. The last time I had to do this, I spent time googling how to open up a port in python, and then read from stdin. It's just a waste of time. All this does is test the wrong things.
      • romaniv 8y ago
        Find a reasonably self-contained problem that doesn't involve too many interactions with the "environment". For example, ask the candidate to refactor an existing piece of code.
        • jonathankoren 8y ago
          Well the interviewee doesn't get to choose do they?
  • lfowles 8y ago
    My favorite interviews have been those that had a small project as a screener and then proceeded to have you modify and/or explain decisions regarding the project at the in-person stage.
  • 8y ago
• castlegloom 8y ago
  It seems like there are two things at play - whiteboarding interviews vs. using whiteboards in your day-to-day job. If the test is to see how well a person works in a whiteboarding interview to solve a problem, then it should be a simulation of collaboration, while trying to avoid the Clever Hans effect. Otherwise your DP whiteboarding problems are worthless.
• h4b4n3r0 8y ago
  Nay, unless the candidate wants the whiteboard. Even Google doesn't mandate whiteboard anymore: you can write your code on the provided Chromebook. Some people choose whiteboard, though, for reasons unknown. I think whiteboard (or a sheet of paper) is reasonable for what it gets used for IRL: for sketching out what you're going to do, by drawing or writing very high level description, but it sucks for everything else.
  • miah_ 8y ago
    I did a interview with Google last summer. They didn't use a whiteboard, but instead had me code in a shared GoogleDoc. Pretty similar issue, limited time, somebody staring over your shoulder, not your usual development environment. Even more frustrating when you _know_ they have a web-based IDE for internal software development but make you write code in a GoogleDoc.
    • stevenwoo 8y ago
      I did one about ten years ago, two of the guys asked me to do the program on legal pads, two on a whiteboard, it was kind of funny because the Google HR person gave out a pdf explaining they were going to use a whiteboard and to practice on a whiteboard before coming on site.
    • h4b4n3r0 8y ago
      With doc you don’t have to stare over the candidate’s shoulder. The interviewer can just share the doc with him/herself and watch as you type. That’s what I used to do. The main goal is actually to make sure the candidate stays on the right track. Some folks are prone to veering way out into the woods otherwise. Unsupervised, they would just run out of time.
    • cableshaft 8y ago
      Was that an on-site interview or a technical interview over the phone? I did an interview at Google about 7 years ago and that sounds like the Technical Interview. When they brought me on-site after that, I interviewed face to face with 5 or 6 people in a row (except for a lunch break), and every one of them asked me a two or three questions and then switched to tricky whiteboard problems. I remember one was 'write a function that draws a 2D skyline from a bunch of 3D buildings', which I got totally stuck on because there's so many possible configurations of heights and widths and how they overlap that complicates it, so I didn't really know how to properly solve it. I didn't get the job. I thought the experience was interesting at the time, and basically treated it as a free tour of Google and a chance to eat In and Out burger again, but I don't want to go through that grueling exercise again (or spend a ridiculous amount of time prepping for it... as it was I spent a solid two weeks studying for it the first time around), so I've said no to Google recruiters every time they've gotten in touch with me since. I might have given it one more shot, though, if I were willing to move to Silicon Valley at this point in my life, but I just bought a pretty decent house and I'm not really wanting to give that up to take out a mortgage five times what I have here just to live in a smaller house in the Valley and be able to say I worked at Google.
• wolco 8y ago
  I may be an outliner but I prefer them. Mixing presenting with randomly writing things is better than talking for an hour. Makes me less nervous doing two things at once.
• a-dub 8y ago
  Whiteboard interviews would be fine if they weren't taken so damn literally. Writing code on the board is dumb. Spitballing solutions to a problem collaboratively and with access to reference resources (a nice little programmer's bookshelf in the room) followed by actually coding a little bit up seems that it would be way less stressful and way more likely to give you a sense as to what someone is capable of and what they're like to work with.
• denzil_correa 8y ago
  In general, an interview is to understand what a candidate brings to the table. Therefore, one of the best ways to assess "glass half full" is to talk about their past work. The interviewer is a subject matter expert who can definitely ask pertinent questions about the candidate's work. In many cases, more so for scientific positions - the candidate's work is publicly available. Currently, many interviewers go for - as I like to call it -"trivia questions". Personally, it just doesn't seem appropriate because "Everything may be obvious, once you know the answer". In some such interviews, I've asked my own set of trivia questions to the interviewers. The interviewers weren't pleased as they couldn't answer some questions for which I knew the answers beforehand.
  • haeffin 8y ago
    Unfortunately, some companies' HR departments actively encourage "trivia questions", because they ask interviewers to ask every candidate the same questions so that a "fair" comparison between candidates.
    • KhanMahGretsch 8y ago
      I think you've touched on a crucial point here about making the comparison "fair". In my view, I find the "trivia questions" approach to be an abdication of responsibility for the difficult, nebulous task of assessing a candidate's abilities. It gives you an objective measure by which to compare candidates... even though the measure itself is usually arbitrary and irrelevant.
  • mmt 8y ago
    The only "trivia" questions I like are ones that don't necessarily have a single "correct" answer (i.e. not "guess what I'm thinking") and can actually lead to further discussion. For example, one I like to ask (in person, with no computer access), ostensibly to gauge familiarity/intimacy with the Unix CLI, is: "For each letter of the alphabet, see if you can name a Unix command (anything one can type at a shell prompt that won't return a "command not found error") that starts with that letter." I preface the question with something suggesting that it's supposed to be fun, and I encourage skipping letters and coming back to them to avoid pressure (nor do I write down the answers). Most people are surprised at how many they remember without much thought. Although not particularly deep, further discussions can arise from differences between shells with respect to built-in commands, as well as differences between OS flavors. Also, I've discussed how a somewhat new language like Java has made one of the otherwise difficult letters much easier. Regardless of the trivial nature of the question/exercise, it provides a spectrum of jumping-off points for deeper knowledge discussions, all of which are signaled/chosen by the candidate.
• bhb603 8y ago
  > "Whiteboarding" has become too large of an umbrella term, one that groups together everything that's wrong with the interview process. That general premise is right, we've lumped too much into the term "whiteboarding", and it's worth unpacking into the different interviewing practices we may like or dislike. Some things people don't like have nothing to do with an actual whiteboard (e.g. testing esoteric CS knowledge or deliberately creating a stressful environments), and some things that involve a whiteboard IMO are ok (e.g. sketching out a system diagram).
  • alkonaut 8y ago
    Yes. The whiteboarding that gets hate is effectively the one where you would be asked to write a depth first traversal or similar, in some verbose language, correctly. On a whiteboard. That is STILL a thing (judging by HN) and it's useless. I don't think anyone would ever think it's a bad idea to have a whiteboard on hand if a candidate is asked to describe how they would design some nontrivial system. Being asked to describe something without a whiteboard in that case, is even harder. The objection you often get for the latter kind is that it tends to benefit the extroverted kind that likes to babble and sketch, whereas a candidate who would prefer ten minutes alone with a pen and paper might not do so well. I think are some merits to that complaint, but I also know from experience that being able to babble and sketch is really important.
• renegadesensei 8y ago
  They're fine but they need to be understood properly. Whiteboard interviews don't really capture how well someone codes. They are better at capturing thought process, high level understanding, system architecting ability, and a candidate's communication skills. If you want to see how well someone codes, look at their code. Or ask them to write something for you. Don't do a whiteboard interview and think it is the end all be all. Take it as a data point.
  • ordinaryperson 8y ago
    > They are better at capturing thought process, high level understanding, system architecting ability, and a candidate's communication skills. If that were the case, ask me about a past problem and my solution and to defend it, not the proper way to invert a b-tree.
• romille 8y ago
  To me, it's not about the code on a whiteboard vs a computer and correctness. It's about the thought process when breaking down a problem and the ability to organize and communicate their thoughts. It's also about exploring a problem space. How carefully does an engineer consider edge cases? What kinds of things are important to them? A whiteboard to me is a much simpler and accessible medium through which to explore a problem vs setting up an environment and having to type code and dealing with all the minutiae that comes with actual development. Of course, it isn't the ultimate method of evaluating a candidate but it's certainly valuable.
  • java-man 8y ago
    I think it's important to measure what's actually relevant to the job. If the job entails large periods of coding on the whiteboard, then yes, it's a perfect metric. If, however, the job requires careful consideration of dependencies, time domain, and, yes, edge cases - then you are NOT testing for that. Lock the candidate in a room and give a few hours to let her to produce the result would be a better measurement.
    • UncleMeat 8y ago
      When I do whiteboard interviews I want a little bit of code because I'm stunned by the number of people who can't write a loop. But mostly I want to see the design process. I ask for a simplified version of a real feature that has an algorithmic core. This lets us code something but lets us discuss all sorts of edge cases and real world complexities that would come up in a true deployment. Lots of interviewers suck. That isn't a property of whiteboard interviews.
      • java-man 8y ago
        so let's discuss the edge cases. let's operate with abstract concepts rather than actually write code.
      • spike021 8y ago
        >I'm stunned by the number of people who can't write a loop I won't say this is you, but it's funny the number of people who will interview and say something like this and then still give a non-trivial problem/question to whiteboard. Reminds me of a guy who interviewed me several months ago at a place in Mountain View (not Google, but another). He started by asking me to create an object with a couple attributes. Then he slowly began to add to the problem by asking for X, then Y, then Z. Little by little, the code became more complex because he wanted iteration, etc. He would say "I just want to know that you're able to code." Later on, I found out he didn't like what I wrote, meanwhile all the basic elements of coding he wanted I was able to add without any problems and I met his specs. If there's a "communication issue" in whiteboarding, perhaps the interviewees shouldn't shoulder all of the blame. Perhaps the interviewers need to temper their expectations and learn to communicate them better, because obviously there is some disconnect in a situation like this, and it's not the first time I've seen this before.
• Will_Parker 8y ago
  Is there any engineer who you'd regret not hiring, who is unable to code FizzBuzz in real time in front of an audience? I'm skeptical.
  • jonathankoren 8y ago
    I've seen a respected engineer that I worked with for years, be told by an outsider that he was incompetent because he couldn't fizzbuzz an interview. Yet, they had no problem acquiring the project he designed and wrote. So yeah.
    • dvirsky 8y ago
      Why couldn't he do fizzbuzz?
      • anonytrary 8y ago
        "Why couldn't he do fizzbuzz with someone else watching his every move while he wrote on a blackboard with no interpreter to test his solution or catch his mistakes?" seems like the better question.
        • vultour 8y ago
          You're assuming quite a lot here. Was he not able to write flawless code without syntax errors, or did he struggle with the core idea of FizzBuzz?
  • readittwice 8y ago
    You certainly have a point. But those whiteboard interviews people complain about are usually a bit harder than just solving FizzBuzz.
• curtis 8y ago
  Many people believe that it is completely unreasonable to ask an interviewee to write code on a whiteboard at all. I disagree with such an absolute position. I do think it can be a reasonable thing to do, but only if you are asking the interviewee to code something really simple. When I say simple, I mean really simple, like FizzBuzz simple. There are interesting questions you can ask that are really simple which are not FizzBuzz. I've used the Fisher-Yates shuffle algorithm and more recently Selection Sort. I should stress in both of these cases that I carefully explained the algorithm before asking the interviewee to code it up. Even though these algorithms are quite simple, I do not expect the interviewee to have memorized them. I do expect someone who is a professional software engineer to understand the algorithms after a decent explanation and then write code which will implement them. I also don't necessarily expect the interviewee to get the code exactly right. I just expect them to demonstrate that they could write correct code given enough time and access to an actual computer to test the code on.
  • BinaryIdiot 8y ago
    If you're looking for them to do something _really simple_, like FizzBuzz, then you're doing it wrong already. This is something that could have taken place over a technical phone screening. Once they hit the on site interview it should be more about how they can work together with a team, how they would design systems, what they would do if they needed help, etc. Coding up FizzBuzz on-site is a waste of everyone's time.
    • curtis 8y ago
      We're a small startup, and we don't have a really structured process. Also I have been the only person asking a detailed coding question (in consultation with my boss). Everybody else on the team has been responsible for those other questions. I should also add that I personally prefer to do coding questions in person on a whiteboard, rather than doing them during a phone screen with some sort of collaboration software. My technique of explaining the algorithm before asking the interviewee to implement it works way better with both people in front of a whiteboard. I'm not saying everybody should do it this way. I'm just saying that this is my current approach and it seems like it's working OK.
• solidist 8y ago
  The meta of how on whiteboard interviews. https://medium.freecodecamp.org/how-to-organize-your-thoughts-on-the-whiteboard-and-crush-your-technical-interview-b668de4e6941 https://medium.freecodecamp.org/how-to-organize-your-thought... Just embrace it. It will be okay.
• ngngngng 8y ago
  My most recent interview involved a coding assignment, which I topically don't do, but this one was a very interesting challenge that would make a good blog post afterwards so I did it. What was surprising is the interview not only included going over my code from the assignment, but also whiteboard problems about recursion. I've still never used recursion in my day job. Can interviewers really not gauge technical ability from my GitHub as well as chatting about problems and solutions?
  • jarsin 8y ago
    Interviewer: I see you have built an app just like ours five years ago. That's great. OK now let's get to the important stuff. How many cakes can you steal from the queen if your duflle bag hold 5 pounds and there are 10 different kinds of cakes? True story.
  • crsv 8y ago
    You have a software engineering job and you never used recursion of any kind? This strikes me as super odd.
    • vesrah 8y ago
      They might generally use a library that handles a lot of common usages for recursion, like traversing a tree for whatever reason. A question I've had in an interview was what is the difference between recursion and iteration. Fairly easy to explain, including examples of usage.
    • dpiers 8y ago
      I can only think of a couple occasions in my professional career where recursion made more sense than iteration. Both involved traversing trees with unknown depths (parsing XML and scanning a file system). That hasn't stopped it from showing up in every programming interview I've ever done.
    • redisman 8y ago
      I haven't really used it for anything other than super simple things with a very tightly bound max input. Stack overflow and honestly many recursive algorithms are quite hard to parse in your head especially once you add some edge cases and some other entropy.
• privacypoller 8y ago
  All of these interviewing "tools" (or tricks) attempt to be time/cost efficient proxies for doing the damn job, and they all suck. * Whiteboard coding is awesome for software development shops that don't actually own computers or use punch cards to load programs. * Shared coding environments with a time limit works well when you want to double screen for someone who can also diffuse suspicious packages that arrive at the office * Riddles and puzzles are good when your workplace has a chicken coop, an office fox and you can't figure out how everyone can go for lunch without leaving the fox alone. * Behavioral interviews are appreciated by candidates who took Psychology 100 back in school for an easy A. * Take-home tests go over well with the huge population of talented software developers who can't find a job and have loads of time they want to spend decoding the operational cost of a bubble sort The only thing I've seen that's at all realistic and effective is a very short, __paid__ project. I did a two-day one for Indeed (ironically one of the worst promoters of all this bullshit) and a 4-hour one for my current employer. The payment doesn't even have to be market, it's more important as a signal to candidates that the company values your time. I ask for 3 things from perspective employers: 1. value my time like you value your own (both the number and composition of your interview steps) 2. keep me updated as to where we're at in the process and when the next stage/decision will be made 3. Move forward in the process in a timely manner. It should not take more than 2 weeks from when you initially contact me to the process concludes. I've never gotten more than two of the above from a single organization, but I will someday, and I'm betting that a company that treats potential employees that well will treat actual employees better as well.
  • woolvalley 8y ago
    The issue with a paid project is you can't legally do it with people on work visas, which is a large part of your interview pool. They are all imperfect proxies due to various constraints.
    • rightbyte 8y ago
      What? Just let the programmer to it in his homeland. Easy. Just as outsourcing. I wish this project approuch was more common. It would probably be cheaper than wasting time on multiple days interviewing reality shows where people are voted out one by one like some companies do it.
• beders 8y ago
  I've been on both sides of this. Whiteboard interviews are good for a couple of things: Can the candidate explain a problem on a whiteboard? Is his hand-writing legible? It's not sufficient to decide if someone can code. You want some actual code written by that person. And you don't need everyone on your team being able to explain things well on a whiteboard. Just try to figure out how they are thinking and how they are approaching a problem.
  • deleted 8y ago
    [deleted]
• rafiki6 8y ago
  I feel like this topic comes up on HN every six months and we all lament the broken state of technical interviewing, and the ardent supporters of all the different styles come in and push their position based on success perceived from anecdotal evidence. I have a hypothesis that hiring a good candidate is mostly luck. When we view the hiring process in the context of what it actually is, a sales relationship, we realize that the customer (i.e. the employer), is ideally looking to buy services and time from the business (i.e. the employee/contractor). Viewed in this context, we quickly realize that many different things become part of the equation. Think about hiring a contractor for your home. If you happen to understand the job they do, you might be able to assess a the potential contractors previous work, quote and reputation effectively. Most people can't because they generally don't understand what it might take to do a job and have no experience in executing it even if they do. So you either heavily rely on recommendations from others, or go for a lower or higher priced contractor based on your perceived value (cheaper job, w/e the results vs more expensive job and risk mitigation) and hope for the best. Considering most software development doesn't actually happen at "tech" companies, the reality is most companies are like most people and likely can't properly assess talent no matter what. They essentially get lucky if they get a good candidate or unlucky if they don't. That would lead us to think that maybe the "tech" companies are able to do a better job of it. In essence they do, but not because of their methods. I'd say it's a form of selection bias. Google became successful and happened to be run by generally smart people technically capable people. As such they were able to attract generally smart technically capable people to work for Google. I'd venture a guess that 90% of people who make it to the live interview stage at Google would be qualified to work there, but since Google has it's pick of the litter they need to create a filtering system somehow. They happened to make it the "whiteboard" interview and similar high achieving Peer companies all tend to do the same thing. It became a thing, and as such all non-high achieving companies followed suit so they can behave like the high-achieving companies. The filter a company like Google applies is only necessary because they have too many candidates. Most companies aren't in a position to apply that filter if they really want talent. So really, they need to get lucky enough to get those who don't interview well with the "tech" company method of interviewing and hope they get some of those prime candidates. I'm pretty sure the tech talent pool, as with all things in life, follows a Gaussian distribution. If you interview enough people you're bound to find some decent ones, even if they don't actually interview all that well.
• theptip 8y ago
  The term "whiteboard interview" seems to mostly refer to "solving algorithmic/coding/puzzle problems on a whiteboard", which I agree is almost always a waste of time for a software engineering position. As the article mentions though, the term is a bit vague and is overly broad; for example if you're doing a system design question, I'd argue that the whiteboard is the best choice for an interview, since that's how you're most likely to collaboratively sketch the design of a system in the real world. I think the problem can be restated at a more general level; does the interview test the sort of skills that the job requires? Most people here are correctly pointing out that the skill/knowledge required to write out pseudocode for quicksort is almost entirely uncorrelated to the skills involved in most software jobs.
• glitchc 8y ago
  No in general. If yes, the problem should be simple and relevant, and the session highly interactive. The assessment should be about (a) How interested the candidate is in the problem (b) How receptive they are to feedback.
• nofunsir 8y ago
  The Chief engineer at my current place of employment said, and I quote verbatim: "I get a sort of sick pleasure from watching them squirm."
• LaserToy 8y ago
  Principal Engineer from huge gaming company here. White board coding interview are testing only one thing: how well candidate is prepared for it. And here what is wrong with it: The assumption that candidate should spend his/her valuable time preparing for someone's assessment is arrogant. I do understand why Google and Facebook do it (the do other arrogant things), they assume you want to work for them so much you will study to make the cut. So, they track bunch of metrics, which makes THEIR life easier. They have baselines, calibrations, and other things you never have in the real life. Hilarious part is that they are both risk averse (better to not hire a good candidate than hire a bad one) and using brood-force approach (they will interview you endless number of time). And if you are not prepared - you will most probably fail, unless you are really good at it or lucky. So, why should I prepare for Google's or someone's else interview? I have a interesting and very busy job, I just don't have time for this. I have commitments to my team to work on real products, not on fake problems from Cracking Google Coding Interview. Just think how absurd it is? So, starting from 6 month ago I: 1) Tell recruiters upfront I will not be spending a minute preparing for their interview process 2) I decline coding on the whiteboard. High level designs are fine, writing code - no, no exceptions 3) And the most important, I stopped asking candidates to code on the white board. The most important skill of the software engineer is (IMO): ability to keep complex problems in context for long time (not 5 boxes and months), ability to manipulate them and ability to convince others that you idea is worth pursuing.
  • balls187 8y ago
    > So, why should I prepare for Google's or someone's else interview? Because you want the job? Everyone is busy, that's a terrible excuse not to brush up on your interview skills. By the tone of your post, my sense is that prior to your recent epiphany you weren't very kind to candidates who you interviewed.
    • LaserToy 8y ago
      Do I? There are a lot of great companies, why should I waste time on Google? Working there is not as fancy as you think. >> Everyone is busy, that's a terrible excuse not to brush up on your interview skills. I believe that their approach is arrogant, they just don't value candidates time. I have a confession to make, I spent some time at Google. And after I left I was interviewing people using their approach and I regret it now. P/S/ When you interview for a company, you actually taking more risk that the company (talking about folks who are headhunted into interviews). If it doesn't work out, you will be out searching for a job, you career growth may be slowed down. And what is the company risk?
• balls187 8y ago
  How do engineers approach solving a problem? Whiteboard coding does a good job at assessing that, regardless of the candidates ability to actually solve the problem (for all the reasons why whiteboard coding sucks). Do you analyze the problem? Write test cases first? Write a mini spec? Gather Requirements? Ask Questions? Jump into code? Google? Verbalize the problems you encounter? In that respect, engineering coding interviews work well. But too often, they are essentially a binary Yes/No: Candidate solved the problem the way I want them to solve it.
• anonytrary 8y ago
  I'd propose a supplement for interviewing. If your company has at least one open-source repository: 1. Have a senior engineer chat with the candidate for an hour about a few bugs/features in the repository, and how the candidate would solve them. 2. If the candidate is promising, give the candidate a week or so to fix the bugs or implement the features. I think this would be a more relevant test than just giving them context-less problems to solve on a whiteboard.
  • pkaye 8y ago
    This basically filters out those who already have a job or getting multiple offers. Most candidates don't want to spend more than a day on an interview.
  • mmt 8y ago
    Make it a paid project, and it at least partially addresses the sibling comment's (valid, IMO) complaint that it filters out candidates that are otherwise in high demand. It would also provide a significant signal regarding valuing the candidate's time and effort [1], which would comply with the suggestion of another comment elsewhere in the thread. [1] As well as the additional signal of putting money, rather than just "free" candidate labor into open source.
    • anonytrary 8y ago
      Companies already pay thousands of dollars (per candidate) to fly out, accommodate and feed candidates for on-sites, so this doesn't seem unreasonable. Similarly, phone-screens and other filters would be done before a paid task is given.
• dvirsky 8y ago
  Programming without being able to insert lines is not indicative of real programming. To me that's the bottom line.
• nybblesio 8y ago
  A regular viewer of my daily Twitch programming stream (link is in my profile) asked me to solve a problem he was asked to whiteboard. He wasn't asked to draw diagrams or write pseudo-code so they could learn how well he communicated. He was asked to write the code and it was heavily implied that it must compile and run -- even though whiteboards don't do that. Here's my attempt: https://youtu.be/6LHqrxrC6Uo https://youtu.be/6LHqrxrC6Uo I solved the problem, with an IDE and a compiler. I communicate during the entire exercise. It takes me over 2 hours. Granted, I debug it, so that takes extra time. (Can't debug on a whiteboard!) I had to take one break. On top of this, I've solved this kind of problem before and it still took me more than the 45 minutes you're likely to get in a whiteboard interview. And I try to cover all of the "hot topic" points I know the interviewer is thinking about: size .vs. time tradeoffs, iterative .vs. recursive, etc. If I had to solve this problem on a whiteboard, in 45-60 minutes, with the bar being "it must run"....I would fail. I guess that makes me a poor programmer. Instead, I'm a grumpy old man who is really tired of all this fraternity hazing bullshit.
  • jiveturkey 8y ago
    It makes you someone that can't listen. The most important part of communication is listening. When the interviewer asks you to whiteboard a problem, they aren't asking you to "solve it". Obviously, you only have a whiteboard and you only have 15 minutes max. You might throw out some comment about size vs. time (eg) but make the decision and move on, quickly. The interviewer might decide to latch on but if not, you have to cover this in 15 minutes so you limit the depth so as to do that. Stub out all the deep functionality and then dig into each part of it as time permits and as the interviewer leads you in those directions. As an experienced and good programmer candidate, the most important part of an interview is for you to evaluate the company. So the whiteboard is a great way to see if they understand what can be accomplished in 15 minutes on the whiteboard. If they don't get it, you can end the interview short. Time saved today as well as the next several years working for a shite company. I love the whiteboard interview.
    • scott_s 8y ago
      The scenario nybblesio describes ("asked to write the code" with expectation it would be able to run) is not the one you described ("they aren't asking you to "solve it").
• ww520 8y ago
  Whiteboard as a communication tool in interviews is great. Sometime it's easier to write things down, draw diagrams, and list technical points than just talking about it. Writing it on the board provides an outline to talk about stuffs. Whiteboard as writing programming pseudo code or steps are fine. Just don't be a human compiler and demand perfect syntax.
• PopeDotNinja 8y ago
  I'll stop short of saying whiteboard interviews, with or without coding, are suboptimal. I will say that any interview question which attempt to see how I think is suboptimal. How I think when on the spot does not reflect how I think on the job. Speaking for myself, I like pair programming interviews.
  • redisman 8y ago
    I like pair programming interviews too, the only thing is that there's still some murky-area between interviews of how much should you lean on your pair and how much should you prove independent problem solving.
• debt 8y ago
  I love these kinds of post. It's like saying: "Highways: Yay or nay?" "Food: Yay or nay?" "Air: Yay or nay?" Hate on whiteboard interviews all you want, but that attitude is going to put you a massive disadvantage in the current rigmarole of software engineering interviews. It's not a thing 99% have any interviewees have control over. Nor is there a way to tell the interviewer: Hey, I prefer not to do whiteboard interviews. It doesn't work like that.
• anonytrary 8y ago
  Whiteboards, in practice, are never used for writing strict code. They're used for high-level diagramming and high-level pseudocode. The only time I've used whiteboards in my job is either when I need to hash out a solution or approach with my coworkers, because I'm confused or don't understand the problem, or when I need to understand high-level architecture for a system. It's a tool for clearing one's thoughts and for getting a team "on the same page". If you're hiring someone to code-monkey a bunch of JIRA bugs, then whiteboarding might not be a relevant test for them. If you are hiring someone to build out new features efficiently or redesign architecture, then whiteboarding may be useful for having them describe at a high-level how they would solve problems. In both cases, writing syntactically flawless solutions on a whiteboard is a waste of time for both the interviewer and interviewee.
  • 0x00000000 8y ago
    At a big 4 company recently, they specifically told me "avoid writing pseudocode"
  • mountainofdeath 8y ago
    Most selective companies require you to have near correct code in the most efficient algorithm, clean, correct, concise, with all edge cases in about 30-45 minutes depending on the question. They also seem to love dynamic programming algorithms and competitive programming tricks (the less common stuff you glossed over in an advanced algorithms class). I say this as someone who worked at one and interviewed at others. You really do need to treat it like an exam.
    • anonytrary 8y ago
      Interviews of the sort you describe are like judging a fish by its ability to climb a tree. Indeed, whiteboards in interviews are used nothing like they are in real work. I'd hope more companies try and make interviewing closer to an actual work environment where the candidate can comfortably use their computer for solving the interview problem, using a whiteboard solely for communicating concepts and other surface level issues.
• dvdhnt 8y ago
  Yeah, no. At least, not to test the technical proficiency of a potential team member. Instead, have a conversation about how to solve a well defined problem. Use the whiteboard to record potential solutions in high level terms, or if the candidate chooses, to note key concepts or concerns. Your interview environment should be a "staging" environment for your day to day operation. The interview should gauge how the candidate might affect your development process. Once the interview ends, snap a picture of it. When you're debating candidates and try to remember your impression of them and how they contributed. Consider the sum of the input they verbalized and the input they wrote. That should give you a good idea of what they'll offer - well, along with your impression of them to that point.
• liquidise 8y ago
  Whiteboard coding measures penmanship while nervous. I have some firmly held opinions [1] on this topic. Interviews are too much of an "art" for how important it is that their results be repeatable. Keep them on topic as much as possible. Making a coder perform circus acts on a whiteboard they will never be asked to do otherwise is simply measuring for skills you don't need. 1. https://blog.benroux.me/whiteboard-coding-measures-penmanship-while-nervous/ https://blog.benroux.me/whiteboard-coding-measures-penmanshi...
• lambdasquirrel 8y ago
  > What’s great about a white boarding session is that it is a blank piece of canvas, where the interviewee can effectively think out loud, collaborate, draw diagrams and also brainstorm with the interviewer. Is the typical engineer conducting an interview good at contextual inquiry? At holding space for people to think out loud? Lets not kid ourselves here. The only people we’re harming are each other.
• 11thEarlOfMar 8y ago
  Nay. We have a round of interviews and then send the candidate home with a choice of 5 coding tasks. Intention is to spend no more than 2 hours. Then they return and hold a code review in front of the team and explain what they've written. That way, they code at their own pace and in a comfortable space where they can focus, much like the way they would actually work. Then they've got it all right in front of them for discussion. The review then weeds out people who don't really understand what they've written, possibly because they borrowed it from somewhere or asked a shill to write it for them. We've had a range of submissions, from the casual-careless-broken code to extremely complete to elegance like we've never seen before. It works well.
• sebringj 8y ago
  Waterboarding and whiteboarding are phonetically similar as well.
• simpixelated 8y ago
  For anyone that wants to work for a company that DOES NOT do white-boarding during interviews, here's a solid list: https://github.com/poteto/hiring-without-whiteboards https://github.com/poteto/hiring-without-whiteboards
• pkteison 8y ago
  I find it weird that the responses seem to draw a distinction between whiteboards and coderpad. The assumption seems to be that the problem making the whole thing stressful and unnatural was the communication medium and not the fact that it's a super time compressed artificial problem with many unstated considerations and a tremendously outsized influence on the rest of your life, no pressure, just talk through everything exactly like you never do. Most of the problem seems to me fundamentally unaddressable without verifiable portfolios, but those have their own problems. Even in industries where portfolios are standard, plagiarism is a thing - how do you get the verifiable part? I want to hire someone great, not just someone who was on the same team as someone great.
  • jpindar 8y ago
    Even just coding on a computer with the screen cast up on a big monitor or projector would be a vast improvement over literally writing on a physical white board.
• jackcosgrove 8y ago
  I think an under-tested aspect of software engineering is the ability to research solutions on the internet. Just give people a search bar and ask them to solve a problem outside their comfort zone. See what terms they use and how quickly they can arrive at a useful link. No pseudo-code or architectural diagrams needed. Just a link with a plausible solution. Because that's how most learning on the job actually happens.
  • jpindar 8y ago
    If I were interviewing that would absolutely be an important part of the interview. It never ceases to amaze me how bad some people are at searching.
    • scottyelich 8y ago
      Hell, I've coded in languages that I didn't even know (didn't really even know what the language was -- I think it was like VB or something) by copying terms from some sample, reference or other part of the code and putting in the term or idea I was looking for. Additionally, just try to look up items on a language that is in (constant?) flux like Swift. Swift 1.x? 2.x? 3.x? 4.x? What's the API today -- naming convention changed, parameters changed, etc. All I can say is that thank goodness Google allows for date ranges with searches. :-)
  • tluyben2 8y ago
    I agree. I interviewed people who optimized for white boarding interviewed and, as such, could knock up CS algorithms which you can trivially import from libraries all I wanted. But when asking them a problem they did not encounter before and Google, they got very stuck. While, every time, there was a way of writing the query to Google that had the answer in the top 3 (usually #1). People waste crazy time on reinventing the wheel. Anecdotal: we had some problem to solve which required qua a lot of code to solve and only old sites with broken links came up in Google for the guy solving it so he decided to implement it himself. When I asked why that task was taking so long he showed me what he was implementing. The code he was writing had an implementation on an old site which had a broken link to the code; when I copied the name of the zip file that was linked in github; there was the code. It had no description or comments; someone just checked it in. It was not perfect code, but it shaved off a few days of writing it from scratch anyway. I care about being able to code, which can be assessed from past code and a pair programming session and then efficient problem solving using your brain and internet. The latter is somehow less common. So my favorite way now is; I ask them to 'solve' a problem they have never encountered and that cannot physically be done during the interview time (I am interviewing for software development and in our field you get asked for things that cannot be done in the time you are asked to do it all the time, so I need to see how you handle that); give them time to Google possible ways to do it and present a little plan. Then they need to pick, out of the plan, something they think they can do inside the interview time (see how confident they are and if they have any sense about low hanging fruit or estimations; I might suggest something else if the task they pick is only installing libraries for an hour ;) and we'll sit together behind a monitor and do it together. I'll usually tell them to stop after 15-30 minutes as I have seen enough at that time.
• deleted 8y ago
  [deleted]
• jrs95 8y ago
  This is one of those things that even if it can be done correctly in theory, it’s often so bad in practice that it’s probably best to just not do it at all.
• deleted 8y ago
  [deleted]
• pan69 8y ago
  As with everything, it depends. To me, whiteboard interviewing makes sense when hiring for a role that leans toward a comp-sci background. People who do well in these roles typically have a brain that works in a certain way. The roles that lean away from a comp-sci background are usually the type of developers who don't do well with whiteboard interviewing techniques. What too often happens is that a hiring engineer doesn't interview within the context of the role they are hiring for.
  • ordinaryperson 8y ago
    > People who do well in these roles typically have a brain that works in a certain way. You know this how? Intuition? People have all different kinds of backgrounds and brains.
• jihoon796 8y ago
  If you must do whiteboard interviews, here's a technique I've used with great effect: Have someone else pick a coding problem (that you as the interviewer don't know beforehand), and work on it from scratch together with the candidate. Being upfront with the candidate that you don't know the answer yourself puts the candidate at ease, and you'll be able to better judge the candidate's soft skills (communication, critical thinking, empathy in case I don't understand the problem).
  • pdxandi 8y ago
    I like this idea. Personally, I struggle with knowing that the interviewer knows the answer. My wife's in medicine and she and her colleagues call this process "Guess what I'm thinking?" I prefer to have dialog and come to a conclusion together, and I feel it gets what you want out of an interview: how does the candidate think, how deep is their understanding of the technology, how do they communicate, and would you enjoy working with them.
    • deleted 8y ago
      [deleted]
• andrei_says_ 8y ago
  I’d be curious, are interviewers running whiteboard interviews willing to do one, conducted by a colleague, in front of their team? Does this practice exist anywhere? It would be interesting to do this maybe once a year? And put $100-500 toward getting a pass or non-pass(money gets donated to interviewer-selected charity), just to throw in some money in the game? And I mean an interview based on non-trivial CS problems, not brainstorming / code ideation which we do often.
• dqpb 8y ago
  I think most people that are opposed to coding interviews feel that way because they don't feel confident in their ability to do those interviews well, whereas they do feel confident in their ability to "get work done". Here's the thing though. Let's say you're the one giving the interview to two people who claim to be able to get shit done. One is able to code up a solution quickly and the other struggles, producing less, or producing something that's flawed. Sure, that second person might actually be productive under the right circumstances, but that doesn't matter because the first person already proved they can code. That's the whole point of interviews, getting high signal in a short period of time. If you think coding interviews don't provide high signal than propose something better that costs the same amount of time.
  • Retra 8y ago
    Your resume, Github account, demonstration of previous projects, ability to discuss problems you've solved, references from previous coworkers & instructors... The whiteboard is not providing "high signal". Everything else is. The whiteboard is providing low signal, and taking quite a bit longer to do it.
  • jcbrand 8y ago
    This doesn't take into consideration how much studying and preparation the person who produced a solution quickly did compared to the person who took longer. If that person studied much more, then they weren't really "quicker", they were just better prepared. Perhaps that's still a reason to hire them, but not everyone has time to study lots of programming puzzles before an interview, and this is then less a measurement of speed, and more of preparedness. It also doesn't take into consideration whether the whiteboard problem being presented is at all relevant to the job being offered.
• ggggtez 8y ago
  >Software engineers hate whiteboard interviews. How do I know? We continually tell complete strangers just how much we hate them. And yet, whiteboard interviews are probably 3rd on the list of flamewar topics behind vim, and whitespacing. So there is clearly some people who don't hate them. I count myself in the camp of people who don't relish the world before fizzbuzz.
• fareesh 8y ago
  I generally ask candidates what they did last week at their existing job, and then ask questions about how they solved specific aspects of that particular job. If the person says "we built real-time tracking for our in-house vehicle fleet", I will just probe further and further about what role they played and how they went about the specific implementation details. If there is any kind of secrecy surrounding their work, I will simply offer them insight into what they'll be tasked with during their first week and ask questions in a similar manner. I'm not sure what advantage any other approaches have - I am hiring to fill a particular position. It's quite likely that the candidate will be in a similar position, so either I ask them about their current work and how they went about it, how they intend to accomplish the work assigned to them when they work with me.
• halis 8y ago
  If you're going to interview someone that is going to write code that a computer runs, then make them write code and run it on a computer IN THE FUCKING INTERVIEW. Silicon Valley is retarded.
• ordinaryperson 8y ago
  Having just been through this process (landed a new job after a 2-month search), the worst part about whiteboard coding is how humiliated you feel if you don't get it right or don't know where to start. Is it really necessary to do that to candidates? I've been doing this for 15+ years professionally, have a master's in CS and I struggled to answer many questions. Just stood there blinking like a goldfish. If companies really wanted to simulate programming work, you'd give me 10-30 minutes to Google the problem because THAT'S HOW IT WORKS IN REAL LIFE. Which is how it should be; rarely are you solving a new problem, usually other people have faced it before, it's probably far more efficient to start with a known working solution and iterate from there. Look, of course there things you should know. Data structures, algorithm basics, some complexity theory, etc. But asking me to output numbers in a matrix in a spiral fashion does not translate into real-world ability. I find the more important developer skills are people skills and project management skills. How well do you work with others? How do you resolve conflicts? What's your methodology for grouping work-- Jira tickets, sprints, etc? But almost none of the interviewers seemed to care. They wanted to know what exotic technology skills I had, not that I could work with project managers and marketers effectively. Take-home projects are more time-consuming but the least unfair, whereas whiteboard coding is the shortest but most unfair. I blame Google for this curse. I hope the next time I go looking for a job this process has changed.
  • madrox 8y ago
    Asking someone with your amount of experience a coding exercise is silly. You wouldn't have lasted 15+ years if you didn't know how to code. Spend more time evaluating the "softer skills," since more experienced engineers have a bigger impact on culture and process.
    • ordinaryperson 8y ago
      Right? Ask me about past projects. Want GitHub examples? Fine. But whiteboard coding some non-real-world problem? I get that companies need some sort of filter, but whiteboard coding is not the answer, IMHO.
    • bcassedy 8y ago
• madrox 8y ago
  I've always been in the camp of not doing coding interviews...whiteboard or otherwise. Overall, that's worked well when hiring engineers with 3-4 years of experience or more. Less experienced engineers are very difficult to assess without some kind of coding exercise. All the hires I've made that I'd characterize as mistakes are of junior engineers that I didn't do a coding exercise with and interviewed well, but didn't bring that interview polish to the job. Since instituting whiteboard exercises for junior positions, our success rate has been higher (no pun intended).
• AgentOrange1234 8y ago
  I’ve interviewed a lot of folks, and bitter experience had taught me to always ask at least a couple of whiteboard problems. I’ve often been completely shocked that someone I thought seemed promising was unable to think through basic problems.
• oh-kumudo 8y ago
  Yes? It designs to filter people based on certain criteria. Nowadays, you just can't get a job by merely talking, the market is too hot, too many people want to get in. I don't think design interview alone is that useful either. Someone without actual experience designing stuff could still fake it by reading other people's past solutions and answers, there are templates on the internet. Nothing is inherently bad just because it fails you. Everyone saying Google's process is broken, blahblah, doesn't change the fact Google employees are hot AF on the job market.
  • jpindar 8y ago
    >Nowadays, you just can't get a job by merely talking You can if you're willing to work for a smaller, non-famous company.
• jjbinks 8y ago
  I've done close to 500 intermediate and senior level engineer interviews for one of the top 3 tech companies. For a time we offered candidates a laptop to code on during their interviews. To my surprise over 70% preferred the whiteboard. Go figure.
• dionian 8y ago
  whiteboard is more useful for design than code, i give them a computer to code on
• swyx 8y ago
  great article! it would have been nice to have a comparison of yays vs nays, like for example 67% of engineers say nay, whereas 50% of companies on key values do have some sort of whiteboarding in their process. with the caveat of course that the kind of companies that talk to you (keyvalues) are probably more progressive anyway so there is selection bias. but it very much does seem like whiteboarding is on its way out.
• deskamess 8y ago
  If someone gets hired, and on the job in the next year, they do not implement/discuss the interview questions in any non-interview situations, then drop those interview questions. When a candidate fails to answer a question/task, ask the co-worker who asked the question/task to complete it (and be just as strict with them).
• blubb-fish 8y ago
  whiteboard tests are always going to produce fuzzy red and white flags. those will come handy later when it gets to assessing the applicant based on sympathy and arbitrary objective arguments are required to back whatever the interviewer wants to conclude.
• kapauldo 8y ago
  I hire for propensity 100% of the time. I've hired around 20 engineers in the past few years, zero regrets. White board interviews eliminate a lot of green highly talented people.
• tzs 8y ago
  A couple of comments have mentioned LeetCode. While reading those comments I had an odd idea on a different way to use LeetCode when interviewing. The usual way would be to get problems from them and spring those on the candidate to solve on a whiteboard or on a computer. Numerous people have raised objections to that kind of interview. Instead, how about sitting down in front of a computer with the candidate, going to an interesting problem on the LeetCode site, and reading the problem statement with the candidate. Make sure you both agree on what the problem is asking for. Then, instead of having the candidate solve the problem, go to the discussion page for the problem, and start reading the posts with the candidate. These will include posts from people who are asking for help understanding the question, and from people who are showing off their solutions. Pick a few where the poster is asking for help understanding, and ask the candidate how they would clarify things for the confused poster. Pick a few where the poster is posting their solution, and ask the candidate to do in informal oral code review along with you. Let the candidate take the lead, just providing nudges if necessary. For ones where the review finds serious bugs, talk about how to make test cases to demonstrate the bugs. From what I've seen on LeetCode problem discussions there will be a lot of posted solutions that have edge cases that fail, or fail to meet time or space requirements that were given, or leave out major cases, or make implicit assumptions about the input that if violated invalidate their sultion. There should be no problem finding plenty of posts with plenty of things to bring up in review to discuss with the candidate. This seems to me that it would not be overly stressful on the candidate (way less stressful than writing code under a short deadline), it is exercising skills that working programmers actually use, and it would let you do some work with the candidate to get some idea of how they get along with others when working.
• bitshepherd 8y ago
  As a senior-level self-taught, I redacted this post because of my views on whiteboard coding. Downvotes are not cool.
• nnd 8y ago
  Whiteboarding or not, what are some good resources to prepare for a coding interview that worked for you?
• dm7 8y ago
  whiteboarding is essential when hiring for roles where development environment is not productive. there are still huge systems which take 5 minutes to link on fastest machine, or embedded, real-time and distributed systems where it takes so much time to debug that one's daily productivity would be close to zero unless he writes code which would be mostly correct before first run. developing under such constraints is radically different from environments with high iteration velocity - i.e. browser or scripting. that said, in many modern environments whiteboarding is completely irrelevant, as modern application level programmer productivity is often ability to do plumbing-and wiring- work between many components and quickly assess why something is going wrong, rather then creating a highly performant or memory-efficient algorithm implementation.
• arcticbull 8y ago
  In my experience conducting engineering interviews (about 300ish so far) I much, much prefer pair programming interviews in front of a computer with an IDE and access to the internet and standard resources. This most closely resembles how we work together and engineers and gives candidates the best chance to show off their skills. Whiteboarding code is something people almost never do in their professional careers, and as such, you focus on all the wrong things (is that the name of that library method? is that where that semicolon goes? is that best practice?). It's neither fair nor representative. Of course I have no problem testing architecture and communication ability in front of a whiteboard, as this is much closer to how these things are done in the workplace.
• jakeinspace 8y ago
  I'm an almost-graduated computer engineering student. I had a relatively pleasant interview last week with a whiteboard component which I thought was fair. The interviewer asked for a Fibonacci function, an easy problem that still allowed me to show that I understood some more advanced concepts. I gave a basic recursive solution, was asked to critique it, explained how it was inefficient in time and space, and would blow up the stack (without tail call optimization). Then I thought I'd mention dynamic programming as a possible solution to the time complexity, but one that would still cost a ton of stack space. Finally, I gave the iterative solution, and explained how it was more efficient, and how you could use it to pre-compute a lookup table. The interviewer propmpted me along the way, it felt like a friendly conversation. The fact that it was an easy problem prevented me from stressing out, but I still felt like I was able to demonstrate some academic ideas. I was always pretty decent at standardized tests as a kid, and this argument over whiteboarding reminds me a bit of that. I don't think it's useful for gauging general software engineering skills, but it might have some value for evaluating communication. It also feels like the sort of thing that software engineers with a strong academic background tend to enjoy more than those with more practical/industry experience, but that's just anecdotal.
• gregrata 8y ago
  So I've been frustrated by this type of interview for years (on both sides, but the last 10 years on the hiring side). I don't think it's great finding people that are good at writing software (as it's a LOT more than a single algorithm and more than just coding). I wrote a book it - along with what I've been using the last few years, that actually seems to work - or work at least a bit better. In the end, I don't think you really know unless you work with someone. https://www.amazon.com/dp/B07FJ6N8P1 https://www.amazon.com/dp/B07FJ6N8P1 It's my first attempt at a book (small as it may be!) - I'd really appreciate some feedback (and it's free right now) -Greg
• raz32dust 8y ago
  Whiteboard is GREAT for communicating design or technical ideas (e.g, what is consistent hashing, can you show how you'd merge N sorted lists schematically?). And these skills are super important in both big companies and startups. And we should definitely test candidates in these areas using whiteboards. Making engineers write code on whiteboard is just comical. If we weren't so used to it, we'd probably have laughed at the idea. In 2018, any company still using whiteboards to write anything more than pseudocode is just playing it too safe or being really lazy in changing their process. Just give them a laptop and have them use coderpad/skype interviews or any of the plethora of collaborative code editors out there. Or even, dare I say, an IDE. You can still have the whiteboard in the room to discuss the idea. But write the code on a laptop with internet access.
• relate 8y ago
  I've done whiteboard only interviews, as well as shared doc/coderpad only, and I find both limiting. When thinking about the problem, it's great to have a whiteboard to sketch examples etc, but writing code is much easier with a text editor. Recently I interviewed at Google, and they had no problem fulfilling my request to do both: sketch the solution approach on whiteboard and then write the code with a laptop.
• DrBazza 8y ago
  Yes to whiteboards if they're used correctly. If the candidate can't explain or solve something simply on a whiteboard, they probably don't understand the problem or domain. That's not to say that the interviewer might not be a great interviewer in the first place though. Quote: "Feynman was a truly great teacher. He prided himself on being able to devise ways to explain even the most profound ideas to beginning students. Once, I said to him, “Dick, explain to me, so that I can understand it, why spin one-half particles obey Fermi-Dirac statistics.” Sizing up his audience perfectly, Feynman said, “I’ll prepare a freshman lecture on it.” But he came back a few days later to say, “I couldn’t do it. I couldn’t reduce it to the freshman level. That means we don’t really understand it.”"
• z3t4 8y ago
  I think in images, and always visualize the problem, so I would love doing it on a white-board, I actually find it easier then writing the code itself, and I find it very hard to describe the problem in words. While others think in code, and yet other people think in words. So in order to not dismiss a good candidate, explore how they think about problems. Can they describe it with words ? Can they describe it with code ? Or maybe they can only describe it in pictures !? There are also other ways of thinking. Some people think in shapes, then solves the problem like a puzzle making the shapes fit together. These guys/girls might be on savant level and would have a very hard time passing any traditional interview.
• keithnoizu 8y ago
  I always do horribly on these. I also don't have a degree in computer science so although I can setup a binary search tree, etc. well enough if work demands it I don't have the muscle memory of working with them intensively over and over again to spin out solutions to interview questions. Once in the workplace however I usually get promoted up pretty quickly. I'm pretty handy with generics and meta programming along with architecture and design patterns, meaning I can turn out more complex systems in much less time than most of my coworkers. But that crap never comes up in the google/microsoft interviews of the world.
  • adrianmonk 8y ago
    IMHO, people with/without CS degrees should be evaluated by different standards/methods. If you do have a CS degree, then I expect you to be able to show decent competency with that material because you were sitting in all those classes for all those years. If you didn't learn anything, it makes me question whether you apply yourself to what you do or just coast through stuff and are going to coast through at this job too. Since we have the shared experience of a CS degree, if I understand what you got out of it, I think it tells me something about your attitude and approach to your work. If you don't have a CS degree, then I am going to focus more on skills required for the job role itself. If being strong on algorithms is really necessary for the job, then I'll need to cover that. For any job, though, I'll need to convince myself you have a certain base level of competency so that, for example, you know that a linear search of a billion items is bad.
• telltruth 8y ago
  I wonder how many of these people are actually active coders which gives them authority on opinionating on how to interview developers. VPs (especially Chief XYZs) are typically good sales and marketing guys with engineering background that often can only be described as hopelessly out of date (or more politely "has-beens"). They need to keep their heads out of real development stuff. I'm also frustrated with how people have developed disdain for anything whiteboarding. Asking leetcode puzzles in interviews is bad. Asking questions from CTCI is worse and amateurish. But... asking to whiteboard a problem that you had to solve on your own job in limited time is good! Interviewing is hard because crafting such questions in a way that it abstracts away minutia of transient technologies but retains essential problem solving is hard. This is exactly why, a right policy for a company is to establish being an interviewer as a privilege that needs to be earned because not even all brilliant programmers are good at it and interviewers must take time to craft good question and show care. When they don't, they turn to leetcode, pick random question and give whiteboarding a bad name. And no, whiteboarding is not bad. What is bad is asking to do X using MongoDB and RectJS because technologies like that are transient. Specific technical tasks that employees might perform in a given point in time are transient. Ultimately what matters is ability to learn, process and use that to solve a given problem. Ofcourse, unless you are company who does nothing but data driven web forms. In that case, yes, go ahead and ask candidate to do just that.
• usrusr 8y ago
  Random fun idea: pair whiteboarding, have one of the reviewers start improvising a solution (or put on a show of not having done it dozens of times before) and see how the candidate will contribute. If the problem is not one of the standard ones (that will be perfectly memorized by desperate candidates, while rightfully confident ones may struggle), it will demonstrate understanding, not the irrelevant ability to sequentially write out code in an unfamiliar medium. After all, you probably don't want to hire those who have already been rejected so often that they can code on a whiteboard as if they did it all day.
• serp3ntine 8y ago
  Yea* or nay, not "yay" or nay. Damn millennials...
• markatkinson 8y ago
  I recently had a coding interview and it was a disaster. The annoying thing is it was actually a super simple question and I had done a lot of preparation, and had solved a similar issue in my actual job just by chance a couple weeks before. So it started out great. But instead of acing it an issue cropped up in the coding pad which I had to try and debug, which threw me off guard. The interviewers had muted their mic and were chatting away and my nerves just crumbled and I ended up profusely sweating into my eyes, I literally had sweat going into my eyeballs. I just turned into a bit of a mess, which is strange for me as I'm normally quite confident. I think if the interviewers were a bit more involved it may have gone better. But I ended up just not finishing in time feeling like I had wasted everyone's time.
• ben509 8y ago
  There are three goals in interviewing: for the interviewer to gather enough evidence to prove that the candidate is going to succeed in the role, evidence that they will grow in the long term, and to sell the candidate on the position. A whiteboard interview isn't a good growth indicator, but it's great at leveling a candidate. Moreover, it signals to a candidate that their peers will be at a similar level. So I'd vote yay. If you pay attention, you can determine someone's proficiency at coding on the whiteboard in about 15 minutes. This is particularly important when you have people who are changing careers or junior or otherwise don't fit the mold. I'm honestly shocked at the arguments against whiteboarding as many of them seem entirely reactionary. "But I'm never going to work that way." Didn't we all do the better part of two decades of formal schooling? We test people like that for a reason: you can carefully focus on the specific markers of mastery of a subject. I understand why people make this argument: it's a reaction to some of the weird puzzles companies used to ask. But it's never substantiated that this will help the interviewer and candidate make a better decision, so it has the same problem the puzzles did. "But at work I have Google and StackOverflow." This is a good point, the questions you ask in a whiteboard question should be based on the fundamentals rather than trivia. But it's a terrible point because it accepts that the interview is just a ritual you go through and this argument is that we should make it fair. Whether a candidate knows "the answer" is not the point, it's more that they're able to talk about what's going on, have good instincts, etc. If you're an experienced engineer, you've seen lots of people write code, you know what looks like "junior" or "senior" and "guy who thinks anyone can just pick up coding." "But if I work on a computer I can compile and see the edge cases." Are you interviewing the candidate or the compiler? Again, this is the ritualistic view of interviewing. "But at work I have plenty of time to work on things." Everyone has this problem, so everyone is less able to perform, and the interviewer can simply adjust expectations. "All of these interviewing "tools" (or tricks) attempt to be time/cost efficient proxies for doing the damn job..." That's very much the ritualistic view. Other industries have had notions of apprenticeships and so forth for thousands of years, and our problem is that we view recruiting, professional development, etc. as things someone else does, rather than something we take ownership of. Interviewing is a critical business function, it can produce value and thus is not a waste of time. If you treat it as a useless ritual, though, it will be.
• Madmallard 8y ago
  If you can solve arbitrarily hard problems while on the spot you must be a stellar candidate from a problem solving perspective. If you can effectively articulate your thought process as well you probably have great communication skills and can handle technical discussion and group problem solving for harder problems. It's gonna weed out a ton of people that can do the job but the guys that rock it will probably be valuable assets.
• onemoresoop 8y ago
  IMO whiteboard interviews are disadvantageous to shy people. However, that aside, generally in meetings whiteboard could have some benefits if not abused
• unrealchild 8y ago
  We offer a whiteboard for the onsite if it will help a candidate communicate comfortably. Narrative is totally fine, gesticulations, metaphors, interpretive dance, whatever means of communication works to get the point across. We send out a small HW assignment before an on-site, after a phone screen. Not all candidates enjoy it, some expect an algorithm driven whiteboard experience. Our process delivers for us, and we tend to naturally attract a good culture fit as a byproduct. In practice we do end up at a board day to day explaining ideas and so on, and everyone seems more than comfortable (with the exception of handwriting insecurity).
• deleted 8y ago
  [deleted]