[Groxx]

Is that expected to be a major part of their job?

If no, then no, it's not.

If yes, perhaps. Interview settings are still quite different than what they're going to face on-the-job, but you do have to infer from something, so I'm not sure there's any real alternative.

[nawgz]

> Is that expected to be a major part of their job?

How do you collaborate with your teammates? I do it directly by approaching a problem in a shared coding or whiteboarding session, where we try to break it down to its barest bones and then implement logic to animate these bones. Once that is done, we begin to look at what types of higher-fidelity information we lost, and iterate.

This requires a good ability to communicate, write code in real-time, understand perfect is the enemy of good, and in general be able to simultaneously think deeply and support conversation / collaboration.

Of course, there are frequent async steps in such a workplace, but if you are the type of engineer who doesn't participate in these stages and instead can only pull tickets and write them to a spec, you are the type of engineer I don't want to hire. So I consider the signal:noise ratio quite high wrt watching someone melt under the same pressure as every other interviewee faced.

[devanl]

I agree that collaborating in real-time is important, but I disagree that interview conditions allow you to assess real-time collaboration abilities accurately.

In a real life situation, both you and your partner will be generally familiar with the problem at hand; if not there's an expectation that the person with more knowledge will be explaining not just the problem, but also the solutions that are already under consideration, so that everyone is on the same page.

In an interview situation, the solution is obviously withheld because the goal is to make the candidate derive it, so any back-and-forth is artificial - the interviewee is the one who has to do analysis while being scrutinized while the interviewer has already done the work.

And of course, normally your partner doesn't have control over whether you get hired or fired. If you were dropped into a room with the CTO and told that you had to solve a new-to-you problem they had already solved or you would be fired, you would probably find yourself performing much worse than if your team-mate asked you to weigh in on the problem that had been bouncing around on Slack for the past few days.

[gfxgirl]

While you're collaborating with your teammates, if you reference anything external or get it wrong or don't come up with an answer in 45 minutes you're fired!

Still stress free?

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