My recommended developer interviewing and hiring practices

Throughout my career, as a software developer and manager at growing companies, I've interviewed a lot of candidates for different software developer positions. Everything from college interns to CTO.  I've also been on the other side of the table, interviewing with lots of great companies.  I've learned a lot about I think what works and what doesn't work, what are good ways to evaluate developers, and wanted to share my experiences.

My Ideal Process

First, let me share with you my ideal interview process. I'll get in to specifics of why I think this process works great later.

1. Recruiter or HR does the initial filtering of candidates/resumes. They need to work closely with a high level software development manager or VP to get a sense of what they are looking for.
2. Before the recruiter reaches out to candidates, a hiring manager (software development manager/director/VP that needs the position, NOT a recruiter or HR) must approve the candidate. This will help HR/recruiter to learn more about what you are looking for.
3. Recruiter/HR reaches out to the candidate and talks to them. They discuss a little about the position, company, company benefits, etc. This weeds out candidates that are not interested at all (salary requirements too high, not the type of job candidate is looking for, etc)
4. Recruiter/HR sets up a technical phone screen with a senior developer or manager.
5. In the phone screen, coding questions are asked, along with general background questions, maybe a design question. This phone screen is to weed out candidates that are obvious non-matches.
6. If they pass the phone screen, they come on site (provided the position is not remote). There are at least 4 different interview slots (no less than 45 minutes each). Interview slots should be individual, no double teaming, or committee interviews (except for shadowing and training people on interviewing). Some coding questions are asked during on site interviews, some design, management questions if a manager position, etc. A variety of types of roles interview the candidate - at least one manager, at least one developer. 
7. After the on site interviews, feedback is gathered from everyone who talked to the candidate (including the phone screener and recruiter). Feedback should be collaborative, ideally in a meeting. Every interviewer must give a yes or no recommendation.
8. The hiring manager makes a decision on whether to give an offer. To give an offer there must be a strong consensus from everyone who interviewed. There should be no strong objections from anyone, and most interviewers must feel strongly about wanting to hire the candidate.
9. Hiring manager decides what position to give an offer for and works with recruiter on salary/bonus/options/etc. There should be a developer career progression ladder established already with positions, and salary given in the offer should fall within the bands for the position. Decision on what position/salary to offer is based on where hiring manager sees them fitting (at least partially based on interviewers' feedback), plus what the candidate is looking for. Hiring manager may need to have a follow on conversation with candidate to determine this.

My Recommendations

#1 - Do a Phone Screen First!

An on site interview is a big time sink, both for the candidate and the interviewers. It really sucks to go through an on site interview for someone who is obviously not a fit. A technical phone (or Skype) screen with a developer or development manager is a great way to weed out candidates, saving everyone time. Here are some tips:

1. The phone interviewer should be a senior developer, or dev manager, with a lot of experience interviewing. Someone you can trust to do a good interview. If the phone interviewer says no, no one else gets to talk to them, so you have to trust that this interviewer isn't saying no to potentially good candidates.
2. Ask coding questions! Just because you're over the phone doesn't mean you should stick to just discussion questions. If you're hiring someone to write code, you don't want to hire someone who is terrible at writing code.  I've interviewed (and worked with) lots of people who had great resumes, could talk all day long, but were awful at coding and couldn't get anything done - asking a coding question can weed these people out so you're not wasting more time. I'd highly recommend https://codinghire.com/ for interactive coding - it has tons of great features. A shared google doc is OK as well if you don't want to spend the $ on coding hire (although I think it's well worth it). Just be sure you use something to watch them code interactively. I'll talk more later in this post about what types of coding questions are good.
3. Be more forgiving in phone interviews than on site interviews. If you aren't sure whether the candidate should pass or not, bring them on site. You can take a firmer stance in on site interviews where other interviewers will get an opinion.

#2 - Research the candidate!

Every interviewer should spend just a little time googling the candidate before the interview. Here are some things to look for:

1. Github - Having a Github account is a plus (and they should have that on their resume). Having their own projects, and/or contributions to other open source projects (not just forks with no changes), is a huge plus. This generally shows a passion for being a developer, and could show that they will be looking for outside solutions for problems, and keep up with new technologies.
   But, not having a Github account shouldn't be considered a strike against someone. There are tons of good developers out there that don't have any publicly available code for a variety of reasons . So only look at publicly available code as a bonus. And a big Github repo with lots of projects isn't always a good thing. It might mean that the person gets bored and can never keep their attention on a single thing. I've worked with plenty of developers like this, that had impressive Github repos, and were always talking about new things, but could never get projects finished.
2. Side projects - Having side projects, like a website that they developed and host themselves, a mobile app, etc. is generally a positive. This shows that they are passionate enough about writing software and learning new things that they'll invest a lot of time on the side. Unlike Github repos, this shows that they can actually produce working projects. Like Github accounts though this should only be considered a bonus, and not a negative if someone doesn't have one. You'll want to make sure too that the side project doesn't occupy too much of their time - you don't want someone spending their work day on their side project!
3. Blog posts/Twitter posts - These can show you some specifics of what they've worked on, what they're interested in, etc.

#3 - Get a good lineup to interview

Unless your company is tiny, you should have at least 4 people interview each candidate that you give an offer to. Different interviewer opinions/perspectives are very important here. Interviewers should have diverse roles too - not all managers, and not all developers. The lineup should definitely include at least one person the candidate would be working with on a day to day basis. It's never good to have high level managers do all of the interviewing.

Following these will ensure the best possible evaluation of the candidates, and give the candidates a better understanding of the company and position.

#4 - Only one person interviewing the candidate at a time

No double teaming of a candidate, or even worse, committee interviewers. This puts too much pressure on the candidate - they'll get no mental breaks in between questions, and it feels a little too hostile. You'll get a much better and personal evaluation of a candidate if it's one on one.

The exception here is if you're training people for how to interview, either by them sitting through your interviews to learn, or you evaluating them. But for these setups, only one of the interviewers should be asking the candidate the questions, the other is there to observe. Explain that the candidate upfront too.

#5 - Think of good coding questions to ask!

Like I said in #1, you need to ask coding questions. You're hiring someone to write software, why wouldn't you ask them to write code to evaluate them? You want to be in the room with them to observe how they solve the problem and answer questions - don't give them a problem and leave them alone for a long time. Whether or not you have a computer for them, writing on a whiteboard vs. paper, etc. doesn't really matter. What matters is that you have good questions to ask and you watch them solve them. You want to be able to say "If a developer did poorly on my question, they're probably not a good developer".  Not "If a developer answered my question well they're a ROCK STAR!" If your question is that tough, most good developers aren't going to answer it well.

Here are some things to avoid with your questions:

1. No clever solutions - the problem shouldn't require a clever solution. If you ask a question that has only a clever solution, many good people won't think of the solution and totally bomb it.
2. Not too long or complex - if it takes a good developer 30 minutes to complete your problem, that's way too long. You have to leave room for someone to start to go down the wrong path and correct themselves - good developers do this every day.
3. No CS curriculum questions, unless you're interviewing exclusively entry level developers - Please, NO breadth first search, sorting, etc. questions. If a dev with 10 years of experience can't answer these types of questions that someone fresh out of school can, it certainly does not mean that the entry level dev is better. And really, how often in your day to day development do you need to write something like a breadth first search? And stay light on the CS concepts. Just because someone doesn't remember big O notation for different sort algorithms off the top of their head doesn't mean they are a bad developer.
4. Language agnostic - The question shouldn't be too specific to a single programming language. You want to be looking for good developers overall, and for most positions, you don't want to require them to have extensive experience in your main language. You're limiting yourself too much there, and a good developer can learn another language easily.
5. Watch glassdoor.com - sometimes people will post interview recaps on there and give away the questions you asked. If that happens change up your questions. You don't want someone to do well because they knew the answer coming in to the interview.

#6 - Ask them to talk through a solution for some problem

Software developers do more than just write code so you should ask more than just coding questions. For experienced developers in particular it's good to describe a problem or design question, and see how they can solve it. Ask them to design something, how they would diagnose and fix an issue, etc. These questions give an opportunity for developers with good real world experience to shine.

Be careful here though, you want the problem to be open ended. You don't want to have to spend a lot of time explaining it - if you do you're probably going to give them hints to what you are looking for. I am not a fan of describing a very specific problem in your product's domain and seeing how they answer - that requires too much explanation of your product's domain.

Also, you have to consider that candidates will all have a different background here, so you should be looking to learn something from their response.

#7 - Observe their thought processes for solving problems

For both the coding questions and talking through the problem, observe how they go about solving the problem. This is more important than the end solution. Do they try to come up with the perfect solution and don't come up with anything, not even mentioning good but not perfect solutions? This is an indication that the person might be smart but will have trouble getting things delivered. There are many other things to watch for when they solve the problems.

#8 - Culture fit is overrated

I've read many articles and heard many people talk about how critical culture fit is, that if a candidate doesn't seem to have the same values, motivations, etc. as the rest of your team, that they won't work out. That if it doesn't seem that they'd fit in with the rest of your developers, then you shouldn't hire them. Well, this line of thinking is really flawed, borderline discriminatory. If you're looking to hire developers you're growing, and you need to grow your culture too. You're never going to grow your culture by hiring the same type of people. And, you're REALLY limiting yourself and will have a much harder time finding people. If you find someone really good, who might not fit in with the rest of your team, what makes more sense - rejecting that person or diversifying your team? Great developers who will want to work for you are rare, you need to do everything you can to accommodate them, even if it forces some culture change at your company. What do you want the culture of your company to be - a place that tackles tough challenges and gets things done, or a frat house environment?

Something I've seen first hand and I'm sure is common is thinking less of someone because you don't think they will work the long and crazy hours that everyone else does. That's not a sign that the candidate isn't a fit, that's a sign that you need to change your culture to not be somewhere that people work crazy hours all of the time. That's a whole other topic of discussion though...

Now that being said, I do think there is value to someone being a "culture" fit, but I define culture as the technical culture. Like, if you have a culture of always looking for off the shelf tools/open source projects, researching and evaluating them, and incorporating them, and you're interviewing someone who has spent the last 10 years doing developing on the same stack and doesn't keep up with new technologies, that could definitely be an issue. Or, if your developers "wear a lot of different hats", and are involved in ops, doing both front end and back end, etc, and you're interviewing someone who just wants to do back end and doesn't have much interest in ops, that is definitely an issue.

#9 - Communication skills are very important

If you are working a team, the ability to communicate well, both verbally and written, is really important. You probably don't want to hire someone that cannot take verbal feedback and understand what you mean, or someone whose written communication is hard to decipher and does not make sense. I personally have seen this at multiple jobs, that someone might be a strong developer but if they have trouble with code review feedback, or keep interpreting the wrong things from descriptions of the work, that will cause problems.

Now if someone is really strong technically, you can live with some communication issues. But a lot of times these issues get discounted during interviews in favor of technical prowess, and they should not. You can see signs of this in the interview - if they misinterpret the questions you are asking, or especially if you answer questions for them and they still have the wrong interpretation, you're probably going to have trouble working with them.

Communication skills are especially critical if the position is remote, or if you have a distributed team.

#10 - Be courteous to the candidates

Throughout the interview, show courtesy to the candidate. Remember that you are selling the company, and if you're an asshole to the candidate, you're now a reason why the candidate won't want to come work for the company. If a candidate doesn't answer your question well, don't make them feel stupid. Of course you can answer it well because you came up with the question, but just put yourself in their shoes, and think to times you've been interviewed. If the candidate is just not doing well and there is no way you would recommend hiring them, still be nice to them. You don't want bad reviews of your company showing up on Glassdoor, and the easiest way to get these is to be rude.

#11 - Be positive and sell the company

Don't forget that the candidate is evaluating your company, and you want to make it sound like a great place to work (even if it's not). Be positive and upbeat throughout the interview! If every interviewer acts grumpy and like they're too busy to deal with an interview, the candidate is not going to want to come work for the company. Try to act like you're happy to work at the company and excited to bring someone else on to the team.

