7 ms·

As somebody who's somewhere between mediocre to good at whiteboard interviews (passed the loop at 1 FAANG, rejected by the rest), I think they're pretty solid.

As somebody who's somewhere between mediocre to good at whiteboard interviews (passed the loop at 1 FAANG, rejected by the rest), I think they're pretty solid. Most programming challenges, even at FAANG-scale, ultimately decompose into some family of classic interview problems (usually a graph or a hash table.) Everything else I do at work is implementation or stack specific. The average programmer will pick it up with enough exposure. But problem solving is somewhat binary (yes I realize thats an oxymoron) and not easily pick-up-able, at least on the time horizon a hiring manager wants to deal with. I realized this when I got a lot better at whiteboard interviews after a FAANG job for a couple years. A coding challenge that I took the full hour on and bombed out of college was now done in twenty. I just picked up the problem solving intuition by writing a ton of code.

louthy 6y ago
How much code do you normally write on whiteboards in front of people? It is such an artificial and for some, confrontational, way of problem solving, that it just filters for people who can stand in-front of whiteboards. It's a discriminatory process that shows pretty much nothing about the individual's capacity to function as a software engineer in a team.
- blamestross 6y ago
  I realized 4 years of teaching in grad-school precisely prepared me for whiteboard interviews. I literally spent 3 days a week working out problems on whiteboards in front of bored/annoyed people.
  - mixmastamyk 6y ago
    Good practice, yes. However what if those bored/annoyed people decided you were a failure and couldn't feed your family if a single unseen problem is not done in 15 minutes?
    - mcguire 6y ago
      Ultimately, I'm not sure what form of interview process would satisfy you.
      - novok 6y ago
        A work sample test set that is restricted to material relevant for the job you are doing? Only writing code on a laptop text editor? Ex: Code this mini app, code this mini api, figure out why this code is buggy, design this app / backend service that does this, why did you choose that, etc.
      - mixmastamyk 6y ago
        When I started my career a simple interview and can you start Monday sufficed. You’d be be let go by Wednesday if you couldn’t produce. I’d return to that, it worked. Perhaps with a few harder questions about hexadecimal and a code review.
        jefftk 6y ago
        Many people move across the country or even between countries for these jobs, especially to the SF Bay Area. You want more assurance than that before you uproot your life. Additionally, the time to spin up at a mature company with it's on tooling and enormous amounts of existing code can be really long. I don't think you can generally tell in two days whether a person is going to do well.
        mixmastamyk 6y ago
        If you can do common things well, you can learn a codebase. Remote contracts are a thing as well. I'm not sure international hires are relevant to the discussion, they are at best a sliver of the whole.
        blamestross 6y ago
        The biggest problem with this is that in bigger companies it is assumed you will need up to a year to "onboard" and that your first first few months will be drinking from a firehose of custom local knowledge and infrastructure details. We don't expect new hires to be productive for at least a month or three after hire.
- scarmig 6y ago
  It's not a question of whether it provides a perfect signal. It's a question of how the signal it provides compares to alternatives. Say what you will about whiteboards, but every other interview structure has its own issues, including being artificial, particularly at scale.
  - Aeolun 6y ago
    If a doctor can be interviewed without being asked to operate on people, or an architect without being asked to build a home, can we not interview without asking someone to write code?
    - scarmig 6y ago
      Moving to a doctor-style credential model would probably make the interview process less intense. But it also adds years of additional education and certifications. And it's unclear whether it would cause a net reduction of stress and pointless studying: pre-med and medical students aren't known for their laid back progression to gainful employment. A lot of the people here would clearly be shocked to discover just how adversarial jobs outside of software engineering can be.
    - stormbrew 6y ago
      Honestly I think this is a poor analogy. It's considerably easier to verify the work history of a surgeon or an architect. Their work is prominent and difficult to plagiarize. Trades might be more applicable, and in trades you likewise have certain kinds of certification or even a guild-like system to keep skills and performance visible and consistent. There's not really any equivalent in programming (though there is in IT more broadly). Even a university degree is not really any particular proof of an ability to code, a lot of programs can be taken without having to write much code solo. Programming is usually done collaboratively, either implicitly (through the use of base libraries) or explicitly (coworkers, group projects) and there are definitely people who freeride on those collaborations to a great extent.
    - mdifrgechd 6y ago
      I'm not super familiar with doctors' career progression but as I understand they have a residency which is basically a super long training / interview. And I bet to become a surgeon at an elite institution you have spent a lot of time being watched doing your job. Also another good example is cooks, who get hired based on working a shift unpaid to see how they fit with the team. Asking for a hands on demo is pretty common.
