[the_reformation]

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]

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.

[ksk]

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.

[blamestross]

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]

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]

Ultimately, I'm not sure what form of interview process would satisfy you.

[novok]

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]

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]

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.

[blamestross]

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]

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.

[louthy]

Not every approach is bad. As an interviewer myself I find that just talking to the person as a human being and asking them about their current work, previous work, and interests tends to expose nearly everything I need to know. I initially just want to see if the person is likely to be a good fit for the company. This can be triggered by attitude, arrogance, etc.

Engineering-wise I can focus on any one thing they bring up and ask them to explain in more depth, this then becomes a dialogue, which is vital I think, because they're interviewing me and my company as much as I am interviewing them. I intentionally don't try to catch them out, in fact the opposite, a candidate at ease is the one that opens up more and will give you more insight into who they are and what they are about than any whiteboard exercise.

I'll then talk about the requirements for the role they're applying for and try to see if their knowledge covers what we need. Again, just a dialogue.

If that first interview goes well, then I will ask for examples of code they have written, or set them a test to do in their own time if they have nothing of their own to show. Granted that takes some of their time, but it only happens if they're being seriously considered, and importantly (I think) allows them to use their own tools, in their own time, in their own way, this gives them a chance to shine.

This might not work at FAANG scale, I dunno, I find the idea of working at any organisation like that a pretty miserable one. But talking to someone in a respectful way, rather than putting them in an uncomfortable situation that bears no resemblance to what their day-to-day would be, shouldn't be hard to scale.

Although, I suspect much of these issues come about because of the inadequacies of the interviewers rather than the candidates, they're hiding behind tricks, gotchas, and memory tests, because possibly they don't have the range themselves to extract something meaningful from the candidate in order to rank them.

[0x445442]

This is almost exactly my approach. I’ve interviewed 100-200 engineers in my career and hired 10-15 of those. Not one of those hires was a failure and I didn’t need to incorporate puzzles as part of the interview process. If you’re an experienced engineer with a history of designing and delivering business solutions for multiple domains you should never need to ask trivial data structure and algorithms questions that can be easily looked up if they’re ever needed.

[jjav]

Exactly this. This has been my approach for a few decades and it works wonderfully well. Making the interview cooperative instead of confrontational is important. The key to success is evaluating the person based on their actual experience instead of their inability to do some whiteboard monkeydance that's completely unrelated to the job.

[Aeolun]

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?

[mdifrgechd]

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.

[wan23]

The important distinction here is that a doctor has to complete a residency only once in their lifetime, not every time they apply for a job.

[ThrowawayR2]

Sure, but residency lasts 3 to 7 years and it is often harsh. I'll take the whiteboarding anyday.

[scarmig]

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]

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.

[nicoburns]

> 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]

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]

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.

[bradlys]

> 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!"