Live data from Hacker News

The software industry's greatest sin: hiring

neilwithdata.com

161–170 of 590 posts

Re: The software industry's greatest sin: hiring

#161

Technical interviews were once seen as a breath of fresh air. You can be a nobody without connections or degrees and if you can prove you have skills during an interview process you may be hired. Contrast this with other hiring processes which are more irrational, like med residency match, investment banks favoring "target school graduates", law firms favoring "top 14 graduates", etc. I think whiteboarding is dumb an…

> Technical interviews were once seen as a breath of fresh air. > You can be a nobody without connections or degrees and if you can prove you have skills during an interview process you may be hired. I think it stops being seen as a breath of fresh air when e.g. Google's explicit expectation is that you will spend multiple months studying for the privilege before interviewing with them.

As an ex-Googler who did many interviews while there, I've never heard of that expectation.

Re: The software industry's greatest sin: hiring

#162
post #50

You've got to know if the other person can code. Lots of people can talk a mean game and make nothing and few people can spot them. That's the thing, though. If you make a reputation as the kind of guy who can near 100% spot the good engineers, you will make boatloads of money. An employer will pay you more than $30k if you only do great hires. You do 10 of them with your conversation out to lunch and you've made $30…

> You've got to know if the other person can code. Lots of people can talk a mean game and make nothing and few people can spot them. If only this were true. I've co-authored a (technical) book, edited another, have dozens of OSS contributions, and GitHub projects with hundreds of stars. Everyone still tries to whiteboard interview me. Usually I tell them to screw off, but still. My theory is that (a) people are too…

Man the guy you responded to is right. I've interviewed and mistakenly hired several types of these people.

Here's the thing, you're not too wrong either. I don't doubt that there are tons of great programmers who can't pass a technical whiteboard interview for various reasons.

But without a doubt if you pass a whiteboard interview your success at that interview is highly highly correlated with your success at the job.

You tell me... how do we screen for these master bullshitters and hire people like you? I would love to know because I see no other alternative than to use whiteboard interviews. I want to hire someone like you, but I have no clue how to differentiate you from a person who can really code and a person who is a master bullshitter.

Re: The software industry's greatest sin: hiring

#163
Would companies make more money if they hired in this "wholistic" way? Every time this comes up, I struggle to see how these top tier companies with these algo-intensive interview practices are compromised by not being "wholistic." They're raking in cash. By all quantitative measures their hiring is working extremely well for them.

Re: The software industry's greatest sin: hiring

#164
post #154

We (Ambra Health) a few years ago decided our "typical" multi-hour multi-week interview process was a lot of effort for pretty mixed outcomes. We realized an interview can't really answer the most important questions: how a candidate works, and what's it like to work together. So we added an option to interview by way of a paid trial period (work part-time nights/weekends for a few weeks with the hiring team). Figure…

I do think this is really the best way to "interview"... it's weird how hard it is to correctly evaluate somebody in two hours of talking to them and yet how easy it is to evaluate somebody in even two days of working with them.

Re: The software industry's greatest sin: hiring

#165
post #54

This makes so much sense. I've stopped doing in-depth technical interviews for precisely this reason. Instead, I take the developer out for lunch and spend an afternoon discussing our software stack and business with them. It always gives be better results. There is no stress. I don't want to see their code, but I do want to understand how they think and work.

Would you hire a sculpter by taking them to lunch and talking about tools but never seeing their sculpture?

Would you judge a jazz musician by asking him where Miles Davis learned to play music?

Re: The software industry's greatest sin: hiring

#166

My favorite interview was at digg.com. A four hour interview was going great. My dream job. I knew their tech solid. Then the last guy - walked in [ianeure]. He asked: "What is a having statement in sql". I leaped in - rambled on and on how you can filter aggregated sets. His response: "I don't think you know how they work." I sat there confused and concerned. He explained you don't need a group by with a having stat…

Some of this could be fixed if companies required technical questions to be vetted before they were used. (For example, by testing them on other people at the company.) Allowing people to come up with questions on their own means there is no quality control.

I wonder how many people could pass software interviews at the company they work for. How many could do it without studying and preparing for weeks? I doubt I could.

Re: The software industry's greatest sin: hiring

#168
I did on a onsite at Google and learned the most during the lunch portion, my interviewers didn't know basic ES6. At lunch, I talked with an engineer who was a teacher before his first industry job at Google which he has worked for 5 years, in contrast with me that had work at 4 different places in 5 years. I didn't get the job even though my github and industry skills were more vast. They would rather hire "theory over practice" developers because they are easier to retain, which is fair.

Re: The software industry's greatest sin: hiring

#169
post #137

My favorite interview was at digg.com. A four hour interview was going great. My dream job. I knew their tech solid. Then the last guy - walked in [ianeure]. He asked: "What is a having statement in sql". I leaped in - rambled on and on how you can filter aggregated sets. His response: "I don't think you know how they work." I sat there confused and concerned. He explained you don't need a group by with a having stat…

> and that I needed to go back and study sql I once had an interviewer with two (TWO!) PhDs. He made sure that I knew he had two (TWO!) PhDs by handing me his business card as we sat down and casually remarking that he had two PhDs (see, right there, two of 'em, yupperoo). This behavior ("he's kind of jerk, and he has two PhDs") had been accurately foretold by the prior interviewer (that session had gone great). The…

[deleted]

Re: The software industry's greatest sin: hiring

#170

My favorite interview was at digg.com. A four hour interview was going great. My dream job. I knew their tech solid. Then the last guy - walked in [ianeure]. He asked: "What is a having statement in sql". I leaped in - rambled on and on how you can filter aggregated sets. His response: "I don't think you know how they work." I sat there confused and concerned. He explained you don't need a group by with a having stat…

Some of this could be fixed if companies required technical questions to be vetted before they were used. (For example, by testing them on other people at the company.) Allowing people to come up with questions on their own means there is no quality control.

Four eyes principle: don't let people come up with stuff on thwir own without any of their (technically skilled) collegues ever seeing it.
Post reply on HN