- ksk 6y ago
  I disagree. It doesn't have to be confrontational if you don't want it to be. As a manager whose used it plenty in the past, I've found it to be an excellent tool to filter out people who were smooth talkers and seemed "clued in" but didn't have the technical chops to do anything. I didn't care at all about syntax, language of choice, or anything superficial like that. All I wanted to see was how they approached a problem, not that they simply memorized a piece of trivia. Also you can ask design or high level architecture questions during a whiteboard-interview too. I have found that simply trusting someone's word is not enough, you need to verify that they can actually back it up. In the end, resume, grades, side-projects, whiteboard code, style of problem solving, feedback from previous co-workers, etc, etc, are all signals that you have to absorb and make a decision. You can't just rely on one signal.
bradlys 6y ago
> I realized this when I got a lot better at whiteboard interviews after a FAANG job for a couple years. A coding challenge that I took the full hour on and bombed out of college was now done in twenty. I just picked up the problem solving intuition by writing a ton of code. Were you perchance interviewing others while at FAANG or doing anything related to interviewing (speaking with coworkers about it, etc.)? I've seen plenty of people come out of FAANG worse at interviewing than they went in. The problems I've heard most of my peers solve at FAANG are not really that relevant to interviewing. At least, none of them are like, "Yeah, man, totally kick ass at leetcode now that I've been at Facebook for a year!"
nicoburns 6y ago
> Most programming challenges, even at FAANG-scale, ultimately decompose into some family of classic interview problems (usually a graph or a hash table.) Most problems decompose into using a graph or a hash table (or an array), not implementing one. And the hard bit is usually things like translating the business requirements, architecting code to keep it maintainable over time, and dealing with buggy / opaque 3rd party systems. Classic whiteboard interviews don't test these things at all.
dmurray 6y ago
One way to look at it is that your ability to contribute is one part familiarity with the stack, the problem domain, and the company's development process: one part "generic ability/competence". You're going to learn the first part on the job. It's rare - especially in Google's hiring - that you want to hire someone for their deep familiarity with the tech stack or problem domain. So you select for the second part. But your test for the second part still involves specialising in some process. Take home tests or pair programming exercises aren't "culture-blind" any more than whiteboard tests. So a large important part of the industry standardised on a "development process" of writing code on a whiteboard, a "business domain" of advanced-undergrad-level data structures, and a "tech stack" of "pick any language you want, or a reasonably rigorous pseudocode". If everyone learns that to the same degree, the remaining differences between the candidates are mostly in part 2. There are some downsides that get trotted out on HN every time: you may reject someone who's really good but didn't take the time to focus on undergrad data structures, you may reject someone who is particularly bad at whiteboard stuff (typically due to nerves), your process is easier to train for recent CS grads from good universities. But every system has downsides. This one is reasonable for Google and not-terrible for you, but you may be able to do much better by focusing on one of the sets of people Google's process underrates.
jcranmer 6y ago
So, in my job, I've had a few, rare reasons to actually push into developing new algorithms for problems nobody has had to solve before. Literally nothing I've had to do for leetcode or whiteboarding has been useful there. The more common instance I've had to do is plug-and-play existing algorithmic design on existing data structures that are well-represented in libraries. Need a hashtable or an auto-growing array? That's in virtually every standard library. Balanced search trees are also pretty common, although (in my experience) actually quite rare in practice. Graphs are usually not in standard libraries, but graph libraries are pretty standard in languages: there's petgraph in Rust, Boost has graphs in C++, and Python has networkx. Just pop those libraries in, and you don't need to bother implementing anything basic like traversals. The only things exotic enough that I've had to personally implement them myself are Johnson's algorithm for elementary circuits and the union-find datastructure. Both times, I've had the algorithm in pseudocode right in front of me when writing the code, so I've never had to actually memorize how these things work.

