[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.

[mixmastamyk]

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]

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.