[cauterized]

I've never had a hire go wrong for technical reasons. I have hired, participated in hiring, or inherited several developers who had to be let go for reasons related to attitude or soft skills. Some examples:

- a guy with an alcohol problem who would disappear for a week at a time or come in to work sloshed

- a junior developer who had major problems with authority, mixed with bizarre paranoia. He refused to take direction from his team lead and had to be let go after he started accusing anyone and everyone of trying to undermine him.

- a guy so obsessed with doing everything perfectly that it took him a year to produce what other engineers could accomplish in a month. Granted, his work has been running for 3 years now without a single bug, but even taking that into account he still wasn't cost effective to have on the team

- a developer who refused to take ownership of his projects and insisted that everything expected of him be specified down to the pixel (might work at a large corporation, but not a startup - we don't have time to hand-hold like that)

- a guy who was hired as a junior mobile engineer and then began throwing fits when we denied him the authority to change the priorities of the entire web and mobile product team

Takeaways:

It's fairly easy to assess who is and is not capable of developing basic CRUD apps. Getting meaningful information about a person's neuroses, self-management ability, and ability to play well with others is extremely difficult in the space of a handful of hours of interviewing.

[dilap]

The perfect code guy doesn't sound so bad.

[pryelluw]

Until you ship a product so late that its declared DOA. Perfect coders are more dangerous than shitty ones. They usually slow down progress in the name of perfection so much that nothing gets done. IMO.

[stouset]

I don't know that I agree that perfect coders are more dangerous than shitty ones. When you're behind on a project because someone is taking too long, it's upfront and obvious and usually they can be encouraged to speed up things as long as they document where work needs to be done afterward.

Bad developers are the gift that keeps on giving. Everything looks great, you ship, it mostly works, and then you spend four years struggling to build anything on top of what was written, squashing data-loss bugs that take weeks to track down and can never have their root causes fixed, etc.

Companies that end up in the latter situation are basically zombies. They're already effectively dead, but nobody knows this is the case for years, pouring time, effort, and money into a bottomless sinkhole.

Perfect coders can also serve as really good mentors on teams, and catch serious issues everyone else would have missed.

[shshhdhs]

For a startup, sure. But the machine doing LASIK surgery on a human's cornea dozens of times per day absolutely should have a perfect coder. There are some industries where sloppy code should get you fired, because it will get someone killed.

[scarface74]

https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...

People who are Smart but don’t Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. They would rather mull over something academic about a problem rather than ship on time.

[cauterized]

If you're building life support software or manned lunar probes, maybe you want him on your team.

If you're a startup trying to find product-market fit before you run out of funding, better to ship a few bugs every week (in features that have an 80% chance of not existing or being rewritten anyway within a few years) than nothing at all for months.

[acjohnson55]

That's one reason we rely heavily on thorough, structured reference checks.

[lj3]

Does that actually work? I've never had anybody ask me for references for a technical job. Few people are going to say anything bad about a former employee for fear of being sued. And that's if the candidate plays fair. For less than $100, you can bribe three people to say you're the next best thing to Steve Jobs himself.

[acjohnson55]

It works great! I agree that we're unusual in the weight that we put in our references, but I've never had it be a blocker with an applicant. We run every reference through the same script of questions, for a call that tends to last about 30 minutes. Since many engineers often talk in interviews about what their team did, versus their own contributions, the third-party viewpoint is very helpful for getting that perspective. We've found references to be helpful in differentiating between average, good, great, and exceptional individual performance, and extremely helpful in understanding a candidate's teamwork. I personally find it vastly more useful than whiteboard coding and work samples for predicting how a candidate will actually perform.

Aside from their usefulness in making hiring decisions, as a manager, it has been great for jump-starting my relationship with my new hires with context on how they have worked in the past. That has been really helpful.

I agree with you that references have some limitations. We do, of course, expect that applicants will cherry-pick their references to make themselves shine. Yet, I typically get very candid feedback from the reference providers. I think most people simply aren't built to straight-up lie for someone else, even if they are a friend. References are typically someone in some level of authority someplace else, and they put their word on the line. Most people seem to take that seriously.

Another limitation is that people often can't use their current boss as a reference, and for people on an upward career trajectory, that may exclude someone who is capable of talking about the applicant's greatest career achievements. This was the case for me when I applied to my current role.

Lastly, we have to keep in mind that any single reference is colored by the biases and personality of its provider. And some applicants simply have access to better referrers than others for reasons out of their control. All we can do is make judgment calls when it comes to these things.

[cauterized]

How do you structure your reference checks? And what do you do for new hires who are very early in their careers and don't have real work references?

Also, I'll note that three of the above employees were sourced via referral from either other employees or friends of execs.

[acjohnson55]

See my other response for more context, but we have a behavioral interview-style reference call script, which is universal for all roles at the company. But it still does tend to reveal good knowledge about the candidate's technical ability, even with generic questions. Occasionally, I'll add an additional question for tech context, but I find the basic script to be pretty comprehensive.

I'll echo the sibling post for inexperienced candidates. References from jobs in other careers also work. But to be honest, if someone can't find anyone to speak in-depth about their achievements and teamwork, they are going to have a really tough time passing the bar to get hired. We don't generally do work samples of any kind, but I'd probably have to make an exception in that case, to get some kind of picture for how they work.

We've certainly had a couple people not work out on our engineering team. But I don't think we've ever hired a total dud or a toxic person.

It's interesting that you mention internal referrals, because I think that can be a major source of bias. People feel obligated to put in a good word for their friend, and if I hold the referrer in high personal regard, my natural skepticism of them as a reference diminishes. I feel referrers should say their (small) piece at the beginning, but from that point onward, the hiring process needs to be independent of their influence.

[badminton1]

References from internship colleagues/managers, school mates or teachers can work a bit. But be aware that you will be getting very few data points.

Now, it is easier to influence new professionals than changing habits of seasoned professionals.

[blablabla123]

It's definitely fair to check this. Also I think this works very well when the hire worked in a well-ordered place beforehands. On the contrary, if someone worked at a toxic work place before - it's probably counterproductive to ask colleagues or even managers. Odds are high the person is exactly leaving because of that.

[pcurve]

Other than hiring someone as contractor first, have a trial run for 6 months, what do you think is a good way to minimize issues like this?

[brogrammernot]

Re: trial run. I do not suggest this.

I'm not a world class developer, but I'm a good one, maybe great depending on the day but I had 3 offers to be contract to hire and I refused.

You may save yourself a bad hire, but more than likely you will do so at the cost of missing out on hiring a handful of good ones.

If I'm interviewing with you and you don't trust me enough to make me an employee from day one then why should I trust you as a company?

[scarface74]

I will only take a contract position if that's the only way I can get a job doing something I know academically -- I studied the technology and did a side project -- but don't have any on the job experience.

Basically, a resume builder

[pcurve]

I agree. Good ones always have good options. I avoid contract to hire, because even a talented developer who chooses to stay as contractor will avoid contract-to-hire positions.

I guess you just have to go with who you think is the best candidate, and if the decision turns out to be incorrect, fire quickly.