Now, you want to be realistic here, if you're too positive and don't mention any of the issues with the company if the candidate asks you, it's too obvious you're not telling the whole truth and that will be a red flag to the candidate. But always try to have a positive flip side for every negative thing you mention.

#12 - Collaborative feedback from all interviewers

When the interview is finished, you need to collect feedback from everyone who interviewed the candidate. Every interviewer needs to form an opinion on whether to hire or not - no "I'm not sure" feedback. Everyone's feedback is valuable so you need an opinion from everyone. Feedback should be detailed too, more than just a yes or no, so you can know why the interviewer has the opinion that they do. The hiring manager needs to consider everyone's input too - don't discount someone's opinion. If you're going to discount someone's opinion, they probably shouldn't be interviewing.

For things to work best this should be collaborative. A quick meeting with everyone who interviewed the candidate (including the phone screener, and possibly HR/recruiting) is best but many times this is too difficult to get everyone together for, so a group chat or having everyone email their feedback to everyone else is good. Everyone seeing everyone else's feedback is important because it can change the opinions. An example that I've gone through is that the candidate was a little careless in the coding question - they missed the edge cases, had logic backwards, etc. I kind of overlooked this and still recommended the candidate. But when I heard similar issues from all of the other interviewers I changed my mind - the issue was not isolated to just me. Without the collaborative feedback I wouldn't have heard this.

