Live data from Hacker News

Tech sector job interviews assess anxiety, not software skills: study

news.ncsu.edu

381–390 of 1001 posts

Re: Tech sector job interviews assess anxiety, not software skills: study

#381

Earlier quoted context omitted.

I was on the other side - I flew out to FB during a vacation earlier this year. I got there, could explain the solution but something was off and I kept losing the thread when I went to convert it to actual code. The interviewers didn’t know I’d gotten a call from my cat sitter that morning and one of my cats had to go in for an emergency check up. (He ended up being fine but didn’t know that at the time). Later that…

I mean this would apply to going on a first date as well. First impression is what matters and once the impression has been ruined, all bets are off. It is not specific to the interview process.

Rescheduling a date or an interview at the last minute doesn’t make a great first impression either.

Re: Tech sector job interviews assess anxiety, not software skills: study

#383

Earlier quoted context omitted.

I don't think people are naive, they just don't have a better solution. Most established professionals are not interested in a 10 week trial period after which they might be back on the job market.

"Most established professionals are not interested in a 10 week trial period after which they might be back on the job market." Why not? If the position isn't a fit for either side after X time on-the-job, that's OK right?

Some places have a contract-to-hire approach which is effectively a trial period.

I believe companies fall into two basic structures:

1. agency / consultant model - implement short-term projects, specific tasks, etc. It's easier in this approach to swap employees in and out as new projects start.

2. software product model - the company's entire business model is built around or highly dependent on internal software projects. Institutional knowledge is very important. It's really important to protect the product process and plan for the long-term implementation of strategic vision.

Contract-to-hire works well for #1. But for #2, the overhead and cost of disruption to the core process is too high. Top-tier software products require a relatively smaller number of highly engaged and skilled people to drive projects to an optimal point. These people need to also be directly involved in hiring and onboarding to maintain the culture and high standards. Bad hires can destroy such a team. Thus you end up with the current interview processes as they're efficient and err on the side of rejecting qualified candidates accidentally. If they spent 10x as long on hiring, they could improve the accuracy, but then they wont have as much time to build product which is the key tradeoff involved.

Re: Tech sector job interviews assess anxiety, not software skills: study

#384
post #56

Earlier quoted context omitted.

The small N is addressed by the authors. To acquire a larger N would mean recruiting more participants, which would require either compensation/extra credit or rely on people volunteering ~1 hour of their time. Likewise, collecting that data would require time and money. It is an time/resource issue with human research. You can require a small N and get some results or require a large N and not have enough funding to…

