12 ms·

I've been using whiteboards for 2 decades during the interview process and they work great, if you ask the right questions. I've built great engineering teams a

I've been using whiteboards for 2 decades during the interview process and they work great, if you ask the right questions. I've built great engineering teams at companies like Orbtiz and whiteboards were one of our best tools. The reason they are important is that they are part of every engineers day-to-day work. We use them to collaborate and design and understand. Therefore, if a candidate can't whiteboard a design, solution, architecture, etc. in a manner that other engineers can understand it, they are going to struggle. That being said, the way Google and other companies use whiteboards is an epic fail. Asking someone to code on a whiteboard is stupid. Asking them to solve algorithm puzzlers on a whiteboard is lame. This isn't how we use whiteboards every day so why should a candidate be expected to use them this way during an interview.

andrewstuart2 8y ago
I've legitimately used whiteboards to pseudocode while discussing architecture with teammates plenty of times before. Does it compile? No. But the point is that I can more easily demonstrate the benefits of an approach with some concrete pseudocode to help grok the proposed algorithm. As an aside, if you've never done systems design or pseudocode on a Smartboard, you're really missing out. Copy/paste, duplicating a slide, recalling earlier slides, etc. Man, that's the way to design a system with quick iteration but still no worry of losing your work.
- Jemmeh 8y ago
  Yes but I think the point is a lot of interviewers do not go for pseudocode. They want syntax perfect solutions on a whiteboard.
  - ianhawes 8y ago
    This. When interviewers feel that the question was not hard enough or that they didn't like the answer, they often fall back on "you're missing a semicolon".
  - brokenwren 8y ago
    Yes. That's essentially what I was getting at. Asking someone to code accurately on a whiteboard is nonsense. When I interviewed at Google, they asked me if my whiteboard code would compile. I said, "give me a laptop and I'll tell you". I don't think they liked that answer. ;)
    - bsk26 8y ago
      When I ask candidates if their whiteboard code compiles, it's a gentle hint that there are major structural issues, or an opportunity for them to point out the parts that are psuedocode-y. In general I don't include whether the code compiles (mostly JS, so "runs") in feedback unless it is amazingly perfect or really far off. This seems standard.
- deleted 8y ago
  [deleted]
extralego 8y ago
Can you point to examples of how you do use whiteboards? I am a self-taught programmer with my own way of noting design strategies and having a tough time finding examples of this.
- organsnyder 8y ago
  Not OP, but I use whiteboards to sketch system designs and things like that. For instance, I'd sketch out the path that a request might take through a complicated system (intake via a REST service, flows through a queue, consumed by another service, persisted to a database...). That's the sort of thing that I would be comfortable doing as part of an interview—though I wouldn't expect a junior developer to be able to do it. AFAICT, the backlash is around interviews where candidates are asked to write code (or pseudocode) on a whiteboard. Being able to implement bubble sort on a whiteboard does not correlate very well with being able to deliver business value, in my experience.
  - xur17 8y ago
    > Being able to implement bubble sort on a whiteboard does not correlate very well with being able to deliver business value, in my experience. To add to this, it's being able to write code on a whiteboard in a high pressure situation while talking about every step you're taking. Over time I've gotten more comfortable with this, but mainly by doing more interviews, not by getting better at my job.
    - Azeolus 8y ago
      If you ever find yourself in a situation that Broadcast television would have us believe, you'll be excellent at coding that hotfix into a real time system as the president of the United States looks over your shoulder.
    - extralego 8y ago
      When I was younger, this would probably make me feel insufficient but I have done enough ‘learning stuff’ by now that I expect this kind of comfort to only come with experience.
romaniv 8y ago
Whiteboards are okay for ad-hoc lists and diagrams, but they are a poor medium for coding. Some of the biggest productivity gains I've had over the years were related switching from "writing code down" to "thinking in code" mentality and abandoning linear, paper-like ways of thinking, which hindered me when I was in college. For anyone who believes that paper and whiteboards are "good enough" for coding, I highly recommend watching some of Victor Bret's or Alan Kay's talks. Pretty much any of them. They consistently touch on the subject of dynamic media as a way to empower people to... well, think better for the lack of better terms.
- tlarkworthy 8y ago
  I think you have got the wrong lesson off those guys. They are about engaging the spatio-visual systems. The whiteboard is the first step away from text towards that. Obviously they want to go a lot further than a whiteboard, but the fact that you can draw things, circle things, wipe things off makes a whiteboard a much more dynamic media than an ASCII interface. I think you would find them pro-whiteboard for thinking design.
  - romaniv 8y ago
    >I think you have got the wrong lesson off those guys. They are about engaging the spatio-visual systems. The whiteboard is the first step away from text towards that. Not when you are literally writing code on it.
    - rando444 8y ago
      I guess I'll just point out the distinction.. there's an obvious gap between writing code and writing pseduo code / logic structures. And there's nothing wrong with whiteboarding pseudo-code.
