Developer hiring by the numbers

It's no secret that hiring software developers is hard. Plenty of people more qualified than I have written on the subject over the years on just how hard. In Dublin, Ireland especially, the supply and demand economics of the problem are particularly difficult. Dublin is a major IT Hub in Europe, and host to the EMEA Headquarters for some of the largest IT companies (Google, Microsoft, Facebook) in the world. We've got insurance companies, banks and other financial institutions all HQ'd here as well. The demand for good IT staff is significant. And the supply side of the equation is further complicated by the presence of recruitment agencies. When a potential candidate is ready to move job, they are faced with a choice. Do all their own job search leg work? Or send their CV out to a small handful of recruitment agencies and let the interview invites roll in?

So where does that leave a relatively small IT company? Well in a far from ideal position, where hiring is a significant undertaking both in terms of time and money. Below is some background information on how I've conducted interview processes in my last few roles, and some some anecdotal numbers on how that process has been working out recently.

The Process

Our hiring process isn't unique. We try to establish as quickly as possible whether a candidate is suitable for a role without wasting any of their time or ours.

1. CV Filtering - Are they an appropriate match on paper for the role
2. Phone/Skype Interview - Keep this brief, 30 minutes, enough to briefly discuss experience, existing role, reasons for moving on, technical experience and some relevant technical questions based on the role their applying for
3. Code Test - We send candidates a test to complete in their own time. Proposed as a typical user story with requirements, acceptance criteria and DoD. This is a chance for the candidate to show off. Try to deliver a code test that can be given from everyone from graduate to senior developers. While a grad might solve the problem, we expect more from a candidate based on their seniority. Solution architecture, separation of concerns, use of design patterns, decoupled design, use of dependency injection/IOC, code quality, unit testing, integration testing, database migration strategy etc
4. Face-to-Face Interview - The candidate meets with our team, usually a mixture of management and technical staff for a more involved conversation around experience, previous roles and technical questions

Our Rules

About 10 years ago, I was in my first team lead/people management role where hiring technical staff was part of my remit. I read "Smart & Gets Things Done" by Joel Spolsky. It's a brilliant concise little booklet on how to hire developers and all this time later there's a few things that still stand out for me.

1. We don't hire maybes - We're a small company. We have a diverse portfolio of software projects for a number of clients across a range of industry verticals. The large majority of our business is bespoke solution development and as a result, the train up time on our projects tends not to be spent on the technology but on the domain knowledge & business problems. We simply cannot afford to hire the wrong people.
2. We need all rounders - I dislike the term full-stack developers. Like it's some novelty. At the risk of sounding like the dishevelled old man shouting "back in my day...", developers used to be full-stack by default, at the very least, they had some hands on experience across all the layers of a solution. This is no longer the case with a lot of candidates we see; developers and engineers who have been siloed into roles where they only worked on one small sub-system, or one specific layer of the solution. This is compounded further when looking for seniors; we add skills like business analysis, hands on experience doing DevOps, CI & production releases, and experience in customer facing roles and it really can feel like we're looking for Unicorns.
3. We don't compromise on #1 and #2 when other pressures are present - It's all well and good having rules and principles in our process. So long as they don't get thrown out the window when they don't suit. Circumstances will dictate from time to time that we need to ramp up in resourcing to facilitate a project. This can be tough if the client wants to start tomorrow, and we have a potential 6-8 week lead time to hire.

The Numbers

The following is from a 6 week period during our most recent hiring period. We received a total of 84 applications. 73 from publicly posted job listings and 11 from a recruitment agency. A higher percentage of candidates from the agency got to phone screen.

• Of those 84 we held phone screens with 35 candidates.
• Of those 35 candidates, we sent out code tests to 25 of them.
• Of the 21 code tests we received back, we went back and offered 9 candidates a follow up interview.
• Of the 7 that accepted and attended the interview, we offered a full time position to 1 person.

That's a signal to noise ratio of slightly over 1%.

Some other observations

Offering a week to complete the code test is a double edged sword. In that time, candidates will continue looking for a role. A number of candidates we provided code tests to just disappeared into the ether after being supplied the test. Similarly, candidates that we've offered a face-to-face interview (or even job offer) are often off-the-market before we get to that point.

A large percentage of our applicants are non-EU residents. We're very happy to supply assistance to them in moving country, applying for VISA's, obtaining work permits, but that does add a significant lead time on (an additional 4-8 weeks typically) on the standard 1-month noticed period we'd expect to be waiting.

Lets assume a resume takes 10 mins to review on average (check content, reply reject/proceed, possibly setup phone screen). A phone screen takes 60 minutes including prep and post-call time (sending out code tests). Code test review and notes by several team members adds another 60 minutes. And a face to face interview including 3-4 team members is at a minimum a 4 hr commitment. By those ballparks we've invested ~100 hours (13 business days) into this one phase of hiring. That's a pretty serious time commitment and nearly doubles the cost associated with hiring when compared against the amount we have to pay out to a recruiter.

The bottom line...

...is that the IT hiring market is particularly challenging for SMEs. Finding talented developers, bringing them through the interview process and getting them in situ, is a significant undertaking. And when you get them, you better do everything you bloody well can to keep them.

After following this path for the past 3 years, we've now hit an impasse. The time and resource cost, lead time for starting and general difficulties with the hiring process for quality full time developers, is now a quantifiable impediment to our business. Without the ability to ramp up on demand, we're faced with either turning down growth-business, or increasing the workload on our existing team. Neither option is particularly palatable. We need to pivot our . Contractor rotation? Near-shoring/Out-sourcing? A change in tack is definitely required.

~Eoin Campbell