Hiring Developers - Any tips on being more efficient? [closed]

Question

I represent a software company that is in process of building a large software development team. We are picky in who we hire and have really good retention rate (most of the devs have been here for an average of 5-6 years).

We've been spending a lot of developers' and HR time and have a low applications to hire ratio. Here's the process we use:

• HR Interview on phone - Involves asking basic behaviorial and tech questions
• Online test - Involves a 30 minute technical test
• Technical Phone interview - A 60 minute interview by a developer
• Onsite Interview - A 60-90 minute interview by several senior developers

Although this process has been working, we've been spending way too much time on interviews. Any thoughts on how this can be done differently? Our goal is to automate any tasks if possible still retaining the quality of talent.

---

UPDATE: Thanks for the responses. Need to clarify a few things. Our aim is to reduce the number of applicants that go from one stage to the other. Here's our current numbers.

1. We receive 1000 resumes
2. 800 resumes pass the HR interview
3. 500 pass the online test
4. 100 pass the initial phone screen
5. 10 pass the onsite and get hired

As you can see, we need to do a better job of weeding out the candidates earlier on in the process. Can we do a better job in the way the online test evaluates people?

Here are more details on the process based on some responses:

• HR Interview on phone - They ask very basic technical questions (What is a CLR?) to weed out as many people as possible
• Online test - Have around 10 basic questions with 3 coding questions
• Tech phone screen - Covers a variety of technologies. We don't care if the applicant doesn't know everything as long as they can demonstrate they will be able to pick up new technologies and come up to speed quickly
• Onsite - Coding questions in front of the developers. More architectural level questions.

Answer 1

I think there are a few places you're wasting time.

Drop the HR interview beyond just a simple first contact to setup follow-up interviews. Having HR people ask technical questions is a waste of time. For example, I had one ask me some unclear question about MVC and they couldn't clarify what was being asked.

Drop the online test, especially if you're hiring mid to senior level developers. It wastes their time plus your time and money. Also, some developers simply don't do well on this kind of test.

While a phone interview is good, it shouldn't require a full hour. Often 5-10 minutes is enough to determine if a person is a good fit or not. 30 minutes should be the most you'll need to determine if a face-to-face is warranted.

The face-to-face interview will be the most important. Just don't waste it on BS like HR personality tests, standardized online tests and the like. Take the time to get to know the person and see if they'll fit into your team. Ask good questions related to the work you expect them to do, not trick questions, not mind puzzles you heard they ask at Google/Microsoft/Apple/etc or obscure trivia.

You might also go through a recruiting firm that does contract-to-hire. Many of them will have done the preliminary screening and testing and, in some cases, will have worked with the person before. That way you can hire the best candidate(s) and determine if they're a good fit while their doing actual work for you. If things don't work out for whatever reason, let them go. If they're a good fit, keep them around as permanent employees.

---

Edit based on updated info...

If your HR is only screening out 200 out of 1000 the problem could lie there.

Your help wanted ad may be too generic and encouraging a lot of people to apply who would otherwise screen themselves out. You may want to target your ad better but don't over-target it.

With that many resumes, HR may do better outsourcing this phase to a pre-screening agency to narrow things down a bit, through the use of automation and/or pre-screen interviews and background checks. This could include an actual initial tech interview given by a real programmer. It might also include an online test but this will be of the tricks and trivia variety.

Like I said, I don't think you're getting a lot of value out of the HR and online test screens. I'd suggest rethinking these and you'll find that your numbers in the other phases will be more reasonable.

Answer 2

This is one situation where you don't want to be more efficient than you already are. There are already too many applicant's who can't pass FizzBuzz. Your current filtering process looks like it ensures developer quality. You'd end up wasting even more time down the line if you eliminated any of the steps you're taking so far.

Answer 3

Sounds like a successful candidate takes about three to four hours. I would not try to reduce that overall time. If anything, I might add more time for the onsite interview to give plenty of time for the really great candidates to show their worth definitively, and decide if what you offer is interesting to them long term. With your low turnover, you must be doing something right.

The low ROI in your process could be the first three steps. Perhaps you can screen resumes more strictly or look for yet higher scores from the online test. The phone technical screen might be a target for optimization if you set it to be 30 minutes, but allowed superior candidates to extend to 45 or 60 minutes.

If it is any consolation, I think the distraction and time cost, while a drag on project work, is some of the most valuable time you can spend. Consider the costs and problems that come from hiring mistakes, and the great gains to the team and company when a good hire is made.

If you are taking point, working with almost all your candidates, you are something of a sacrificial lamb. However, the global effect of the work you are doing has great value. You should embrace the role and milk it for all the good will you can get among the new hires. If the process goes well, your management will value your judgment about other things as well.

Answer 4

As I read it your system is working, and you are more than happy with the outcomes. Your teams are working well, are productive and everyone is happy. The only issue is you believe it is costing too much.

