Live data from Hacker News

The software industry's greatest sin: hiring

neilwithdata.com

151–160 of 590 posts

Re: The software industry's greatest sin: hiring

#151
Developer hiring is not broken, it is the people who do the hiring that are.

It could not be more clear to me and their conclusion only makes me more sure of it

  We need to throw away this idea that you can get the measure of a person just by subjecting them to a faux-IQ test. 

  We need to fully internalize that being a great software developer is holistic and draws on abilities ranging from, yes, technical skill, but also empathy, experience, taste, grit, perseverance, and independence. 

  Being a great software developer is multi-disciplinary and we need to actively and vigorously reject the notion that just being good at "cutting code" and inverting a binary tree is the end of the story 

  and is therefore the only axis on which to assess people who work in teams and build products for other human beings.
The kind of person who is able to judge someone for such skills, is also probably very high up the company ladder, a busy person who cannot interview every candidate. At the end of the day, 50% of interviews are going to be conducted by people who were until recently new-grads and have only taken exams which are neither technologically holistic nor gauge for non-technical essentials.

This is not a problem in the system. This is a problem of scale.

Re: The software industry's greatest sin: hiring

#152
post #115

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…

> He explained you don't need a group by in a having statement and that I needed to go back and study sql. I sat there awkwardly [I have been writing sql since I was 14 - I was 25]. He's technically right though. For instance in postgres, you don't need to have a GROUP BY clause when using HAVING https://www.postgresql.org/docs/current/sql-select.html#SQL-...

SQL isn't the most portable language. Postgres has special behavior for aggregates/having without group by which essentially creates an implicit group by, other engines will raise an error (SQL Server iirc)

Clearly not something to nitpick over in an interview

Re: The software industry's greatest sin: hiring

#153
post #115

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…

> He explained you don't need a group by in a having statement and that I needed to go back and study sql. I sat there awkwardly [I have been writing sql since I was 14 - I was 25]. He's technically right though. For instance in postgres, you don't need to have a GROUP BY clause when using HAVING https://www.postgresql.org/docs/current/sql-select.html#SQL-...

"Technically correct", the most irritating form of "correct"

Re: The software industry's greatest sin: hiring

#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). Figured maybe some people might prefer that, but probably wouldn't be feasible for most.

Every candidate since has chosen that route, with very good outcomes - so far, everyone who did well in the trial period has been a good hire. Some of our best hires did not interview well (and would not have been hired under our old process), but were outstanding in the trial period. And, a couple candidates interviewed so well we almost skipped the trial period, but they struggled to complete even simple tasks during the trial.

We've now optimized interviews for that process, where the decision is primarily about whether it's worth moving to a trial period. That usually only takes a short screening call and a 1-hour call with the team (we're a remote team, even before quarantines).

BTW, if you'd like to experience this first-hand, we're hiring - https://news.ycombinator.com/item?id=22753515

Re: The software industry's greatest sin: hiring

#155
post #47

> Developer hiring is broken This seems to be a pretty popular opinion. It totally might be right, but it’s not my own experience, so I have a serious question because maybe I don’t know what’s happening out there with most hiring today - what are the broad-stroke outcomes that demonstrate that hiring isn’t working? Are there statistics that show that hiring has problems? All of the reasons given in the article are c…

I'm a software engineer working at a company in the hiring space. I've done over 400 technical interviews in the last year alone, and ... this is a hot take, and not the view of my employer, but I think developer hiring processes are fine (At least, at most mature companies.) There's a problem at the moment in the market that there's a huge amount of pent up demand for senior developers. The market has responded with…

> I think the real sin is that we're afraid to tell people they aren't very good at programming yet, and we use technical interviews as a scape goat.

So does this mean that programming education is broken? That companies should invest more in training? That bootcamps should revamp what they teach? That there should be industry standards for what programmers at different levels should be expected to know?

The most maddening thing about interviews imo is the opacity. There's always uncertainty about where exactly things went wrong, and how it should be fixed next time. It's almost a meta-engineering problem of its own. And it's a metaphor for the lack of software engineering standards.

Re: The software industry's greatest sin: hiring

#156

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.

Re: The software industry's greatest sin: hiring

#157

Earlier quoted context omitted.

You may be better at interviewing than some of us. Personally, I can't figure out how to tell if someone can actually write code in a conversation.

ask them what they've built in the past and start digging in from there.

I've certainly done that. But if it's in a domain I'm not familiar with, I'm not going to be able to tell if its real.

Re: The software industry's greatest sin: hiring

#158
I had a candidate totally fail the algorithm interview. Is a binary tree balanced? I thumbs downed him.

I was overruled and he was hired based off of his credentials, resume and what he talked about in the interview with another person who just had a talk about "architecture."

Turns out the guy can't even code. He constantly just talks about architecture and tries to tell everyone to completely change the architecture to be event driven. But when given an assignment to work on the actual product he totally fails. It's crazy, the man is a complete clown.

Here's what I think. You can't hire a candidate based off of just a technical interview alone. But you can't just hire a candidate off of his credentials either. There's too much room for lies and deception in this area. You need both metrics in order to get the most information out of a candidate. It goes both ways.

The Technical Interview was invented because of too much of the above problem. People who are charismatic and exaggerate their resume and turn out not being able to code. Of course nowadays with canned memorization going rampant and technical interviews becoming IQ tests there's really no accurate way measuring a candidate.

I'll just say that as bad as an IQ test is in identifying good programmers who are bad at IQ tests, a person with high IQ is likely going to be a good programmer.

Re: The software industry's greatest sin: hiring

#159
Yes, it's the reason I'm not currently employed in the software industry. After a decade of being a professional developer, I decided to start building physical things and learning other maker skill sets. Whenever I need some extra income I start looking at software jobs, but I'm not able to think clearly during these sort of test situations, and they don't usually go well. I've built so many things from software products and businesses from scratch and could do so again, but it just makes me bitter to even subject myself to this initiation. I would be much happier (and companies would have more diverse candidates) if a resume and past experience did the talking like other professions.

Re: The software industry's greatest sin: hiring

#160
post #138

Earlier quoted context omitted.

> He went on to ruin digg.com (the rewrite everything guy) and I promised myself to never be a dick to people I interview. Sounds like the interview process worked for you. You found out that you don't want to work with him and didn't.

More ideally, the interview process would have found that OP was a better fit for the company and that the rewrite-everything guy was producing abnormal interview reviews and should be demoted.

You're absolutely right. Unfortunately the broken-ness of the interview process is not limited to the interview itself.

I've interviewed around 40-50 folks for $role at $wildly_successful_megacorp.

My qualifications: zero training, zero oversight.

I'm getting a lot better and more consistent. But I have still left a lot of interviews thinking how poorly I have done, and needing to reflect on how things could have gone differently.

It's very easy to think of interviewing folks as a chore or merely a favor to $other_manager. For something so vital to the long term health of the company, it's really appalling how little effort is put into it.

Post reply on HN