I'm curious as to what makes a good size of N. To me, N=10 would be do small, N=48 seems a little under what is should be, and N=100 seems sufficient, but I don't have a real basis for this (in fact, it's probably because of the original count that had me settle on a min and max of 10 and 100). Maybe a better question is: What are factors that studies consider, besides the logistics you rightly pointed out, in determ…

>I'm curious as to what makes a good size of N.

That depends on the size of the population being sampled from, the margin of error, and the confidence level.

For a huge effect like the one shown in the study, where one side performed 2x as well as the other, a sample size of 48 is more than large enough to say that the result is statistically significant. If there was as small effect, that wouldn't be the case.

Put it this way. You want to find whether people from California prefer Taco Bell or Pizza Hut, so you randomly sample 100 people. If all 100 people say Taco Bell, then you can be reasonably confident that more people from California prefer Taco Bell. Because if at least 51% of your population preferred Pizza Hut, the odds of not getting one of those people in your sample are minuscule (the odds of getting all Taco Bell people in your sample if 49% of the population prefers Taco Bell is 0.49^100).

If 51 prefer Taco Bell and 49 prefer Pizza Hut, your confidence level is too low to be useful--you need a larger sample size.

Re: Tech sector job interviews assess anxiety, not software skills: study

#385

Earlier quoted context omitted.

is there a centralized place with information like this but for other companies as well?

Glassdoor? Maybe, not sure if that is exactly what you are looking for..

I mean, yeah. They have a review(s) section for people who used to work there, and a section on interviews too.

Dig up some fake creds on BugMeNot and poke around Glassdoor

Re: Tech sector job interviews assess anxiety, not software skills: study

#386
post #305

Earlier quoted context omitted.

I'm pretty angry with the person that you were. I'm frustrated with the people who look up a question, see the exact solution and walk through and then expect the candidate seeing the problem statement for the first time to walk through it in the same way. There are questions being asked that full academic papers have been written on. What's even worse is typically I get interviewers that are not experienced+prepared…

I bomb on technical interviews the same way because my mind just freezes and can't get through even simple problems. I had the same question you mention. "This is a problem a paper was written on, are you expecting me to derive a whole paper from first principles in half an hour, or are you expecting me to have seen it before? If it's the latter, why not let me Google, as I normally would?" I feel that saying "I woul…

The funny thing about this is:

They're not looking for someone that is eager enough to show they're willing to work through it even though they have no idea to proceed.

They are looking for someone that got lucky enough to be ready to answer that particular problem, but won't stand up to them that the ask was a bit too much for a reasonable interview that is intended to see if you're a fit for the company and skilled enough to get the work done.

They aren't looking for someone that will dress them down to tell them that's incredibly insulting to ask something that took an academic a long time to come up with a solution for that. [Although a rough approach and fairly unfriendly. That shows a lack of desperation, confidence on the knowledge, and a good understanding of the difficulty of the task at hand (heck that's a good signal for won't underestimate points during planning)] (There's a singly linked list question that amazon used to ask that qualifies for this)

Re: Tech sector job interviews assess anxiety, not software skills: study

#388

Earlier quoted context omitted.

So have them explain it to you after they complete the problem with you out of the room.

If I’m in the room, I will steer them away from dead ends and ask leading questions when they get stuck. The point of the interview is to give the interviewee as much of a chance as possible to demonstrate their skills. I’ll say for sure, not everyone interviews this way. A lot of devs running interviews think of it as a “test” with pass/fail. I’d say the better interviewers see it as an opportunity to dig around and…

The problem is that there's lack of transparency in the process. Candidates don't know the "real" rubric that interviewers use, so anxiety could make the situation far more antagonistic than it is. And to some point, it is inherently antagonistic; the interviewee is being judged, vulnerable to being rejected, by someone who may or may not be unfair. So the anxiety ratchets up. This can lead to all sorts of bad behaviors like candidates not asking questions for fear of revealing ignorance or looking stupid. And a lot of interviewers as you say, especially at the top firms, don't really care about "how a candidate thinks" at all; they want to see correctness, they want to see efficiency, they want to see whiteboard code that can compile.

I don't think this necessarily means the "answer question alone and present answer after" approach is the right solution to interviewing, but it does show that interviewers might need to take some steps to make the process less opaque and daunting to lower candidates' potential anxiety.

Re: Tech sector job interviews assess anxiety, not software skills: study

#390
post #138

It seems pretty obvious to me that this kind of interviews are simply there to assess how much you want to work for a certain company. As in: would you be willing to study for months, go through mock interviews, read books, test your skills etc. to have a shot at working for us? Even though the majority of that stuff will likely have zero impact on your day to day work? That's all there is, really. I've had no proble…

Amazon is the king of assessing how much you want to work for the company. The recruiter will place a huge emphasis on nailing their Leadership Principles, and coming up with stories from your work to demonstrate you embody the Principles. They will even tell you that specific interviewers have specific LPs they will probe on, but in the actual interview they ask very veiled questions and you're supposed to know that…

This approach also works realy good when interviewing with other companies. I used the STAR [0] principle everytime after Amazon, it almost always worked. Having interviewed a couple of people at Amazon myself definetly helped.

[0] Situation - Task - Action - result, basically your story tellling format for Amazon interviews. Back the day it was even covered on their interview prep page.

Post reply on HN