Something to watch out for with collaborative feedback though is that the interviewers are respectful of each others' feedback. No bullying or convincing interviewers to change their opinion. Timid interviewers might just go with the group to avoid a conflict but this is not good - you want everyone to feel free to share their opinion.

And, at the end of the day, the group does not have to 100% agree on a final decision. The hiring manager makes the final decision taking the interviewers feedback in to consideration. This is OK - you're never going to get everyone to agree all of the time, and if you do, you're probably bullying people to come to an agreement which will make it less likely they'll give real feedback which the hiring manager needs.

However, you don't want anyone to be strongly opposed to giving an offer to the candidate. A "well, if it were my decision alone I would say no, but, I can understand why we'd want to give the candidate an offer" is OK, but a "This is a really bad idea, I don't see how you all can think that we should hire this person, I'm not going to work with this person if we hire them!" is not good. Either the interviewer's ideas for what you are trying to hire for is not in line with the hiring manager (which is common for junior/mid level engineers), or you are discounting their feedback. Both of those can be solved.

#13 - Strong opinions are good

If most people who interviewed the candidate has a lukewarm response ("Yeah, I guess so, didn't wow me but did decent"), that is a red flag. You want most interviewers to feel pretty strongly about hiring the candidate. Chances are if most people do not, if/when you hire the candidate, they're going to be mediocre or bad. Lukewarm feedback is also an indication that the interviewers aren't committing, and aren't thinking about the evaluation enough. If an interviewer always gives a lukewarm response, you probably need to work with that interviewer to ensure they are giving their real opinion.

