Live data from Hacker News

The Utter Uselessness of Job Interviews

nytimes.com

131–140 of 410 posts

Re: The Utter Uselessness of Job Interviews

#131
post #90
post #65

Earlier quoted context omitted.

That has to be one of the most employee-hostile hiring strategies I've ever read.

You're pretty much limited to hiring either only the jobless or someone with the ability to work two jobs at once for an extended period of time while you hold your tryout. There are a lot of people who can't devote that kind of time to a second job (some candidates burn a week's vacation!) And it's not some mere formality, according to their stats they hire about a third of the people they try out.

> or someone with the ability to work two jobs at once for an extended period of time while you hold your tryout.

This is the part that's crazy to me. If you think you can accurately judge someone based the work they perform after a full normal workday/week, I have some beachfront property on the moon to sell you...

I have a feeling their conversion rate is so low because a lot of people get another offer during their trial and immediately jump ship.

Re: The Utter Uselessness of Job Interviews

#132
post #74

Earlier quoted context omitted.

Google tries to keep interview questions confidential - that's why candidates sign an NDA - and periodically rotates out questions that have appeared in public. Many engineers are also continually trying to think up new questions as well, usually based on their work. For most questions, there's no "right" answer, but there are a set of points that the interviewer wants to see you touch on. For example, they might fir…

Maybe, but that doesn't sound like my interview at Google, which was interesting but really rather random. Perhaps most notably, one interviewer became irate that I didn't know the "ps -o" flags off of the top of my head. :-/

According to `man ps` on my Mac, there are nearly seventy of them - how many did he want you to know?!

Re: The Utter Uselessness of Job Interviews

#133

This discussion misses an important element, the skill of the interviewer. It is unsurprising that unskilled interviewers' assessments are poor predictors of future performance. It would be interesting to measure the accuracy of interviewers who have had years of experience interviewing, hiring, and managing people. Here's how I think it works. Skilled interviewers are biased toward rejecting candidates based on any…

> For this use case only precision matters. Extremely low recall is fine.

Only if you have arbitrarily large amounts of time you can spend interviewing. Most of us don't.

Re: The Utter Uselessness of Job Interviews

#134

Earlier quoted context omitted.

That's a big red flag, at least in a Google setting. The reason is because when your dataset is in the petabytes, any algorithm bigger than O(N log N) is not going to terminate. You're not going to get any answer at all; your MapReduce is going to sit there burning CPU time for a day, and then you'll kill it, and you won't have any idea what went wrong. (This is learned from experience, if you couldn't tell.) In a st…

In my experience as a Google engineer, this is mostly false. None of the work I or any of the people I know well at Google is on petabyte datasets; most people just aren't on the hot path of indexing/websearch/youtube. In fact almost none of the stuff I was asked about in my interview has been relevant to my work. I have thought about complex algorithms two or three times in the past year.

Not only that, but (in my experience as a Google engineer), factors relating to the location of data (distribution and disk vs ram, etc.) often greatly outway algorithmic performance. Constant factors often dominate variable factors.

Re: The Utter Uselessness of Job Interviews

#135
post #109

Earlier quoted context omitted.

"I'll pay you $50/hour to work on a project here, Monday to Wednesday. At the end, you'll either get the job or we'll find a different candidate." I'd take that over every other bullshit interview process I've gone through in the past, while also feeling satisfied that it's a more accurate assessment of how I would actually perform at the job.

> The most significant shift we’ve made is requiring every final candidate to work with us for three to eight weeks on a contract basis. Candidates do real tasks alongside the people they would actually be working with if they had the job. They can work at night or on weekends, so they don’t have to leave their current jobs; most spend 10 to 20 hours a week working with Automattic, although that’s flexible. It's far…

Ok, yeah, that's pretty ridiculous. In concept, though, I think these kinds of trials can be a win-win.

Re: The Utter Uselessness of Job Interviews

#136
post #11

Laszlo Bock (former SVP of People at Google) did a great job summarizing decades of research around structured interviewing in his book 'Work Rules!' For a quick reference, the two defining criteria for a structured interview are: 1.) They use one or several consistent set(s) of questions, and 2.) There are clear criteria for assessing responses That second point is really important. You can't only ask candidates the…

From my experience, I'd say Google's interviews need to ask harder questions and last longer.

Today they ask fairly easy questions (given a list of integers, find the subsequence that has the following property etc. - basically leetcode medium level) that you can solve fairly easily using basic CS 101 knowledge. However, it ends up (again, IME) being a race against time where you have to whiteboard code a simple solution in 20 minutes approximately.

I'd much rather have them as questions that take real insight to solve, but have the interviews last 90 minutes or so.

Re: The Utter Uselessness of Job Interviews

#137
post #11

Laszlo Bock (former SVP of People at Google) did a great job summarizing decades of research around structured interviewing in his book 'Work Rules!' For a quick reference, the two defining criteria for a structured interview are: 1.) They use one or several consistent set(s) of questions, and 2.) There are clear criteria for assessing responses That second point is really important. You can't only ask candidates the…

Yes, but even when this is done well, there is still the question of what's measured vs what results in hiring good candidates and not hiring the others. Turning away a huge number of false negatives is also not optimal, especially in a situation where talent is scarce.

Re: The Utter Uselessness of Job Interviews

#138
post #74

Earlier quoted context omitted.

Google tries to keep interview questions confidential - that's why candidates sign an NDA - and periodically rotates out questions that have appeared in public. Many engineers are also continually trying to think up new questions as well, usually based on their work. For most questions, there's no "right" answer, but there are a set of points that the interviewer wants to see you touch on. For example, they might fir…

Maybe, but that doesn't sound like my interview at Google, which was interesting but really rather random. Perhaps most notably, one interviewer became irate that I didn't know the "ps -o" flags off of the top of my head. :-/

If the stuff online on Quora etc. are to be believed, the hiring committee will disregard such trivia interviews (and possibly send a node to the interviewer asking him/her to correct their technique).

Not sure how well this works in practice though.

Re: The Utter Uselessness of Job Interviews

#139

Earlier quoted context omitted.

Why did you conclude that you failed because of that? That sounds like a pass with flying colors. Did you specifically get feedback about that segment?

In the few remaining minutes after we agreed that it was possible to correctly deserialize a tree serialized in this way, I did not produce a linear time deserializer.

:-(

Re: The Utter Uselessness of Job Interviews

#140
post #65

Earlier quoted context omitted.

That has to be one of the most employee-hostile hiring strategies I've ever read.

"I'll pay you $50/hour to work on a project here, Monday to Wednesday. At the end, you'll either get the job or we'll find a different candidate." I'd take that over every other bullshit interview process I've gone through in the past, while also feeling satisfied that it's a more accurate assessment of how I would actually perform at the job.

Honestly I don't find this a realistic option either (although better than the approach in the GP's linked article...). IME at many companies you will be in great shape if you're set up with accounts/licenses/permissions/etc so that you can theoretically do something useful by the start of your second week. Once you have all of that set up, you still typically need a few days or a week+ being brought up to speed on projects, the structure of existing code/systems/etc.

Personally I feel like if you can't come up with an interview process that gives you enough confidence to risk a 3-6 month onboarding period on a new hire, you're doing something wrong.

Post reply on HN