But communication on-the-fly, on-your-feet, in a high pressure environment, which is what a whiteboard test is, is not most communication.

Most communication gets thought about, drafted, revised, critiqued, socialized, ahead of distribution.

If your whiteboarding comes after hours or days of consideration and review, that sounds like a great way to vet good communicators. Otherwise, aren't you optimizing only for speed? If someone cracks a joke in the moment, they're a wit; but we only pay money to and call comedians those who worked on it for a while.

Of course the candidate is under more pressure than they would be at work - that's why we don't expect them to create a Leonardo masterpiece in front of us and we give the candidate the benefit of the doubt.

You would be surprised at how poor some of the candidates are at this. Candidates who are unable to draw a few squares on a board to describe the last thing they worked on, and candidates who have never questioned any of the work they were assigned or don't understand that there are often multiple options for a solution, each with pros and cons.

If someone can't even draw a simple diagram on a board, I don't want to have to plan and come up with highly complex solutions over whole months with them.

I think an important point is that you are assuming someone’s design communication moves along a spectrum from good to bad as you increase time pressure or stress, and so you can accordingly adjust your expectations along a spectrum and still be well-calibrated to evaluate the meaning of the candidate’s performance.

I propose it doesn’t work like that at all. Rather, if someone’s brain is loaded with time pressure or interview jitters, and they are not the type of person who thrives on stress, then it will be more like you have totally switched off the part of their brain that is good at communicating design thinking, and their performance in the interview will be entirely unrepresentative of what their performance would be in a regular day-to-day team meeting on the job.

I think the same effect is even more severe with any type of coding / mathematics / puzzle solving questions done inside a short timed session or using things like Coderpad or HackerRank.

I was on a phone interview where my anxiety crossed a threshold and my brain just shut down. I literally could not comprehend the code I had just written. For a few minutes, I forgot how to program. I've programmed for 21 years professionally, across many languages, but still fell apart. I recovered after about 5-10 minutes, but at that point it was too late. A couple hours later I went back and breezed through the problem, wrote a few test cases, and ran them without issues.

And how do you propose a removal of all stress? Shall we hire everyone and fire them if they turn out to be dreadful after a week? That would ensure EVERYONE is under pressure all the time...

Evaluate software engineering candidates the same way virtually every other skilled profession on the planet evaluates their candidates: through a series of conversational interviews that involve technical communication about their skills and past experiences, and perhaps some version of “sample work” that ideally should just come from GitHub, school project, Stack Overflow answers, etc., and only be based on some take-home (with tons of time to complete it) in the rare cases the candidate doesn’t have any samples they want to discuss with you.

I don’t understand why people keep overthinking it and believing you need any type of timed testing aspect at all.

Through many years of leading engineer hiring for my teams, a simple conversational style has helped me successfully hire effective software engineers much, much more than traditional software tests.

Imagine asking a plumber, lawyer, or tax accountant to solve a pipe problem, law problem, or accounting problem in ~40 minutes while you watch over their shoulder and iteratively add complicating details, while telling them to use some foreign interface they never use for their own work and confusing them by saying you don’t care about syntactical correctness and just want high level communication to “see how they think,” despite the very nature of the problem being rooted in sweating micro details about correctness.

Yes, exactly!

I've been in the tech (software) industry over 25 years now, nearly all of those years here in Silicon Valley. Worked in everything from 3 person startups to the largest of enterprises.

I feel good about saying I've never made a bad hire (meaning: I've never come to regret saying "hire", everyone I have given the thumbs up after an interview has turned out to be a fine contributor).

I don't ask candidates to code, I don't ask them to come up with whiteboard architectures out of the blue or any of these silly artificial techniques that don't measure anything relevant.

Here's what I do: I carefully read their resume. I have a conversation about the projects they have worked on. I encourage them to talk about what jobs/projects/tasks they liked and disliked and why. What they found easy vs. hard and why. And what they want to work on next and why.

That's it. Works extremely well.

I wish everyone would try it. You'll find it is very easy to pick out those who padded their resume. You can't actually have a meaningful conversation about what you loved and hated about working on foo if you didn't do it.

This is what take home projects or allowing someone to present their own code help fix.

Ever been in a tense meeting?

Most (almost all) verbal communication comes with time pressure.

Speak too long (ramble) and your message is lost and your coworkers are annoyed.

Don't speak fast enough and now someone else is using all the air in the room.

Yes. They're still nothing like an interview. It's a different kind of pressure.

> Ever been in a tense meeting?

This should not be what interviews are like.

If anything, my interviews are less tense and stressful than my meetings. On both sides of the table.

(If anything, this is probably not what meetings should be like. I wish to god my coworkers would have real agendas for meetings — and a one-sentence subject does not count as an "agenda", and ideally, written material detailing any proposal that will be proposed, s.t. I can arrive at the meeting already understanding what it is that someone wants to do.)

We shouldn't setting up interviews that are biased toward to hiring people who will make the company even more toxic and counterproductive.

What makes you think they'll be toxic and counterproductive? If, as you seem to think, whiteboarding is a test for this, then everyone should have whiteboarding tests where the good whiteboarders don't get a job.

However, just like like whiteboard coding is completely unrelated to real-world coding, this type of whiteboard design is also completely unrelated to the real-world whiteboard design people do in non-interview settings.

How many times has a scenario like this happened to anyone: Your manager pulls you in with no warning into a conference room and asks you to architect on the whiteboard a new product completely unrelated to anything the company does or has done so far. And you get 45 minutes to get it correct or you're fired. Right.. never. That's the scenario interview whiteboarding is testing for and it has no real world relevance at all.

In an actual job even the most impromptu whiteboarding sessions are related to product context already in your head. And most sessions are scheduled in advance so get to do research and prep work.

... You are making a load of assumptions that are wrong.

We ask the candidate to describe a system they have recently built. Therefore they should have product context, they are not being tested on inventing whatsoever (unless they are actually doing an impressive con, in which case, they'll have to be extra skillfull). As mentioned below, we give candidates the benefit of the doubt, but quite a lot of candidates are unable to give even a simple explanation of what they've worked on.

As for the amount of pressure - all of the pressure is circumstantial. We try as hard as possible to put candidates at ease. Obviously it's not entirely possible, but we try our best. Secondly, scenarios like that happen all the time. Maybe I won't get fired, but if there is a pressing issue, for example, I often need to draw diagrams to explain what is happening to a part of a distributed system. It is impossible to do without diagrams. And communicating these issues clearly and concisely often leads to quicker resolution times and happier clients/stakeholders

Can I just use words to describe it though? Or pseudocode? Short lists of issues that need to be considered in the design, with various options and their pros and cons, in words?

It's the expectation of drawing pictures on a whiteboard that's so strange to me, that's completely alien to the way I think about software. I think in text.

+ we don't set a hard time limit in the interviews. The whiteboarding piece is last and the candidate can spend as much time as he would like to. Often candidates have shown something we are happy with in just 5 minutes or so.

The assumption you seem to be making is that anyone with a whiteboard is also an evil villain that wants to interrogate you violently you and pick on any mistakes that you might make. In reality, it is a higher level check to see if you can communicate at all.