Live data from Hacker News

The software industry's greatest sin: hiring

neilwithdata.com

271–280 of 590 posts

Re: The software industry's greatest sin: hiring

#271
I hire people from direct conversation that jumps around many subjects. My goal is to see the wheels turning, find what excites them, get the lights in their eyes shining. If I can’t do that in even 15 minutes, then I lose interest fast. If I can, an hour goes by in a flash and I really get to determine if they align with the role they’ve applied to.

I could care less about data structures and graphs. Do they care about code and can they learn and can they communicate. That’s what matters.

Re: The software industry's greatest sin: hiring

#272
post #18

The best way I see it, is to have this guy to work for a while, say a few weeks or a few months as a contractor, then either ends it or converts to a permanent job. This is the best interview approach.

When I was contracting I would nearly always get a job offer at the end of the contract. I always turned them down because I wanted to be a contractor, not an employee.

I expect the converse applies as well, someone who likes being an employee is unlikely to take up your offer.

Re: The software industry's greatest sin: hiring

#273

Earlier quoted context omitted.

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.

At Amazon a long time ago, people used to joke that for everyone working there, you could pick a group of interviewers that would have rejected that person.

Re: The software industry's greatest sin: hiring

#274

Earlier quoted context omitted.

Why do you say Google discriminates on the basis of race? I used to work there and was involved in the hiring processes and never saw evidence for this

> Why do you say Google discriminates on the basis of race? Google told their recruiters to actively not hire white or asian males for certain roles. https://www.theverge.com/2018/3/2/17070624/google-youtube-wi...

As an employee of Google who is involved in hiring let me tell you the process is extremely rigorous and we work very hard to make it bias free. I am not an unbiased individual myself but when it comes to hiring, I work extra hard to ensure fairness regardless of other person's characteristics.

Re: The software industry's greatest sin: hiring

#275

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…

It is true that you can succeed well at tech companies without a degree from a top school. Class, race, gender, sexual orientation are not barriers to success. That's the positive thing. The negative thing is that most tech companies heavily favor "top school" candidates and actively recruit for them. They would rather higher someone provably less qualified from a "top school" than someone else. They track and boast…

> most tech companies heavily favor "top school" candidates and actively recruit for them

Good job prospects upon graduation is one of the things that makes a school a "top school" and attracts smart students. If you wanted to hire people with no work experience, and money was no object, a "top school" would be the logical place to go to first. And I say this as someone who didn't go to a top school. So tech companies actively recruit from top schools only insofar as every other company in every other industry does. But that doesn't mean they recruit exclusively from top schools either. Stanford, MIT, and the Ivy League literally don't graduate enough students for that to be a feasible new grad hiring strategy.

You'd have to provide evidence for the first half of that statement though. My personal experience is after you've worked a few years, no one in software engineering cares where (or even if) you went to school. And any software engineer with a pulse located in the SF Bay Area can get at least a phone interview with any of the top tech companies.

Re: The software industry's greatest sin: hiring

#276
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…

These positions are entirely consistent, it's just a "pick your poison" situation. Whiteboard interviews are a skill unto themselves, with only a glancing relationship to day-to-day job content, artificially high-pressure, overly performative, etc. You measure hours invested in Leetcode, not suitability for the work. Take home projects probably collect good signals, but present a high and (crucially) asymmetric burde…

Pretty good description of all the gripes people have.

Hiring software devs is a damned if you do, damned if you don’t proposition—somebody is always gonna bitch.

Re: The software industry's greatest sin: hiring

#277

I hire people from direct conversation that jumps around many subjects. My goal is to see the wheels turning, find what excites them, get the lights in their eyes shining. If I can’t do that in even 15 minutes, then I lose interest fast. If I can, an hour goes by in a flash and I really get to determine if they align with the role they’ve applied to. I could care less about data structures and graphs. Do they care ab…