louthy 6y ago

How much code do you normally write on whiteboards in front of people? It is such an artificial and for some, confrontational, way of problem solving, that it just filters for people who can stand in-front of whiteboards. It's a discriminatory process that shows pretty much nothing about the individual's capacity to function as a software engineer in a team.

blamestross 6y ago
I realized 4 years of teaching in grad-school precisely prepared me for whiteboard interviews. I literally spent 3 days a week working out problems on whiteboards in front of bored/annoyed people.
- mixmastamyk 6y ago
  Good practice, yes. However what if those bored/annoyed people decided you were a failure and couldn't feed your family if a single unseen problem is not done in 15 minutes?
  - mcguire 6y ago
    Ultimately, I'm not sure what form of interview process would satisfy you.
    - novok 6y ago
      A work sample test set that is restricted to material relevant for the job you are doing? Only writing code on a laptop text editor? Ex: Code this mini app, code this mini api, figure out why this code is buggy, design this app / backend service that does this, why did you choose that, etc.
    - mixmastamyk 6y ago
      When I started my career a simple interview and can you start Monday sufficed. You’d be be let go by Wednesday if you couldn’t produce. I’d return to that, it worked. Perhaps with a few harder questions about hexadecimal and a code review.
      - jefftk 6y ago
        Many people move across the country or even between countries for these jobs, especially to the SF Bay Area. You want more assurance than that before you uproot your life. Additionally, the time to spin up at a mature company with it's on tooling and enormous amounts of existing code can be really long. I don't think you can generally tell in two days whether a person is going to do well.
        mixmastamyk 6y ago
        If you can do common things well, you can learn a codebase. Remote contracts are a thing as well. I'm not sure international hires are relevant to the discussion, they are at best a sliver of the whole.
      - blamestross 6y ago
        The biggest problem with this is that in bigger companies it is assumed you will need up to a year to "onboard" and that your first first few months will be drinking from a firehose of custom local knowledge and infrastructure details. We don't expect new hires to be productive for at least a month or three after hire.
scarmig 6y ago
It's not a question of whether it provides a perfect signal. It's a question of how the signal it provides compares to alternatives. Say what you will about whiteboards, but every other interview structure has its own issues, including being artificial, particularly at scale.
- Aeolun 6y ago
  If a doctor can be interviewed without being asked to operate on people, or an architect without being asked to build a home, can we not interview without asking someone to write code?
  - scarmig 6y ago
    Moving to a doctor-style credential model would probably make the interview process less intense. But it also adds years of additional education and certifications. And it's unclear whether it would cause a net reduction of stress and pointless studying: pre-med and medical students aren't known for their laid back progression to gainful employment. A lot of the people here would clearly be shocked to discover just how adversarial jobs outside of software engineering can be.
  - stormbrew 6y ago
    Honestly I think this is a poor analogy. It's considerably easier to verify the work history of a surgeon or an architect. Their work is prominent and difficult to plagiarize. Trades might be more applicable, and in trades you likewise have certain kinds of certification or even a guild-like system to keep skills and performance visible and consistent. There's not really any equivalent in programming (though there is in IT more broadly). Even a university degree is not really any particular proof of an ability to code, a lot of programs can be taken without having to write much code solo. Programming is usually done collaboratively, either implicitly (through the use of base libraries) or explicitly (coworkers, group projects) and there are definitely people who freeride on those collaborations to a great extent.
  - mdifrgechd 6y ago
    I'm not super familiar with doctors' career progression but as I understand they have a residency which is basically a super long training / interview. And I bet to become a surgeon at an elite institution you have spent a lot of time being watched doing your job. Also another good example is cooks, who get hired based on working a shift unpaid to see how they fit with the team. Asking for a hands on demo is pretty common.