#14 - Have a career progression ladder and salary bands with each position

Salary negotiations with the candidate are OK, but you should have defined job titles, and salary bands for each title should be defined. If the candidate wants more money than the position, you need to bump them up to the next position and evaluate whether they would be a fit for that position. This is to ensure that your current employees are treated well and are being paid appropriately. Trust me, developers talk to each other about salary. I've seen things go really bad when the developers who have been there for years find out what a relatively new employee is making because they demanded a high salary. You want your current employees to feel appreciated and paid well, if they don't they'll leave or be undermotivated. Having defined job titles, and salary bands around each are the only way to ensure fairness to current employees. This can also help to make sure things don't go spiraling out of control in negotiations.

#15 - Hiring process should be a funnel

After you've been interviewing a lot of people, take a look back at numbers for your hiring process. How many people make it on site from the phone interview? How many people do you give an offer to from on site interviews? Ideally this should be a funnel. So for example, a third of the resumes/applications that catch HR's interest should have a phone interview, a third of those pass the phone screen to on site, and a third of those you give offers to. The number there (one third) can change, but the point is, at each step you should be filtering out a good number of candidates. If you are not, you probably are not evaluating tough enough. And if only 10% of candidates are making it past each step, you're probably being too restrictive.

You need a big history to evaluate this well though. For a 6 month period you may have just gotten really lucky or unlucky. So you need high numbers at each step to make a fair evaluation.

Final Thoughts

I hope you appreciate me writing this up. I'd love to hear if there are things you disagree with, or things you really agree with! More feedback for me is better, I love hearing different perspectives.