[HN Gopher] Does Stress Impact Technical Interview Performance? ...
___________________________________________________________________
Does Stress Impact Technical Interview Performance? [pdf]
Author : kevbin
Score : 48 points
Date : 2021-03-08 21:09 UTC (1 hours ago)
(HTM) web link (www.chrisparnin.me)
(TXT) w3m dump (www.chrisparnin.me)
| louisstow wrote:
| My least favourite interview technique has to be "talk me through
| a complex problem on a whiteboard". It's not so much the stress
| but the fact that you can't have a train of thought longer than 5
| seconds before someone finds the silence awkward or interprets it
| as you're lost and breaks the silence and train of thought. It's
| a test for solving complex problems in 5 second blocks while
| being constantly interrupted.
| tomca32 wrote:
| I absolutely hate the interviews that are just an algo
| challenge and the interviewer is waiting on me to finish to
| evaluate my solution. I flip out, start thinking that I'm
| taking too long and it just goes downhill from there.
|
| On the other hand, the questions where I can talk through a
| problem are by far my favorite. Every problem in our field can
| be talked about for days. There's just so much to discuss:
|
| - different approaches
|
| - performance considerations
|
| - perceived complexity
|
| - and a hundred tangents I could go on to
|
| In my opinion, it is the interviewer's job to get the candidate
| to talk. If the candidate can't speak a word out of their
| mouth, the interviewer failed. When I interview I just want to
| get you to talk...tell me stories, tell me tangents, tell me
| the stupid stuff, tell me the smart stuff. Tell me what kind of
| solutions you prefer and why?
|
| Reading your comment made me think that maybe this isn't the
| best approach. Maybe some people want me to shut up and just do
| the hard math problem on their own.
| ericbarrett wrote:
| I've been on both ends of this exchange. I always gave
| candidates time to work through it without interruption when I
| was the interviewer. This didn't prevent the worst cases of
| nerves, of course, but hopefully I didn't make it unnecessarily
| worse.
|
| Conversely, how they treat me as I go through the process is a
| great way to judge the engineering culture of the org. If the
| interviewer feels license to cut me off, jump in, correct me on
| syntax _as I 'm still writing_, or just generally sprays
| frustration, it's a high-confidence signal that I'll get the
| same treatment as a new coworker, and I have ended interviews
| accordingly.
| heavyset_go wrote:
| My least favorite is "let's implement something that's really
| easy to implement if you've spent time thinking about it or
| working with it before", except you don't get the time to think
| about it and you're judged poorly for providing anything other
| than the "obvious" optimal solution.
| jmchuster wrote:
| If you work at a company where 90% of your developer
| interactions are, let's go to a whiteboard and hash it out, it
| kind of is the most job-relevant interview question you can ask
| outside of writing code.
| cmckn wrote:
| How common is this? I haven't really ever used a whiteboard
| at work, though they're everywhere (and I mean everywhere).
| It seems like a lot of companies want you to think
| whiteboarding is a thing there.
| jedberg wrote:
| We want you to think out loud. It's a different skillset but an
| important one when solving a problem in a group. You might be
| formulating an idea in your head, but if you say it out loud,
| even an incomplete or "wrong" thought might be useful to
| someone else in a real world situation, as it might trigger an
| insight for them.
| ugh123 wrote:
| Yes, it is generally a good thing to be able to communicate
| while you're working on a problem within a group.
|
| But rarely does someone get posed a difficult technical
| design question _on the job_ and _on the spot_ where they 've
| had little or no opportunity to think about it ahead of time.
| Usually there is a ton of contextual knowledge leading up to
| those group discussions vs. being asked a question in an
| interview and then be expected to perform at that same level.
| screye wrote:
| I actually love these kinds of questions. Allows the candidate
| to run through the problem as a conversation instead of a
| binary solved/not-solved outcome.
|
| I usually preface it by saying that I will take a minute to
| write down a few ideas, so the silence isn't awkward. It is
| such a great way to engage your interviewer, while gaining a
| finer ability to choose the level of abstraction when you are
| working through a problem.
|
| I love it also because it helps those who aren't native English
| speakers. The ability to visually represent ideas is equally
| distributed across language skills. It doesn't even need to be
| suited for a visual thinker. It can be math, venn diagrams,
| graphs or even straight up code.
| Germanika wrote:
| Working through a problem out loud is definitely a bit of a
| different skill from just solving a complex problem on your
| own. I do find that saying something along the lines of "OK now
| I just need a minute to think through this next part" goes over
| well enough and can give you a minute to relax and think
| though.
| planet-and-halo wrote:
| I think the issue is "a minute." You still feel pressured to
| get moving and keep talking, even if it buys you a little
| time. My favorite part of the job is whiteboarding with
| colleagues, but in an interview there is something that feels
| inherently adversarial about it. This isn't necessarily the
| fault of the interviewer either, it's just sort of baked into
| the format. There's a natural power discrepancy: the
| interviewer makes the final call, and they selected the
| problem to begin with, which means you can't possibly be on
| equal footing. That imbalance means you spend the whole time
| on the back foot. I'm not sure there's a better format
| available, but that's definitely an unnatural environment and
| can lead people including me to perform much differently than
| they do in a normal work environment. Unfortunately it may be
| the best we can do.
| bmitc wrote:
| I think the better format is to have the interviewee talk
| through a complex problem that they have already solved,
| whether it's a side project, a work project they can talk
| about, or whatever. It balances out the power imbalance,
| and it showcases how well the interviewee can explain and
| talk through problems, design decisions, what they learned,
| what worked, what didn't, etc. through a problem they are
| already familiar with.
|
| These whiteboarding interviews where the interviewers pose
| some random question does nothing for either party.
| bmitc wrote:
| Even worse is when you solve the problem in a way they didn't
| expect or plan on, and they spend the time derailing you off
| your solution and back to the one they understand.
|
| I had a miserable interview experience once were I gave a tree
| processing solution in a functional, tail recursive way. They
| spent the interview sliding me back into a mutable, iterative
| approach, and it really through me off. Additionally, I don't
| think they even understood the functional solution. Half the
| time, it felt like I was needing to guess where they'd like me
| to go.
|
| And we all know working and software development is nothing
| like that. At no point in that particular interview was I asked
| to describe projects I had worked on. When I left, they had no
| idea what I had even worked on previously because they didn't
| ask. They just asked a tree question, which someone could look
| up over an evening or weekend. So pointless.
| plank_time wrote:
| The absolute worst is when interviewers keep interrupting the
| candidate. It shows a complete lack of empathy and it shows
| that the interviewer wants the interviewee to answer the way
| the interviewer thinks it should be answered.
|
| I am very mindful of this when I interview and I think it's my
| job as the interviewer to strain myself to try to understand
| the interviewee, not the other way around. I quietly try to
| understand my interviewee and don't interrupt unless there's a
| real reason since I want her to think freely and not feel
| stressed.
| tchalla wrote:
| > My least favourite interview technique has to be "talk me
| through a complex problem on a whiteboard".
|
| Let's say an interviewer reads your resume and is interested in
| a project. The interviewer comes to the interview prepared with
| some questions. They ask you to start with a high level summary
| of the project. Then, ask you - "What choices did you have to
| make during the project?". Then, ask you some specific
| questions about these choices. In each of these questions, the
| interviewer is not supposed to "evaluate your answer" but
| rather gain an understanding of your project and choices to be
| made. At the end of the interview, the interviewer would walk
| away with two things - (1) a clear picture of the project
| almost as good as the interviewee and (2) a clear picture of
| the design decisions the interviewee made (options they had and
| why they chose one over the other).
|
| The above interview is a conversation and you are allowed to be
| silent. The process will be communicated to you upfront. In
| fact, silence is encouraged because the interviewer would much
| rather give you time to think over a spur of the moment answer.
| majormajor wrote:
| I would love, as an interviewer, to be able to do this style
| of interview every time.
|
| It's astonishing how often you get nothing useful as an
| answer. Things like "my boss suggested it" as the reason for
| choices being made, or "not really" when asked about
| alternatives considered, or problems they ran into...
|
| The hypothetical project whiteboard interview gives people
| who _haven 't_ done sufficiently interesting past projects
| and opportunity to show that they can think about them, at
| least...
| shepardrtc wrote:
| > Let's say an interviewer reads your resume and is
| interested in a project.
|
| That's not what they were talking about. The complex problem
| is supposed to be novel to the interviewee.
|
| > In fact, silence is encouraged because the interviewer
| would much rather give you time to think over a spur of the
| moment answer.
|
| Yes, they certainly say that. But for a normal person trying
| to figure out a novel problem, ignoring everything that's
| going on and sitting there silent for 30 seconds or longer
| while the person who single-handedly can determine whether
| you pass or fail - often depending on their mood - stares at
| you is incredibly difficult. And if their mood isn't good,
| they absolutely see the silence as not knowing the answer and
| push for you to move on. I had it happen to me on a Facebook
| interview. I personally can't concentrate enough to think
| through a difficult, multi-layered problem in that situation.
| It is in no way reflective of what I can do while working.
|
| Online coding tests are more than sufficient. And a
| discussion afterwards about said tests is sufficient to make
| sure there was no cheating.
| louisstow wrote:
| Those are great, I'm more talking about a complex problem
| you're given and have to whiteboard the solution while making
| sure not to be silent for too long or you'll interrupted or
| given a hint.
| chaps wrote:
| Yep. Once had an interview where I was asked to model attack
| vectors for a generic service for an industry that I spent most
| of my career in. Pretty sure they didn't realize I came from
| that industry. The interviewers got a little bit frustrated
| with me when I wasn't answering their questions in the
| abstract-but-precise way that they were looking for and they
| clearly didn't understand the industry of the fake app they
| wanted me to attack. The "attacks" I described came from real-
| world scenarios, usually sourced from some backend person's
| mistake that cost someone a lot of money, just sprinkled with a
| bit of obfuscation. At one point in the interview I had to call
| a timeout on the whiteboard interview and explain to them that
| a lot of their questions only made sense in an abstract way and
| had zero real-world meaning. Was offered the job, but it makes
| me wonder what sort of answers they were looking for and who
| was denied despite giving valid attacks.
| efwfwef wrote:
| My latest system design interview was: design this app. Dude was
| like "I'm expecting you to lead the conversation". I was like,
| bitch there's a million things to talk about, at some point you
| have to tell me where you want the convo to go. Needless to say I
| failed, when I'm probably overqualified for the job, but heh...
| MattGaiser wrote:
| I had this for my current job. I was asked to design Facebook
| and it just ended up being nearly entirely about how to design
| a notification microservice. Got the job so it evidently
| worked, but I was just going on in a direction until told to
| stop.
| taurath wrote:
| The interview process is somewhat akin to the "stress"
| gatekeeping in other industries, where people in charge say "I've
| gone through this, so it makes sense that others would have to
| also or else we risk getting worse people". While not really in
| the same ballpark it feels somewhat like the medical residency
| system, something that everyone knows is drastically unhealthy
| but it keeps getting propagated because people are afraid of what
| happens when you change it.
|
| As someone with clinically diagnosed and treated anxiety the
| whiteboard interview is an absolute personal hell. I have
| extremely good performance ratings everywhere I've landed a job
| even in very high stakes actual work environments, but my opinion
| on the average interview process is it's extremely discriminatory
| against people who deal with practically any mental health issue
| (which, let's face it is probably quite prevalent in this
| industry).
| _greim_ wrote:
| So, it's a long PDF. Can someone summarize the recommendation
| from the study?
| tchalla wrote:
| The abstract of a paper is an executive summary. In case, that
| is not enough - you can look into the press release [0].
|
| [0] https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/
| kevbin wrote:
| > A technical interview has an uncanny resemblance to the trier
| social stress test [39], a procedure used for decades by
| psychologists and is the best known "gold standard" procedure [1]
| for the sole purpose of reliably inducing stress.
|
| > The trier social stress test involves having a subject prepare
| and then deliver an interview-style presentation and perform
| mental arithmetic, all in front of an audience.
|
| > ... rather than avoiding unwanted stress, technical interviews
| may be inadvertently designed with the sole purpose of inducing
| it.
|
| 39: https://www.karger.com/Article/Abstract/119004
| boredpandas777 wrote:
| There is no other field where the candidate has to pass an exam
| ever time they switch jobs. I suggest getting software engineers
| licensed by an independent party just once (maybe renew every 10
| years.)
| daniel-thompson wrote:
| Speaking from personal experience, it absolutely does; both on a
| mental level (the feeling of being watched and judged, leading to
| constant second-guessing) and on a physical level, where it
| invokes the fight-or-flight response. I'm sure the latter in
| particular was super useful to our ancient ancestors, for whom a
| shot of adrenaline during stressful situations could be the
| difference between survival and death. But the physical symptoms
| - elevated heart rate, dry mouth, tunnel vision, shaking, excess
| perspiration - are actively harmful to performance in a software
| engineering interview.
|
| I have friends who, before upcoming situations they know will be
| stressful - interviews for engineers, performances for musicians,
| surgery for doctors - have obtained prescriptions for beta-
| blockers, which mitigate the physical symptoms of the fight-or-
| flight response for a few hours at a time.
|
| * https://en.wikipedia.org/wiki/Beta_blocker#Anxiety
| gkoberger wrote:
| We have a rule for technical interviews that we want to "enable
| each candidate to show the best version of themselves". It seems
| simple and obvious, but I'm amazed by how happy and excited
| people are by our interview process. I constantly get emails
| saying it was such a relief or that they loved it.
|
| It just seems so crazy that we pressure technical candidates the
| way we do, and expect decent results.
| ugh123 wrote:
| That sounds great, but how do you achieve that?
| GongOfFour wrote:
| The only time I've ever had a panic attack was when I was white
| boarding some basic stuff in an interview while I was hungover.
| Obviously being hungover is non-ideal and one wouldn't expect the
| interview experience to account for that but nonetheless I have
| always found it interesting that it took that combination to put
| me over the edge.
|
| I remember leaving as quickly as I could and thinking that I had
| to find a place to sit down as soon as possible. I made it to
| Washington Square Park and just sat at a bench for about 30
| minutes feeling like I was slowly coming out of a tunnel. Never
| happened before nor since.
| 5cott0 wrote:
| A kooky theory I harbor is that corporate tech continues to
| employ algo whiteboard hazing ritual interviews because if they
| were to evaluate SWEs with tasks more closely resembling the
| expected day-to-day they would have to pay them an hourly rate
| under CA labor law or face liability exposure.
| tchalla wrote:
| Previous Discussion 8 months ago :
| https://news.ycombinator.com/item?id=23848039
| bmitc wrote:
| Absolutely. I've had it happen. I have even undergone tests that
| shows I experience performance anxiety, and that it actually goes
| up the easier a question is.
|
| I've had interview instances where my face felt flushed and my
| mind completely blank on a question I knew how to do but
| struggled on. And then 30 minutes after the interview finished,
| the answer is clear as day in my head because it was indeed
| something I knew and the anxiety was gone.
|
| I feel there is a fair amount of discrimination against those of
| us who experience anxiety like this, but in a way, I don't care
| all that much because places that interview certain ways aren't
| places I want to work anyway.
| ram_rar wrote:
| This is one of the reasons, I prefer small take home assignments
| which can be later discussed with the interviewer about the pros
| and cons of the decisions made during coding. As an interviewer,
| you get more insight into what the candidate was thinking and
| whether they were able to actually implement something end to
| end. Leetcode style problems rarely give you that signal from
| candidates.
| Trasmatta wrote:
| I've done those before, and found the employer always
| underestimates how much time they should take. I think it's a
| good idea, but I've done 3 where the employer said "this should
| take 2-3 hours", but I actually had to spend an entire weekend
| on it instead. Felt like a waste of time, especially for the
| ones I didn't even make it to next phase in.
| [deleted]
| bitbuilder wrote:
| As a hiring manager who was once a developer who was absolutely
| terrified of the typical whiteboard/algorithm interview, take
| home assignments are my preferred method to judge tech ability.
| However, I often feel it's not fair to ask the candidate to
| invest their personal time in the interview process. So I'm
| glad to see some affirmation that it's the preferred method for
| at least some.
|
| When I have done take homes, I've tried to keep the time
| requirements minimal and the project itself simple and
| hopefully even a bit fun. It might even be as simple as "here's
| a REST endpoint, pick the JS SPA framework of your choice and
| do something interesting with that endpoint." Even just a
| simple form with clean code that builds will be enough to get
| you hired if you're otherwise a good candidate. Because in the
| real world, most of of us are just building CRUD apps.
|
| All that said, I only bother with this if the candidate is
| incredibly green. For anyone with decent experience I generally
| assume they're not lying on their resume, and an hour long chat
| about their projects and technology interests will tell you
| more than any technical assessment.
| cmckn wrote:
| "Small" is the operative word here; but I think take-homes are
| almost always an inappropriate ask. It takes too much time to
| implement even simple things end-to-end to ask someone to do it
| for free. I lobbied for candidates to be compensated for such
| assignments in a previous role (even if it's just a voucher for
| a nice dinner).
| posharma wrote:
| We discuss interviewing a lot here. Despite all the proposals
| things don't really change. FA(A)NG style interviews are just
| that - whiteboarding solutions to N algorithmic problems in M
| minutes (or minor variants of this). Either we accept this and
| move on with solid preparation or modify our priorities such that
| we're fine with not wanting the money and/or the quality of work
| (debatable) offered by these companies. At the end of the day,
| it's a choice and it's still in our hands.
| jmfldn wrote:
| It absolutely does. One of my first programming interviews, post
| MSc graduation, was essentially a 3hr whiteboard interrogation. I
| should have walked out after an hour as, in retrospect I was
| stuck like a rabbit in the headlights, unable to think straight
| as this unpleasant interviewer essentially tried to dismantle
| every angle of my understanding of a subject. I was gripped with
| anxiety and lost confidence. He claimed he was just trying to
| find out the edges of what I knew but boy did he do it in an
| unpleasant way. Interrupting, making slightly snide comments,
| being plain rude at times. I think he was either an actual jerk
| or maybe just not very good with people. He had just been pointed
| CTO of some fintech app having had no experience other than ivory
| tower academia I think. It was a masterclass I now realise, in
| how not to interview someone.
|
| Anyway, other than that interview where I was super stressed and
| tanked it, all my others have been nothing like it. Just goes to
| show how stress and a loss of confidence can wreck your chances.
| 11thEarlOfMar wrote:
| We use a 3 step process, sans whiteboard:
|
| 1. First interview, the candidate interviews us. What market we
| serve, what our development processes are, what our technology
| stack is. If they express interest by being prepared and asking
| good questions, we send them
|
| 2. a programming task. Choose 1 of 5 tasks. The tasks are not
| abstract problems or puzzles, but come out of the designs we've
| implemented. We ask for 100 lines of code and not more than 2
| hours. They take as much calendar time in days as they need, most
| have full time jobs, and let us know when you're done. The
| candidate then comes back, typically in 2 to 7 days and hosts a
| code review in front of our team. I give strict instructions
| before hand: The purpose of the review is to learn how they
| thought through the problem and how they solved it, not to
| criticize their style and approach.
|
| 3. If we decide we like them to this point, the third interview
| is with managers from other functions. How well does the
| candidate communicate, come across to non-developers, express
| interest in the company and role, etc. It's a check point to look
| for concerning weaknesses, as well as get buy in from the broader
| organization.
|
| We like this approach because it allows the candidate to code in
| a much more natural environment. They can take the time they need
| and comfortably solve. No one spends their professional career
| coding on a white board. This approach so far has yielded
| excellent results. We ask developers how much time they took in
| the programming task and why they chose the one they solved. The
| programming task is telling, not in the quality of their code and
| how long they took, but how much did they get into it? We have
| had the range from candidates who did not complete it at all and
| opted out, to candidates who stumped 40 year veterans with
| elegant code. In every case, we learn how well they can express
| their thoughts, and importantly, their level of love for the
| discipline. This is as important to me as any other attribute.
| nabla9 wrote:
| It seems that technical interview is a great way to do
| psychological evaluation. How does this person manage stress and
| deal with it?
| 2pEXgD0fZ5cF wrote:
| You can be the most resilient person to real life
| work/emergency/deadline pressure and stress and still get stage
| fright when giving talks or being in an interview.
| dgellow wrote:
| It's a great way to pass on otherwise awesome employees. You
| don't need all your employees to be the same. You don't need
| them all of them to manage their stress the same way. You don't
| even need all of them to be good at managing their stress.
| kevbin wrote:
| The authors address this: the induced stress is not necessarily
| similar to the stress experienced on the job they're applying
| for.
| planet-and-halo wrote:
| This has been my experience. Time is crunched in a rather
| unrealistic way. Not that time crunches don't happen, but
| it's never once been the case in my real job that I was
| approaching an unpracticed academic algorithm problem which
| had a 30 minute time cap.
|
| Recent example: I was asked to do a density map with about
| ~20 minutes remaining in an interview. I could immediately
| see the performance issue of the naive solution (re-summing
| the same positions), but I needed some time to think through
| an efficient solution. But because of the time limit and the
| fact that I had someone watching my every step (i.e. there
| was more performance than problem solving going on), we
| agreed that I would take the naive approach and simply sum
| all of the positions as quickly as I could. When I wasn't
| asked back for a second round, it was obviously in part
| because I had resorted to such an ugly and inefficient
| solution.
|
| I don't blame the interviewer--he was actually one of the
| best I've ever interacted with--and I actually think the
| problems selected fit the role very well. But at the end of
| the day I don't feel that format gave a very good snapshot of
| my abilities. (Case in point, I looked up solutions
| afterwards and an intuitive approach I had thought of was
| very close to the optimal solution, but I didn't feel I had
| time to go down that route.)
|
| I don't think there is a perfect interview format. They all
| have downsides. But this is definitely a tradeoff you're
| making with timed algos.
| hinkley wrote:
| Why do you want all of your employees to be the ones most
| resilient to stress?
|
| Are you hiring for a fire department? The Navy Seals?
| Engineering section on a nuclear submarine?
|
| Maybe, just maybe, things would improve if you had a few people
| who said 'no way' when someone tries to crank up the drama on
| your team instead of just grinning and bearing it.
|
| Capitalists don't reward the quiet workers. They exploit them.
| Billionaires and wannabees do it remorselessly.
| tesnirnat wrote:
| If I had a Bitcoin for every time I heard a manager say that
| he idolizes the Navy SEALs.....
| heroHACK17 wrote:
| Or, an alternative title: Is Water Wet?
| ChrisMarshallNY wrote:
| You do realize that the correct answer to any headline that
| ends with a question mark, is "No."
|
| So I guess water is not wet.
|
| I will say that I am comfortable with people not wanting to
| work with me, because I don't fit their mold _(deliberate
| [sic])_.
|
| Take-home tests are a good idea, but you still have the issue
| that so many folks here have mentioned:
|
| They don't just want you to _solve_ the problem. They want you
| to solve it _the way they want_. Orthogonal approaches are
| generally not met with support.
|
| I once had a take-home, where I was asked to produce an iOS app
| that used a certain dependency (that I had never used), and was
| asked to do so, using MVVM.
|
| In four hours, I had it done. It was a localized, ship-ready
| app. I didn't use MVVM, because UIKit is designed specifically
| for MVC, and using other models actually makes the app larger
| and more prone to problems. It was a tiny app, and I didn't
| want to add any code that wasn't 100% necessary (basic Quality
| 101). I also encapsulated the dependency (Quality 101, again).
|
| During the process, my home had an electrical emergency, and
| almost burned down, so I guess there was a bit of stress.
|
| I handle stress quite well, indeed. A quick glance at my CV
| tells that I worked for one of the top Japanese firms in the
| world, for 27 years.
|
| They refine and mass-produce stress in Tokyo. If you last 27
| years at a joint like that, you can handle stress.
|
| I could smell the burning rubber, as they peeled out _(although
| it could have been the electrical fire)_. They never asked me
| why I made the choices I did. I strongly suspect that I was
| never in consideration anyway. I think they were checking off a
| _" interviewed old guy, and he sucked"_ checkbox on an EEOC
| form.
|
| The folks that actually get around to working with me, seem to
| enjoy the experience. Funny how that happens.
___________________________________________________________________
(page generated 2021-03-08 23:01 UTC)