Many companies get by with mediocre developers, mine is one of them. You're not demonstrating that your interviewing style generates superior results.

Re: The software industry's greatest sin: hiring

#278
post #178

Earlier quoted context omitted.

Don't focus on the domain, focus on the coding. i.e. don't talk about what they were doing, talk about how they did it. Where there any performance considerations? concurrency? what did they do for testing? was it automated? How the thing deployed? do they maintain it? etc. etc. In doesn't matter that in all of the above I'm talking about the code used to talk to little green men on Mars (which you know nothing about…

How much faith do you really have in these questions? This could be your entire 45 minute interview: Where there any performance considerations: Yes, the spaceship was extremely slow at first. After reverse engineering the launch protocol, we discovered that we could increase speeds by 5x simply by limiting the fuel cell usage. "Oh tell me about your rocket fuel cell usage"- Well, we have this thing called a fuel cel…

> your entire 45 minute interview

There's your problem. Right there.

I don't think we can evaluate whether someone can do a decent job in 45 minutes. Or an hour. Sure, we can spot and confirm a hopeless case in 20. But beyond that, an hour is simply not enough.

I've been involved in hiring and interviewing for close to 15 years. The best results have been with candidates with whom I've arranged to have at least 90 minutes, and where that time ended up being well spent. It takes a while to get comfortable, to warm up, to establish a common ground. And it sure as hell takes time to actually discuss a technical problem, whether it's design or a programming problem, as the solution unfolds.

The desire to shoehorn an interview into at most 1-hour slots is not designed to find the best candidates. From where I look at things, it's designed around the idea that most business meetings are booked for one hour each, and the cadence in the day must fit the business of, well, doing business. And it kind of works, because everyone (or near it) has the context and shape of the problem fairly clear in their heads.

But for an interview? A process, where by definition you are dealing with people who are not well versed in your business? Companies book 1-hour interview slots because it's convenient - for their employees, including those who have no part in the interview process, but who are expected to attend other 1-hour meetings with the people who are involved.

The gauntlet of 1-hour interviews feels like a very much intended consequence of the organisation thinking in terms of 1-hour slots for everything. The result is a grueling exercise very few like, and almost everyone with experience despises. It's bad for the candidates, it's bad for interviewers, and I'm pretty sure it's bad for the companies.

But it keeps getting done that way because the cargo-cult of 1-hour slots for everything can not be reasoned with, or deviated from, results be damned.

Just think how well you would do the engineering and programming part of your profession if you had to carve everything into 1-hour slots. After all, PG wrote about it back in 2009: http://www.paulgraham.com/makersschedule.html

Re: The software industry's greatest sin: hiring

#279

some frustrating parts for me: 1. if i got an offer from your company a year ago, why do i need to redo the phone screen and entire process? 2. if someone has 10 years of experience at google and is L6, why do they need to do the standard process to work at some rinky startup?

The reason for (2) may be the following: can the company verify that the candidate did in fact work at Google for 10 years and reached L6? I don't know about Google, but if someone claims they worked at Microsoft as an L65, and they call Microsoft to fact-check, Microsoft will only tell them when that person started and ended their employment there. They will not disclose any other information.

Re: The software industry's greatest sin: hiring

#280
post #144

Earlier quoted context omitted.

> huge amount of pent up demand for senior developers But is leetcode really the way to find them?

Isn't Google known for analyzing the hell out of their candidates for predictors of success? They dropped the GPA requirement, college degree requirement, brain teaser questions - but they kept the leetcode questions. It's probably least bad of everything else they've looked at.

Google talks a lot of shit about rather missing out on a good candidate than hiring a bad one.

What removing a metric tells you is that people that they regretted hiring people who looked fine on those metrics. They have no way to determine if people who failed on other metrics were better than the people they hired.

The problem is that if you measure someone by a metric you can’t actually disregard it in your decision process. Even a double blind affects the subject’s behavior.

Post reply on HN