- curuinor 8y ago
  bret's apparatus in dynamicland is literal pieces of paper embodying code, which, quote, "also are fully functional pieces of paper".
notheguyouthink 8y ago
As an aside, any resources for learning whiteboard techniques? Not specifically solving algorithms on whiteboards, but designing and conveying information during architecture planning/etc? I feel like there's two angles to this; 1. understanding complex algorithms commonly used as tests. 2. understanding how to convey information on whiteboards efficiently, common paradigms, etc. #2 is what I think I'd actually enjoy improving. #1 is just SAT style stuff that I infrequently use in my day job and serves as an annoyance more than anything.
vkou 8y ago
> That being said, the way Google and other companies use whiteboards is an epic fail. Asking someone to code on a whiteboard is stupid. Asking them to solve algorithm puzzlers on a whiteboard is lame. This isn't how we use whiteboards every day so why should a candidate be expected to use them this way during an interview. Every candidate I interview has the choice between coding on a whiteboarding, and coding in a text editor with rudimentary code formatting. I really like it when people code in the text editor, because that's one less thing I have to transcribe in my interview evaluation. Regardless of whether they will choose the whiteboard or the laptop, I have never, and will never mark people down for typos, confusing .length with .size, a missed semicolon, or any other petty bullshit that isn't pertinent to the problem. I'm not hiring a compiler.
- contras1970 8y ago
  not that i'd feel like my success in interviews hinges on this, i just find this very refreshing. where do you work, and are you hiring?
  - vkou 8y ago
    Google, and yes, and unfortunately every interviewer is different, as all the bad experiences people post about can attest to.