ksk 6y ago
I disagree. It doesn't have to be confrontational if you don't want it to be. As a manager whose used it plenty in the past, I've found it to be an excellent tool to filter out people who were smooth talkers and seemed "clued in" but didn't have the technical chops to do anything. I didn't care at all about syntax, language of choice, or anything superficial like that. All I wanted to see was how they approached a problem, not that they simply memorized a piece of trivia. Also you can ask design or high level architecture questions during a whiteboard-interview too. I have found that simply trusting someone's word is not enough, you need to verify that they can actually back it up. In the end, resume, grades, side-projects, whiteboard code, style of problem solving, feedback from previous co-workers, etc, etc, are all signals that you have to absorb and make a decision. You can't just rely on one signal.

bradlys 6y ago

> I realized this when I got a lot better at whiteboard interviews after a FAANG job for a couple years. A coding challenge that I took the full hour on and bombed out of college was now done in twenty. I just picked up the problem solving intuition by writing a ton of code. Were you perchance interviewing others while at FAANG or doing anything related to interviewing (speaking with coworkers about it, etc.)? I've seen plenty of people come out of FAANG worse at interviewing than they went in. The problems I've heard most of my peers solve at FAANG are not really that relevant to interviewing. At least, none of them are like, "Yeah, man, totally kick ass at leetcode now that I've been at Facebook for a year!"

nicoburns 6y ago

> Most programming challenges, even at FAANG-scale, ultimately decompose into some family of classic interview problems (usually a graph or a hash table.) Most problems decompose into using a graph or a hash table (or an array), not implementing one. And the hard bit is usually things like translating the business requirements, architecting code to keep it maintainable over time, and dealing with buggy / opaque 3rd party systems. Classic whiteboard interviews don't test these things at all.

dmurray 6y ago

One way to look at it is that your ability to contribute is one part familiarity with the stack, the problem domain, and the company's development process: one part "generic ability/competence". You're going to learn the first part on the job. It's rare - especially in Google's hiring - that you want to hire someone for their deep familiarity with the tech stack or problem domain. So you select for the second part. But your test for the second part still involves specialising in some process. Take home tests or pair programming exercises aren't "culture-blind" any more than whiteboard tests. So a large important part of the industry standardised on a "development process" of writing code on a whiteboard, a "business domain" of advanced-undergrad-level data structures, and a "tech stack" of "pick any language you want, or a reasonably rigorous pseudocode". If everyone learns that to the same degree, the remaining differences between the candidates are mostly in part 2. There are some downsides that get trotted out on HN every time: you may reject someone who's really good but didn't take the time to focus on undergrad data structures, you may reject someone who is particularly bad at whiteboard stuff (typically due to nerves), your process is easier to train for recent CS grads from good universities. But every system has downsides. This one is reasonable for Google and not-terrible for you, but you may be able to do much better by focusing on one of the sets of people Google's process underrates.

jcranmer 6y ago

So, in my job, I've had a few, rare reasons to actually push into developing new algorithms for problems nobody has had to solve before. Literally nothing I've had to do for leetcode or whiteboarding has been useful there. The more common instance I've had to do is plug-and-play existing algorithmic design on existing data structures that are well-represented in libraries. Need a hashtable or an auto-growing array? That's in virtually every standard library. Balanced search trees are also pretty common, although (in my experience) actually quite rare in practice. Graphs are usually not in standard libraries, but graph libraries are pretty standard in languages: there's petgraph in Rust, Boost has graphs in C++, and Python has networkx. Just pop those libraries in, and you don't need to bother implementing anything basic like traversals. The only things exotic enough that I've had to personally implement them myself are Johnson's algorithm for elementary circuits and the union-find datastructure. Both times, I've had the algorithm in pseudocode right in front of me when writing the code, so I've never had to actually memorize how these things work.