[nawgz]

So, you walk into job interviews with the feeling you have already earned the job? And that failing the interview is equivalent to being fired?

Weak strawman aside, I don't know what your point is. You can reference external things in most interviews I've executed. "Getting it wrong" is much likelier to apply to portions of the interview outside the Whiteboarding, like for example the coding portions where you find out if they can code. The whiteboarding is a loosely structured conversation hoping to understand how the candidate would approach the problem. Even not coming up with a perfect answer seems like it'd be far more stressful in the coding part than the whiteboarding part.

Indeed, every single thing you've listed is actually probably directly worse in other portions of the interview. Yet everyone only rails against whiteboarding in this thread, with no one answering my questions like "why is whiteboarding so much more stressful than each other piece" and "why do you think social anxiety would present cleanly as a detriment to your interview performance but never your job performance?

Too many strawmans, not enough substance.

[devanl]

I think I'm picking up that your model of how a typical technical interview is structured is different from what the other commenters have in mind.

It sounds to me like you view the technical interview as being split into a high-level whiteboarding phase followed by a separate coding test that is not done on the whiteboard.

In every interview I've had that involved coding and a whiteboard, I was expected to do everything on the whiteboard, from drawing diagrams and working through test cases to writing the actual code under evaluation, all in front of the interviewer.

Under this (very common) interview system, there is no "other piece" for whiteboarding to be more or less stressful than - it's embedded into the entire interview! (Yes, there are other interviews throughout the day that might only involve block diagrams or ask behavioral questions with no coding whatsoever, but I don't think that's what most people have in mind when they're told to prepare for an algorithmic whiteboard interview).

I think the interview process would be a lot better if it started with a no-coding-required whiteboard collaboration phase, followed by coding solo, and then ending with a mini code-review on the whiteboard. This is similar to the private technical interview procedure described in the paper.

As to your other question, I'm not sure why you seem so dead-set against the idea that performing analytical tasks while being evaluated in real-time would be harder than doing so under normal conditions. That's what this paper set out to investigate.

[nawgz]

> Under this (very common) interview system

I have never experienced such an interview, both when I am the interviewer and the interviewee, and I've been thru the entire process at multiple FAANGs. What you describe - literally coding on a whiteboard - is a far cry from whiteboarding a problem in my mind, this is a fair point

> I'm not sure why you seem so dead-set against the idea that performing analytical tasks while being evaluated in real-time would be harder than doing so under normal conditions

The entire interview has this elevated difficulty. You are constantly being judged and evaluated over the course of the interview. I have consistently asked for people to clarify why the Whiteboard part is elevated over any other technical portion in how stressful it is and how much that impacts performance, and I mostly have been attacked with strawmen. I appreciate your good-faith argument here, and certainly agree with you that conducting an entire interview including coding with a pen instead of a keyboard is a braindead practice. I will be more explicit of my assumptions next time as I would not have anticipated entire interviews to be conducted on whiteboards when you are trying to also find people who can code. I would expect what I've seen, which is that you use multiple different evaluation techniques across different scenarios and levels of interactivity and then you evaluate the tradespace, in which the whiteboard & collaborative time gives valuable data on how personality interop would work with your team.

[devanl]

> I have never experienced such an interview, both when I am the interviewer and the interviewee, and I've been thru the entire process at multiple FAANGs.

I've been through the all-day on-site interview at two FAANGs and every coding interview involved me standing at the whiteboard for the entire interview. As the saying goes, data is not the plural form of anecdote, but it's certainly common enough as a format that it has to be considered when discussing whiteboard interviews.

> The entire interview has this elevated difficulty. You are constantly being judged and evaluated over the course of the interview. I have consistently asked for people to clarify why the Whiteboard part is elevated over any other technical portion in how stressful it is and how much that impacts performance, and I mostly have been attacked with strawmen.

I agree that the entire interview has elevated difficulty, but which aspects are intrinsic / essential and which parts could we remove with minimal impact to the effectiveness of the interview?

For example, we both seem to be in agreement that writing code with a pen makes the whole interview harder without facilitating what we usually want to measure - the candidate's ability to reason about complex problems and write good code to solve those problems.

From the findings in the paper, just having a proctor in the room is correlated with the candidates performing worse on the programming task (as measured by writing code that passes the test cases). I'm sure there are benefits to being able to observe the candidate directly, but those benefits should be weighed against the drawbacks and evaluated in light of whether or not it's really a net positive, regardless of whether the interview process as a whole will still be stressful in other ways.