dalbasal 8y ago
An important thing to remember is that broken/not-broken is completely different for each side of that desk: candidate person & hiring person. This is always the case for selection steps. The employer (or school, etc) wants to make successful hires and to avoid bad ones. False positives are always a big problem. False negatives are usually much smaller one. A process is good if it produces good hires, and no bad ones. In principle, a process that hires 3 good candidates from a pool containing 5 good candidates and lots of bad ones is good. Avoiding bad hires is paramount. Missing 2 good hires is not as bad as making one bad hire, not near as bad usually. Most employers don't care about false negatives at all. If they do, they probably care most about missing really good outlier hires, not mistakenly selecting the 5th best candidate instead of the 4th. The only reason to care is fairness. People instintively care about fairness so this affects practices but it's not nearly like false positives. Employers that need huge volume (eg, the army) are the only ones that care about false positives as much as candidates do. The candidate (student etc.) generally feels the process is "broken" when it is unfair to them. Unfair means that a person could have done the job well, but cannot get hired. Ie, if the candidate is a "false negative" then the process is broken. Anyway... When things become systemic, the "brokenness" becomes acute to a candidate. If whiteboards (your architecture version, Google's CS version or any other version) are prevelant and you suck at them... you can't get hired. There are people who suck at your test (whatever it is) but would be good at the job. Your proxy is a biased against some people, every proxy is. Like I said, a lot of things are like this. One side is working the numbers game, the other side isn't. Insurance markets, college entrance, executive appointments, PayPal's fraudster detection (bastards!), credit scores, investment (even startup investment)...
- braythwayt 8y ago
  I agree that most companies don't care about false negatives. The problem is that very few companies know how much false negatives are costing them, so it is very difficult to evaluate whether the false negatives are—cough—a negligible tradeoff against weeding out the false positives. False positives are right in your face. But it is nearly impossible to systematically keep track of the candidates that aren't hired to see if they are successful elsewhere. So people lean towards eliminating false positives at all costs. It's another variation on "Looking for the watch where the light is better."
ugh123 8y ago
> Asking someone to code on a whiteboard is stupid I think this is largely the point.
- badloginagain 8y ago
  Whiteboards should be used for what they're good at: Visually explaining ideas/solutions on an abstract level. They are terrible at compiling and syntax checking. Theoretically you should already know whether someone can do the physical code part. That problem is largely solved for and don't require in-house interview. In-house interview should be used for c̶o̶n̶f̶i̶r̶m̶a̶t̶i̶o̶n̶ b̶i̶a̶s̶ ̶f̶o̶r̶ a̶g̶e̶/̶r̶a̶c̶e̶/̶g̶e̶n̶d̶e̶r̶ determining if the candidate can think/design/solve for the domain space they're being hired into. A whiteboard is a really good tool for assisting in that.
- jamesmela 8y ago
  When I worked at http://zipcodedownload.com http://zipcodedownload.com we constantly used whiteboards to code. That, of course, is when we had a parent company. Now that we are independent its gone by the wayside. Don't like it as well.
mrep 8y ago
They seem to be starting to get that. I recently interviewed with a few companies including google and all of them provided a computer for me to type out my code in the interviews.
thirduncle 8y ago
The reason they are important is that they are part of every engineers day-to-day work. We use them to collaborate and design and understand. Hey if they work for you, that's great. But the simple fact is that they don't fit everyone's brain. And that there are other tools available to accomplish precisely the same ends -- some of which have many advantages over whiteboards, in fact. Like these things known as "pen" and "paper", for example. So this idea that they're part of "every engineer's" day-to-day work is, quite simply, disconnected from reality. I do agree with you, however, that the problem lies not in the whiteboards themselves but in the way they've used. Which has truly been an epic fail.
- TooBrokeToBeg 8y ago
  > So this idea that they're part of "every engineer's" day-to-day work is, quite simply, disconnected from reality. > Like these things known as "pen" and "paper", for example. When you need to share this pen and paper, you use a whiteboard. I don't understand this hate for whiteboards, which are a cross-industry cross-profession standard (including medical) when collaborating. One of the more interesting things I have noticed is that happy engineers have a little free time each day. They aren't under crushing pressure at all times. To this end, it's very common for whiteboards to accumulate drawings and doodles. This is often turned into "the elaboration game" where one doodle is built upon (by a little or a lot) every now and then. This is probably because coding is problem solving, but also because it's a creative endeavor. Engineers who are happy tend to work around other happy engineers and those engineers are all creative with free time.
  - thirduncle 8y ago
    I don't understand this hate for whiteboards, What's not to hate? * unless both the board and markers are of very high quality, the boards tend to stain over time * as do your fingers * and the markers dry up, and the erasers get less useful as well (if they're available at all) * you have to erase other people's crap (or wonder / ask if it's worth saving) first * the dizziness that results having to turn back and forth between the board and your audience (that is if you don't end up simply talking into the whiteboard most of the time) * and from stooping to pick up the pens / erasers / pen caps all the time * and all of this, mixed with all those indelible memories of crappy interview experiences I'll take pen and paper any day which are a cross-industry cross-profession standard Along with horrible interview experiences unfortunately.
scarface74 8y ago
Therefore, if a candidate can't whiteboard a design, solution, architecture, etc. in a manner that other engineers can understand it, they are going to struggle. If that's the kind of whiteboarding you do, no problem. But, don't ask me to write a merge sort in C# (been there done that). If you ask me to sort a list in C#, I'm going to write: sortedList = employeeList.OrderBy(e => e.LastName + " " + e.FirstName).ToList();
- hinkley 8y ago
  I’ve been in too many NIH situations and when someone asks me one of these questions, often my mind isn’t on the solution. Im thinking about if there’s a reason they asked the question, and maybe this was a mistake. I get so hung up on this it’s changed how I ask the question. The last time I asked a sort question, all I wanted was a compound comparator. And even then I couched it as “we want the rest endpoint to support sort criteria so we can do a top five list, but to sell the idea, we are going to sort in the UI for now. Give me some code to do that.”
  - scarface74 8y ago
    I wouldn't even bother remembering that pattern. With R# Generate Code -> create Relationsl Comparison and click on the properties that I want to use for comparison.
rifung 8y ago
> This isn't how we use whiteboards every day so why should a candidate be expected to use them this way during an interview. I work at Google, opinions are my own. I think your assumption that Google interviews based on what you will do on the job is wrong. The reality is that for most SWE positions, we can't assume you will know the things you'd be using for the job because of all the internal tools. Thus, algorithm interviews are more or less a proxy for some combination of general intelligence and coding questions. I'm not saying it's perfect and there are many things I don't like about it, but I think it's important to know what the goals are when making a critique of whether the process meets those goals.
- hueving 8y ago
  > more or less a proxy for some combination of general intelligence and coding questions. It's a proxy for one particular style of coding questions: leetcode. It's nothing more, nothing less. Calling it a proxy for general intelligence or coding in general is a joke. That's propaganda passed around the company to convince people that the practice should be continued. It strokes the employees own egos to think they passed some magic intelligence test so it motivates them to keep repeating that it measures intelligence/skill.
  - rifung 8y ago
    Well, maybe I should have said it was an attempt at a proxy for general intelligence? For what it's worth, I agree with you. When people start studying for interview questions, then something is probably wrong..
    - ska 8y ago
      That's true. On the other hand, it's okay to target sufficient but not necessary. False negatives can be fine, so long as you are finding enough true positives. Even if you are systemically missing out on a sub-pool who are good, it's not necessarily a bad thing - particularly if you are realistic about its limitations. To my mind the real problem isn't that you might miss good people (you will) but that if your filter is too constrained the good people you find might be too homogeneous.
codegeek 8y ago
This guy/gal gets it.
bitL 8y ago
> the way Google and other companies use whiteboards is an epic fail. They are optimizing completely different metrics than you do. They want crème de la crème developers that are perfectly trained not to think about certain classes of problems and waste time there but instantly come with acceptable answers, immediately recognizing the structure of the problem and having the ability to faultlessly transform it into a piece of code without a debugger. It allows the training from the best universities to shine. The problem is when everybody starts doing the same, but without the prestige, salary, equity and lifestyle that Google provides.
- thirduncle 8y ago
  The problem is when everybody starts doing the same, but without the prestige, salary, equity and lifestyle that Google provides. Or without actually needing to problems that even remotely resemble the kinds of problems that Google (sometimes) solves.
iteriteratedone 8y ago
Some engineers think that whiteboarding is not clear enough ... that code snipts are better. The key about whiteboarding is it take away all the specific syntax and gets to the heart of the understanding the logic. Thats what collaberation is for, i think many young engineers that only code with an ide are nervious whrn they dont have autocomplete available and they lose focus on the core logic. Programmerd used to write on paper ... this entire process (coding without the ide/search engine) is lost. But this is the part where the programmer shoes their strength in logic ... not syntax memory.
bostik 8y ago
> Asking someone to code on a whiteboard is stupid. I've started to turn this around and so far our senior candidates have loved the experience. (I only wish I had come up with the idea.) Instead of asking to write code on a whiteboard and solve an arbitrary problem, couple of our engineers came up with an inverted problem. And ever since seeing it in practice, I've been trying to introduce it to every interview I can think of. We write a piece of code on the whiteboard, and then ask the candidate to review it, as well as modify it to better suit the problem and context. This way the question turns into a discussion on design, constraint exploration, service expectations and externalities. Hell, sometimes it even goes into deep language design issues. Sure enough, it still measures a level coding skills but puts a much higher emphasis on understanding what the problem and its scope really is. It's also a lot of fun.
- hoistbypetard 8y ago
  I really like that idea and plan to steal it next time it seems useful. Thanks!
  - bostik 8y ago
    Go ahead!
lmilcin 8y ago
I agree. The point is not to have or not have the whiteboard during interview but how and what it is being used for. The best way I found to interview candidates is to have few different discussions. One of the discussions I like to have is to try and solve some kind of problem that you could potentially have in real life. I am solving problems with people this way on a daily basis so this lets me observe candidate in a setting that is already familiar to me and hopefully to the candidate. The whiteboard is then used exactly as in real life -- as an tool to visualize and communicate ideas and hold it as a kind of cache and reminder for the duration of the discussion. The whiteboard is there during interview but I will not require candidate to use it. If I have trouble understanding the idea I may ask "ok, I can't visualize this, could you maybe draw it for me?" Nobody programs on whiteboard in real life. If I need to program for presentation, for example to train my team on some topic, I will bring laptop.
zackify 8y ago
Couldn’t disagree more. I hate whiteboarding and I never do it. Verbal explanations and pair programming work just fine. I feel slowed down having to write out on a whiteboard when I could instead write some dummy code to get a point across. It just seems crazy to assume all developers everywhere must be good at white boarding. I tend to move my hand faster than I can hand write, which is why I like typing for all forms of explanation. Especially since I’m on a full remote team, whiteboarding would be really weird.
- linkregister 8y ago
  I can't recall ever having written actual code on a whiteboard in the course of doing actual work. I have, many times, sketched out a system's architecture or worked out some weird process using boxes and arrows. I'm sure a shared digital sketchpad would accomplish the same thing for remote workers.

andrewstuart2 8y ago

I've legitimately used whiteboards to pseudocode while discussing architecture with teammates plenty of times before. Does it compile? No. But the point is that I can more easily demonstrate the benefits of an approach with some concrete pseudocode to help grok the proposed algorithm. As an aside, if you've never done systems design or pseudocode on a Smartboard, you're really missing out. Copy/paste, duplicating a slide, recalling earlier slides, etc. Man, that's the way to design a system with quick iteration but still no worry of losing your work.

Jemmeh 8y ago
Yes but I think the point is a lot of interviewers do not go for pseudocode. They want syntax perfect solutions on a whiteboard.
- ianhawes 8y ago
  This. When interviewers feel that the question was not hard enough or that they didn't like the answer, they often fall back on "you're missing a semicolon".
- brokenwren 8y ago
  Yes. That's essentially what I was getting at. Asking someone to code accurately on a whiteboard is nonsense. When I interviewed at Google, they asked me if my whiteboard code would compile. I said, "give me a laptop and I'll tell you". I don't think they liked that answer. ;)
  - bsk26 8y ago
    When I ask candidates if their whiteboard code compiles, it's a gentle hint that there are major structural issues, or an opportunity for them to point out the parts that are psuedocode-y. In general I don't include whether the code compiles (mostly JS, so "runs") in feedback unless it is amazingly perfect or really far off. This seems standard.
deleted 8y ago
[deleted]

extralego 8y ago

Can you point to examples of how you do use whiteboards? I am a self-taught programmer with my own way of noting design strategies and having a tough time finding examples of this.

organsnyder 8y ago
Not OP, but I use whiteboards to sketch system designs and things like that. For instance, I'd sketch out the path that a request might take through a complicated system (intake via a REST service, flows through a queue, consumed by another service, persisted to a database...). That's the sort of thing that I would be comfortable doing as part of an interview—though I wouldn't expect a junior developer to be able to do it. AFAICT, the backlash is around interviews where candidates are asked to write code (or pseudocode) on a whiteboard. Being able to implement bubble sort on a whiteboard does not correlate very well with being able to deliver business value, in my experience.
- xur17 8y ago
  > Being able to implement bubble sort on a whiteboard does not correlate very well with being able to deliver business value, in my experience. To add to this, it's being able to write code on a whiteboard in a high pressure situation while talking about every step you're taking. Over time I've gotten more comfortable with this, but mainly by doing more interviews, not by getting better at my job.
  - Azeolus 8y ago
    If you ever find yourself in a situation that Broadcast television would have us believe, you'll be excellent at coding that hotfix into a real time system as the president of the United States looks over your shoulder.
  - extralego 8y ago
    When I was younger, this would probably make me feel insufficient but I have done enough ‘learning stuff’ by now that I expect this kind of comfort to only come with experience.

romaniv 8y ago

Whiteboards are okay for ad-hoc lists and diagrams, but they are a poor medium for coding. Some of the biggest productivity gains I've had over the years were related switching from "writing code down" to "thinking in code" mentality and abandoning linear, paper-like ways of thinking, which hindered me when I was in college. For anyone who believes that paper and whiteboards are "good enough" for coding, I highly recommend watching some of Victor Bret's or Alan Kay's talks. Pretty much any of them. They consistently touch on the subject of dynamic media as a way to empower people to... well, think better for the lack of better terms.

tlarkworthy 8y ago
I think you have got the wrong lesson off those guys. They are about engaging the spatio-visual systems. The whiteboard is the first step away from text towards that. Obviously they want to go a lot further than a whiteboard, but the fact that you can draw things, circle things, wipe things off makes a whiteboard a much more dynamic media than an ASCII interface. I think you would find them pro-whiteboard for thinking design.
- romaniv 8y ago
  >I think you have got the wrong lesson off those guys. They are about engaging the spatio-visual systems. The whiteboard is the first step away from text towards that. Not when you are literally writing code on it.
  - rando444 8y ago
    I guess I'll just point out the distinction.. there's an obvious gap between writing code and writing pseduo code / logic structures. And there's nothing wrong with whiteboarding pseudo-code.
curuinor 8y ago
bret's apparatus in dynamicland is literal pieces of paper embodying code, which, quote, "also are fully functional pieces of paper".

notheguyouthink 8y ago

As an aside, any resources for learning whiteboard techniques? Not specifically solving algorithms on whiteboards, but designing and conveying information during architecture planning/etc? I feel like there's two angles to this; 1. understanding complex algorithms commonly used as tests. 2. understanding how to convey information on whiteboards efficiently, common paradigms, etc. #2 is what I think I'd actually enjoy improving. #1 is just SAT style stuff that I infrequently use in my day job and serves as an annoyance more than anything.

vkou 8y ago

> That being said, the way Google and other companies use whiteboards is an epic fail. Asking someone to code on a whiteboard is stupid. Asking them to solve algorithm puzzlers on a whiteboard is lame. This isn't how we use whiteboards every day so why should a candidate be expected to use them this way during an interview. Every candidate I interview has the choice between coding on a whiteboarding, and coding in a text editor with rudimentary code formatting. I really like it when people code in the text editor, because that's one less thing I have to transcribe in my interview evaluation. Regardless of whether they will choose the whiteboard or the laptop, I have never, and will never mark people down for typos, confusing .length with .size, a missed semicolon, or any other petty bullshit that isn't pertinent to the problem. I'm not hiring a compiler.

contras1970 8y ago
not that i'd feel like my success in interviews hinges on this, i just find this very refreshing. where do you work, and are you hiring?
- vkou 8y ago
  Google, and yes, and unfortunately every interviewer is different, as all the bad experiences people post about can attest to.

dalbasal 8y ago

An important thing to remember is that broken/not-broken is completely different for each side of that desk: candidate person & hiring person. This is always the case for selection steps. The employer (or school, etc) wants to make successful hires and to avoid bad ones. False positives are always a big problem. False negatives are usually much smaller one. A process is good if it produces good hires, and no bad ones. In principle, a process that hires 3 good candidates from a pool containing 5 good candidates and lots of bad ones is good. Avoiding bad hires is paramount. Missing 2 good hires is not as bad as making one bad hire, not near as bad usually. Most employers don't care about false negatives at all. If they do, they probably care most about missing really good outlier hires, not mistakenly selecting the 5th best candidate instead of the 4th. The only reason to care is fairness. People instintively care about fairness so this affects practices but it's not nearly like false positives. Employers that need huge volume (eg, the army) are the only ones that care about false positives as much as candidates do. The candidate (student etc.) generally feels the process is "broken" when it is unfair to them. Unfair means that a person could have done the job well, but cannot get hired. Ie, if the candidate is a "false negative" then the process is broken. Anyway... When things become systemic, the "brokenness" becomes acute to a candidate. If whiteboards (your architecture version, Google's CS version or any other version) are prevelant and you suck at them... you can't get hired. There are people who suck at your test (whatever it is) but would be good at the job. Your proxy is a biased against some people, every proxy is. Like I said, a lot of things are like this. One side is working the numbers game, the other side isn't. Insurance markets, college entrance, executive appointments, PayPal's fraudster detection (bastards!), credit scores, investment (even startup investment)...

braythwayt 8y ago
I agree that most companies don't care about false negatives. The problem is that very few companies know how much false negatives are costing them, so it is very difficult to evaluate whether the false negatives are—cough—a negligible tradeoff against weeding out the false positives. False positives are right in your face. But it is nearly impossible to systematically keep track of the candidates that aren't hired to see if they are successful elsewhere. So people lean towards eliminating false positives at all costs. It's another variation on "Looking for the watch where the light is better."

ugh123 8y ago

> Asking someone to code on a whiteboard is stupid I think this is largely the point.

badloginagain 8y ago
Whiteboards should be used for what they're good at: Visually explaining ideas/solutions on an abstract level. They are terrible at compiling and syntax checking. Theoretically you should already know whether someone can do the physical code part. That problem is largely solved for and don't require in-house interview. In-house interview should be used for c̶o̶n̶f̶i̶r̶m̶a̶t̶i̶o̶n̶ b̶i̶a̶s̶ ̶f̶o̶r̶ a̶g̶e̶/̶r̶a̶c̶e̶/̶g̶e̶n̶d̶e̶r̶ determining if the candidate can think/design/solve for the domain space they're being hired into. A whiteboard is a really good tool for assisting in that.
jamesmela 8y ago
When I worked at http://zipcodedownload.com http://zipcodedownload.com we constantly used whiteboards to code. That, of course, is when we had a parent company. Now that we are independent its gone by the wayside. Don't like it as well.

mrep 8y ago

They seem to be starting to get that. I recently interviewed with a few companies including google and all of them provided a computer for me to type out my code in the interviews.

thirduncle 8y ago

The reason they are important is that they are part of every engineers day-to-day work. We use them to collaborate and design and understand. Hey if they work for you, that's great. But the simple fact is that they don't fit everyone's brain. And that there are other tools available to accomplish precisely the same ends -- some of which have many advantages over whiteboards, in fact. Like these things known as "pen" and "paper", for example. So this idea that they're part of "every engineer's" day-to-day work is, quite simply, disconnected from reality. I do agree with you, however, that the problem lies not in the whiteboards themselves but in the way they've used. Which has truly been an epic fail.

TooBrokeToBeg 8y ago
> So this idea that they're part of "every engineer's" day-to-day work is, quite simply, disconnected from reality. > Like these things known as "pen" and "paper", for example. When you need to share this pen and paper, you use a whiteboard. I don't understand this hate for whiteboards, which are a cross-industry cross-profession standard (including medical) when collaborating. One of the more interesting things I have noticed is that happy engineers have a little free time each day. They aren't under crushing pressure at all times. To this end, it's very common for whiteboards to accumulate drawings and doodles. This is often turned into "the elaboration game" where one doodle is built upon (by a little or a lot) every now and then. This is probably because coding is problem solving, but also because it's a creative endeavor. Engineers who are happy tend to work around other happy engineers and those engineers are all creative with free time.
- thirduncle 8y ago
  I don't understand this hate for whiteboards, What's not to hate? * unless both the board and markers are of very high quality, the boards tend to stain over time * as do your fingers * and the markers dry up, and the erasers get less useful as well (if they're available at all) * you have to erase other people's crap (or wonder / ask if it's worth saving) first * the dizziness that results having to turn back and forth between the board and your audience (that is if you don't end up simply talking into the whiteboard most of the time) * and from stooping to pick up the pens / erasers / pen caps all the time * and all of this, mixed with all those indelible memories of crappy interview experiences I'll take pen and paper any day which are a cross-industry cross-profession standard Along with horrible interview experiences unfortunately.

scarface74 8y ago

Therefore, if a candidate can't whiteboard a design, solution, architecture, etc. in a manner that other engineers can understand it, they are going to struggle. If that's the kind of whiteboarding you do, no problem. But, don't ask me to write a merge sort in C# (been there done that). If you ask me to sort a list in C#, I'm going to write: sortedList = employeeList.OrderBy(e => e.LastName + " " + e.FirstName).ToList();

hinkley 8y ago
I’ve been in too many NIH situations and when someone asks me one of these questions, often my mind isn’t on the solution. Im thinking about if there’s a reason they asked the question, and maybe this was a mistake. I get so hung up on this it’s changed how I ask the question. The last time I asked a sort question, all I wanted was a compound comparator. And even then I couched it as “we want the rest endpoint to support sort criteria so we can do a top five list, but to sell the idea, we are going to sort in the UI for now. Give me some code to do that.”
- scarface74 8y ago
  I wouldn't even bother remembering that pattern. With R# Generate Code -> create Relationsl Comparison and click on the properties that I want to use for comparison.

rifung 8y ago

> This isn't how we use whiteboards every day so why should a candidate be expected to use them this way during an interview. I work at Google, opinions are my own. I think your assumption that Google interviews based on what you will do on the job is wrong. The reality is that for most SWE positions, we can't assume you will know the things you'd be using for the job because of all the internal tools. Thus, algorithm interviews are more or less a proxy for some combination of general intelligence and coding questions. I'm not saying it's perfect and there are many things I don't like about it, but I think it's important to know what the goals are when making a critique of whether the process meets those goals.

hueving 8y ago
> more or less a proxy for some combination of general intelligence and coding questions. It's a proxy for one particular style of coding questions: leetcode. It's nothing more, nothing less. Calling it a proxy for general intelligence or coding in general is a joke. That's propaganda passed around the company to convince people that the practice should be continued. It strokes the employees own egos to think they passed some magic intelligence test so it motivates them to keep repeating that it measures intelligence/skill.
- rifung 8y ago
  Well, maybe I should have said it was an attempt at a proxy for general intelligence? For what it's worth, I agree with you. When people start studying for interview questions, then something is probably wrong..
  - ska 8y ago
    That's true. On the other hand, it's okay to target sufficient but not necessary. False negatives can be fine, so long as you are finding enough true positives. Even if you are systemically missing out on a sub-pool who are good, it's not necessarily a bad thing - particularly if you are realistic about its limitations. To my mind the real problem isn't that you might miss good people (you will) but that if your filter is too constrained the good people you find might be too homogeneous.

codegeek 8y ago

This guy/gal gets it.

bitL 8y ago

> the way Google and other companies use whiteboards is an epic fail. They are optimizing completely different metrics than you do. They want crème de la crème developers that are perfectly trained not to think about certain classes of problems and waste time there but instantly come with acceptable answers, immediately recognizing the structure of the problem and having the ability to faultlessly transform it into a piece of code without a debugger. It allows the training from the best universities to shine. The problem is when everybody starts doing the same, but without the prestige, salary, equity and lifestyle that Google provides.

thirduncle 8y ago
The problem is when everybody starts doing the same, but without the prestige, salary, equity and lifestyle that Google provides. Or without actually needing to problems that even remotely resemble the kinds of problems that Google (sometimes) solves.

iteriteratedone 8y ago

Some engineers think that whiteboarding is not clear enough ... that code snipts are better. The key about whiteboarding is it take away all the specific syntax and gets to the heart of the understanding the logic. Thats what collaberation is for, i think many young engineers that only code with an ide are nervious whrn they dont have autocomplete available and they lose focus on the core logic. Programmerd used to write on paper ... this entire process (coding without the ide/search engine) is lost. But this is the part where the programmer shoes their strength in logic ... not syntax memory.

bostik 8y ago

> Asking someone to code on a whiteboard is stupid. I've started to turn this around and so far our senior candidates have loved the experience. (I only wish I had come up with the idea.) Instead of asking to write code on a whiteboard and solve an arbitrary problem, couple of our engineers came up with an inverted problem. And ever since seeing it in practice, I've been trying to introduce it to every interview I can think of. We write a piece of code on the whiteboard, and then ask the candidate to review it, as well as modify it to better suit the problem and context. This way the question turns into a discussion on design, constraint exploration, service expectations and externalities. Hell, sometimes it even goes into deep language design issues. Sure enough, it still measures a level coding skills but puts a much higher emphasis on understanding what the problem and its scope really is. It's also a lot of fun.

hoistbypetard 8y ago
I really like that idea and plan to steal it next time it seems useful. Thanks!
- bostik 8y ago
  Go ahead!

lmilcin 8y ago

I agree. The point is not to have or not have the whiteboard during interview but how and what it is being used for. The best way I found to interview candidates is to have few different discussions. One of the discussions I like to have is to try and solve some kind of problem that you could potentially have in real life. I am solving problems with people this way on a daily basis so this lets me observe candidate in a setting that is already familiar to me and hopefully to the candidate. The whiteboard is then used exactly as in real life -- as an tool to visualize and communicate ideas and hold it as a kind of cache and reminder for the duration of the discussion. The whiteboard is there during interview but I will not require candidate to use it. If I have trouble understanding the idea I may ask "ok, I can't visualize this, could you maybe draw it for me?" Nobody programs on whiteboard in real life. If I need to program for presentation, for example to train my team on some topic, I will bring laptop.

zackify 8y ago

Couldn’t disagree more. I hate whiteboarding and I never do it. Verbal explanations and pair programming work just fine. I feel slowed down having to write out on a whiteboard when I could instead write some dummy code to get a point across. It just seems crazy to assume all developers everywhere must be good at white boarding. I tend to move my hand faster than I can hand write, which is why I like typing for all forms of explanation. Especially since I’m on a full remote team, whiteboarding would be really weird.

linkregister 8y ago
I can't recall ever having written actual code on a whiteboard in the course of doing actual work. I have, many times, sketched out a system's architecture or worked out some weird process using boxes and arrows. I'm sure a shared digital sketchpad would accomplish the same thing for remote workers.