Does Stress Impact Technical Interview Performance?
theregister.com
theregister.com
I (as a man) can absolutely work under stressful conditions such as dealing with a major outage, even if there is a bunch of people looking over my shoulder.
However having a bunch of people looking over my shoulder waiting for me to write on a whiteboard what they have in mind and then judge me, that's going to be a problem for me.
After settling down I proceeded to solve problem after problem effortlessly.
Later in career I got very sick.
I would be doing presentations while having minor strokes (TIAs) I shouldn’t have been working, But I had no options if I lost my job. Doctors didn’t yet know what cause was.
So literally I had to perform or die.
Yea that is stress.
At the same time, the idea that "ability to handle stress" isn't important for software engineering seems (to me) a silly one.
So yes, if you're trying to assess technical ability and you're failing at that, it's a problem. But it is not discriminatory (in the bad way) to weed out candidates who can't handle stress in an occupation that can be very stressful. Though it was pointed out in the article that "public" vs "private" settings made a difference, so your hiring process should reflect whichever of those settings is more likely to come up if the candidate is actually hired.
At the end of the day, the goal of an interview should be to assess whether or not that person will be able to do their job, so you want interview conditions to match working conditions as much as possible. Unfortunately every job is different so there is no one-size-fits-all solution.
For example, when you're in charge of a production service, and that service goes down, there is a lot of social stress to "just fix it", oftentimes under non-ideal conditions (just like solving a problem on the spot in an interview).
It's much more likely you're typing some bash commands or restoring a postgres database.
I've had to solve DS&A problems a few times in my career, and I've had to solve production outages, but never both at the same time.
I don't think that's a conclusion you can actually make, it's still a very different kind of stress, especially for someone introverted. When I'm being evaluated, the stress is crippling me - I'm overly nervous and can mess up even the simplest things; even finding correct words can be hard. However, when I'm in a urgent situation where something needs fixing, or deadline is passing, I become focused, assertive (but also easily irritated) and take charge much more easily than usual - and that short-term stress actually helps there. Those are very different situations that make people react differently.
I also think that how much stress you want is a matter of taste. Some folks prefer the pressure cooker. I'm not knocking stress, I just think that's a culture thing not a requirement.
When it comes to job interviews, there are so many ways to write somebody off, but all I'm looking for is: - major deal breakers. e.g. too mean, irresponsible, too many bad habits - major wins, e.g. they bring something to the team we don't have.
The default posture of most candidates is uncomfortable and stressed. Being able to evaluate them often means trying to make them more comfortable. If whiteboard interviews are more prone to inducing stress, that's worth knowing.
Sure, but there needs to be some kind of careful thought about HOW to devise and evaluate candidate performance on such "assessments". It's not trivial and it's not a "solved problem".
Are all forms of stress the same? Is the stress of solving a puzzle at a whiteboard the same thing as the stress of dealing with a sh*t-hits-the-fan outage? I think not.
Some people are excellent at handling being put in front of observers who are evaluating them and keeping their calm. Others are exactly the type of people you want in a crisis. These are not necessarily the same people. Some folks are great at triage, working in emergencies and maintaining communications, others are really good at reducing the likelihood of emergencies happening in the first place-- not necessarily the same people, and they don't necessarily act the same in front of your whiteboard quizzes.
More importantly, there's no proof that these "amateur-hour" psychological evaluations to assess stress are successful in predicting actual job performance under stress. HR certainly can't do this, but technical hiring managers think they can do it just because they assume their "gotcha" questions mean anything valid.
On a whiteboard interview, it feels like being in school at a test where you didn't prepare well, for a topic you are not interested in. So stresss kicks in and my mind goes blank. I'm glad that a lot of interviews happened remote, it helped a lot.
"Whiteboard coding interviews" are not what was studied--the terms the actual study uses seem to be "public" versus "private" interviews, and the finding was that public interviews tested ability to handle anxiety (not stress, as some commenters are misidentifying) rather than coding ability. Critically, both forms of interview studied are whiteboard interviews.
The Register's writeup is inaccurate worthless crap, demonstrating either incompetence or dishonesty on the part of the authors. Let's try to link to original studies in the future.
[1] https://medium.com/@gameweld/the-case-for-the-private-techni...
I've done 2 whiteboard interviews. I bombed them because the questions are incredibly stupid and have zero real world application. And I'm a guy. I know plenty of women that run circles around me when it comes to interviews and public speaking. This paper's weak argument that women are incapable should be shot down.
Stop blaming everyday people. This is diverting from the issue of wannabe clever interview processes. 90% of whiteboard questions are stupid in nature. People with real world experience typically have a hard time with uber abstract questions that never come up in day to day.
In truth, a person that bombs one of these interviews should be immediately hired. It shows they can't accept stupid thoughts. Regardless if they're a man or woman.
The argument is that, in the study: All women in supervised interviews failed the interview. All women in unsupervised interviews passed the interview.
The sample size is too small to draw conclusions, but it definitely opens up further avenues of inquiry that should be done.
However, whiteboard architecture interviews for solving certain higher level classes of problems do provide a signal for problem solving ability. Design is a narrative process that you make concrete with diagrams, so it's more suited to an interview situation.
The trial-by-trivia approach of coding interviews creates a culture where you get a company full of people who shared copies of the exam answers with the people they referred in for the hiring bonus. A company succeeds on the quality of its products, which is the effect of the quality of design and architecture thinking, and not on the ability of its staff to perform live optimizations on fizzbuzz.
It's too small a group to draw proper conclusions, but it definitely warrants a larger study.
In this context, a white-board interview would normally come later in the process, when we already have a rapport with the candidate, and the goal would not be to "catch" a candidate with tricky questions, but rather to see how well a candidate is able to reason through a problem collaboratively in real time, which is something I would expect to happen in the team setting with some regularity. It's even more of a team chemistry evaluation as a problem solving test.
Probably earlier in the process I would ask a candidate to complete an individual assignment in their own time. This would be the opportunity to see what kind of work they are capable of producing.
If your goal is to see how they reason through a problem collaboratively, then doesn't it make sense to actually collaborate with them? I.e. instead of asking questions, take a problem that you don't know the answer to either, and team up on it.
When I'm solving a problem I sometimes do use a whiteboard, but that depends on the nature of the problem--if it's heavily data structure oriented, for example, then a whiteboard is useful for drawing out the data structures. I don't think I've ever written a line of code or pseudocode on a whiteboard board as part of collaborative problem solving: that's just not useful when you could be writing actual code on a shared screen.
TL;DR: While I agree with your goals here, I don't think the method we're discussing actually achieves those goals.
As someone who failed around 8 interviews (combined phones + onsites) for FAANG/Unicorns I am still a supporter of DS&A interview. I finally now work in one of the FAANG/Unicorns, after solving around 400 Leetcode questions.
For those who are against DS&A questions, tell me how you as a company that wants to interview candidates, can afford to interview as many as possible as fair as possible as straightforward as possible as little time possible and everyone having equally strong skill set? You can't hire them all. You can only hire few ones but reject the others. Without some x metrics that can be seen easily you'll get into trouble rejecting other candidates.
Edit: written when the title was: "whiteboard interviews are anti woman"