Ask HN: When hiring for an open position what do you do?

Don't wait for the best candidate. Get the first hireable person onboard. When you're still getting off the ground, it's okay to work with a decent hire, than to miss to holiday season because you couldn't get work done.

If this is your first time hiring however, then you should interview a few people, in order to know what you are exactly looking for. Most people don't realize this, but hiring is closer to dating than it's to a test. You learn more about yourself with every date. Eventually you make an opinion of "good enough", and continue the relationship.

Getting referrals is great. But that doesn't mean you skip interviews entirely.

Your interview process should be structured. You exactly want to know in advance, who is asking what question and whether each question is measuring what you need as a skill. You can only do this well when you have a good sense of what you're looking for.

In order to be fair to everyone who applies, you can send them a work-sample test. e.g. for tech interviews, you can use hackerrank.com, or for non-tech, you can use candidatemetrics.com etc.

HTH

(Source: A lot of hiring over a number of years. Now running a bootcamp for candidates: http://InterviewKickstart.com)

I posted this tangent on a different thread here too but would like to get your thoughts:

On a slightly different note: in the past we have taken current developers and a potential hire out for lunch to see if there is "cultural fit". I don't like this idea anymore unless, we have agreed and intend to hire the candidate pending the lunch. However, the existing developers will not be able to override the hiring decision as it is not for them to say "no" but rather it is an opportunity for the candidate to decide if they can get along with the existing team? Is that fair?

P.S. I've always thought about getting involved in something like what you are doing. So many developers just don't "get" (and often care about) interviews.

As far as "Do you fish for the "best" candidate of a bunch or do hire as soon as you find a "hire-able" candidate?"

I think this really depends on what you're looking for. If the first person seems like a good fit, with a solid referral, and you don't want to continue looking, then sure, hire him/her.

On another note, I've seen people trying to hire candidates too fast backfire, as they rush to hire someone because they are in a dire need to fill a position fast. Usually these candidates aren't ones that are referred internally, but rather someone who came in through a recruiter.

This is a problem on the management side. Ideally, you want to start interviewing candidates 1-3 months before you really need them. That way, you won't be forced to hire the first person that seems like a good fit.

I'm actually surprised you get so many referrals from current employees.

A referrer shouldn't feel the consequences of a bad hire. The referrer didn't make the hiring decision, it's not their fault if you hired the person they referred.

If the referrer is a current employee, someone from a department other than development won't "feel" the negative consequences as someone in dev. So a referral from a developer might carry more weight than one from someone in sales. Additionally a current developers referral would carry more weight than a salesperson's referral because a developer ought to be able to gauge the candidates abilities a bit more. The negative consequences for the developer comes mostly from psychology (which affects some more than others) in that most people apply personal pressure to ensure the success of a hire that they referred for fear of looking bad (current employees might feel this more than say a third party business contact that referred someone).

So...

"A referrer shouldn't feel the consequences of a bad hire. The referrer didn't make the hiring decision, it's not their fault if you hired the person they referred."

A referrer might feel the consequences of a bad hire in that they, assuming they care about their personal referral capital and reputation, may have to pick up the slack for a "bad hire". You are correct they didn't make the decision to hire the person. The negative consequences aren't direct not intentional but they expose additional "skin" in a referral hence giving their referral more weight in ordering candidates. Maybe that's just wrong to consider and view things?

On a slightly different note: in the past we have taken current developers and a potential hire out for lunch to see if there is "cultural fit". I don't like this idea anymore unless, we have agreed and intend to hire the candidate pending the lunch. However, the existing developers will not be able to override the hiring decision as it is not for them to say "no" but rather it is an opportunity for the candidate to decide if they can get along with the existing team? Is that fair?

> Do you interview all potential candidates, or do you order the candidates based on a few factors such as their resume and the referrers credibility...

Yes, assuming the candidates background/experience is within range; usually a 30 minute Skype/phone screen will suffice as a first step in the process. Decide quickly, either move them forward to in-person meetings or thank them for their interest.

> Second, would the referrer feel the negative consequences of a bad hire.

Yes, match-making humans is tricky at best. We all want to be loved. Same in the workplace. Grown-ups get it.

> Do you fish for the "best" candidate of a bunch or do hire as soon as you find a "hire-able" candidate?

Scorecard what you're looking for in a candidate. Some very basic criteria 1) Can they DO the job? 2) Will they DO they job? 3) Can you live with them?

I posted this tangent on a different thread here too but would like to get your thoughts:

On a slightly different note: in the past we have taken current developers and a potential hire out for lunch to see if there is "cultural fit". I don't like this idea anymore unless, we have agreed and intend to hire the candidate pending the lunch. However, the existing developers will not be able to override the hiring decision as it is not for them to say "no" but rather it is an opportunity for the candidate to decide if they can get along with the existing team? Is that fair?

> an opportunity for the candidate to decide if they can get along with the existing team? Is that fair?

Earning both 'team buy-in' and helping a potential hire gain 'good-fit' insight with his prospective colleagues is a best practice in hiring. Better still, allow the potential hire & current developers meet 1:1 on the company card without your supervision. It implies trust and executive competence.

Why can't the existing team say "no"? Because I hope I didn't make a mistake and hire non-professionals who can't work with others in a professional environment. i define a professional environment to mean setting aside personal and private matters to conduct business oriented tasks. Will personalities conflict? Very possibly. What is a managers job? To manage people (and personalities) in order to achieve results. If there are severe issues with the new hire it may mean that an existing team member needs to go (or the new hire) whichever one is not setting personal/private issues aside...