Consider the alternative - you reduce the overhead of recruiting staff (though whatever method). As a result tenure drops from 6 years to 3. If you have spent 1/2 the time for each recruitment, then you have spent the same in total in recruitment alone. Now look at the cost of turnover - unlike manual labor (fence painting is a good example), it takes significant time to come up to speed, say 3- 6 months. So that means your recruitment savings have to recover 3 -6 months of wages, costs and lost profits for the business (call it 2.5* wages) Now factor the disruption to the team, and the risk a new recruit has to team dynamics.

All in all - a recruitment on average will cost you 3-6 months salary. How much are you spending to fill a position - a week or two is my guess.

Way to reduce it: All I can see is the interview times - are you terminating them or padding them out once you have decided the candidate is a No (or a Yes)? If you have decided to make him an offer after the first 5 minutes- make the offer. If you need 90 to decide not to make an offer, ask why it took 90 to get to No (i.e. what did he do to blow it in the last 60 seconds).

Recruitment is at best a crap shoot - it seems you have successfully loaded the dice in your favor, I would be tempted to keep it that way......

Answer 5

We generally ask them to bring and explain some code that they wrote and are particularly proud of, preferably from an open-source project.

"Wait," you say, "Doesn't this bias you toward people who write software in their spare time?"

Yes. Yes it does. That's kind of the point.

Answer 6

I would also suggest something that I read here: Effective Programming: More Than Writing Code:

It's nice to see if the candidate "fits" in the organization's culture and day to day life. This can be done by allowing the candidate to ask questions to current employees "off the record" or in some advanced level doing a contract job for a week or two (suggested by author).

In retrospective if some companies that I've worked for used this strategy, they would have never hired me, something that would be equally good for both parties.

Answer 7

Rather than asking is our process wrong you should first ask are we failing to attract the best people available out there. Most organizations fail to promote themselves and the job prior to receiving any applications. I reckon is it also a mistake to have HR involvement at the first point of contact. There is a fundamental schism between the personality types employed in HR and high-end developers.

After much thought over the years on this subject I would use a 100% contractor/temp hiring policy and offer fulltime career positions to select contractors after a year. Some people interview very well with encyclopedic technical knowledge but spend their time writing the code they know you need but not what asked of them.

I have one specific interview hint, provide some code and give the candidate 10 minutes to review, then ask them to criticize the code.

Answer 8

Have you thought of working with a recruiting agency to try and find people? You could sit down with an agency and tell them your process and what you're looking for in an applicant. They can then spend the time looking at the many resumes, doing the general technical test and administering the online test. Then, they pass the good applicants onto you for the phone and in person interview.

I have worked with a recruiting agency in the past as a developer looking for a job. I had to go through a long interview process to be in their pool, and then when potential jobs came up I had to do initial steps and if my code/answers were good, I got to meet the actual company.

I'm sure it cuts a lot of overhead out from your team, but there would be a cost. I have heard it can be a percentage of the employee's salary. So if you are offering 65k/year, you might offer them 60k and then pay the company 5k.

Answer 9

Like SomeKittens says, do the FizzBuzz test... only that do it live and preferably on paper, since what you want is to really see how much time they take doing the solution. Don't grade syntax, just the logic of the solution, in my case I even allow pseudocode and its not a problem, it works just as good.

It has worked like magic for me... I was able to weed out a so called 15-year-experienced-guy who talked big about him being so good that he would be willing to "step down" from his managerial position for a shot at a developer position in my company... oh boy, did he fail: 45 minutes (I even went for a soda and came back), did it in pseudocode, and he got it wrong. The guy had left a good impression with HR due to his resume, but given this result I was able to weed him out without a sweat.

The average is 15 minutes, less than that, doesn't mean you got a good programmer, more than that start worrying about having a bad programmer in front of you.

Read the article by Jeff Attwood "Why can't programmers program" to get a sense of the essence of the test.

Also, unfortunately I'm in Mexico and this is not popular enough to have where to choose from, but, maybe try careers.stackoverflow.com?, I mean, it is a specialized recruiting tool exactly for what you are looking for.

Answer 10

Answering from a developers perspective, relying on developer's technical skill so much does get quality developers but equally has chance to eliminate really good developers also.

I am involved in many programming backgrounds C#, Java, PHP etc. A lot of work experiences does ensure a person is expert in its field, but due to this a fact ignored is that other background are suppressed.

For example, majority of my experience involves around PHP and I know almost all tits and bits of the language, just because I can answer the question, it does not make me a quality programmer. And just because I dont remember the function name and definition in a XXXX library in Java does not make be a bad Java Coder.

I believe developers should be judged by potential and adaptability rather than what they can do.

Answer 11

My suggestion would be to change the HR interview to be more about asking the candidate about their ideal work environment. A key point here for HR is to just collect answers and add points about how the answer is given to determine if the candidate knows what kind of environment they want and how well does it match your organization.

There may be something to be said for HR knowing some points in the overall process used within your organization but this is likely where you could do some more weeding if you can set things up so that you have specific values, communication styles, and other points as things for HR to find. The point here isn't for HR to determine the fit alone but rather collect the information that can then be passed onto a developer or two that can see if someone is worth fast-tracking through the process.