I am a professional development manager but an amateur recruiter. I have been trying to recruit between 2 and 4 developers for the past 3 months and it is hard. I have learned quite a lot and tried to automate as much as possible but the domain is still under-served by well thought-out companies or products that provide some benefit but still leave many of the problems unsolved. Except by our time!

That is really the ultimate problem. I am paid because I am good at managing software development and with other software related tasks so it is not good use of money for me to spend hours and hours per week processing applications or otherwise finding candidates. It would be great to have an HR administrator to do a lot of this for me but firstly we are too small to need one and also they won't have the specialism that can spot a good senior dev from someone who has been writing software for 15 years and assumes that this means they are senior.

So what is recruitment? We are trying to find somebody who is a good fit for our company and who can add value in a certain area. The amount of value they will add is firstly about their seniority and therefore how much they will cost. A good senior should be able to produce more quality work than the equivalent number of juniors so we should never be employing "the best we can afford" if that person is not at the level we need them to be. For example, if we need a Marketing Manager then we need somebody who can do that job well, not someone who thinks they can do the job but they cost £10K less. There are always exceptions but unless we know somebody, we need someone who can, not someone who might.

£10K might sound like a lot but our sales are something like £2M/year so will £10K break the bank? A marketing or sales manager will increase income by way more than £10K per year so although it will take some time between hire and results, if you have not seen the results within a year, they are the wrong hire (or maybe you are in the wrong business!). Business is like whack-a-mole, as you see weaknesses, you address them. If you employ a marketing manager who doesn't deliver results because there aren't enough sales people to handle the leads, you either need to employ more sales people or you whacked the wrong mole and should have put something else in place first.

So back to my developers. The problem with saying that we need somebody who is a good fit is that it raises some reality. We don't always know what we mean by a good fit, we don't know how to decide whether the cnadidate is a good fit, the recruiter might know some things but likely lacks technical ability to discern good fit from fit and then the candidate themselves won't be the best qualified to say they are a good fit. They might promise the world but there is no cost to them to say they will perform well. If they don't, they can leave and we can get rid of them but then we are 3 months down the line and still a developer down, we might also be a lot of money out of pocket with recruiter fees.

So we need to know what a good fit is, how to judge the fit of a candidate and to make sure they can evaluate themselves. All of this with the least amount of effort for the company who are often processing 10s or 100s of applications, the candidate might only be applying to a handful and a recruiter might be doing it for them so, again, no cost to the candidate can make them lazy.

Your recruitment needs to be a funnel. Early stages need to be quick, easy and ideally automated so that anyone who is way off the mark can be dismissed early-on before they take our time. As the candidate progresses, we need to decide what other boxes they need to tick and measure them as objectively and consistently as possible. The slowest or most labour-intensive tasks , like interviews, should be left until the end. The funnel is narrower here, which means less interviews, and also the people who have lasted this long are worth the more in-depath conversation.

So what does our Developer recruitment funnel look like at SmartSurvey?

Auto Response

All applicants should get an automatic response. Ideally, avoid an email address because once the recruiters get it or guess it, you will be inundated, an online form is better. The automatic response tells them their application has been received and under what conditions they can expect a response and when. For example, you might respond to everyone initially to say, "sorry you don't have the right skills" but eventually you will get so many waste of time applications that it might be easier to say, "If you don't hear from us within 2 weeks, your application has not been successful at this time".

Initial Survey

We ask some very broad questions in the first place via an online survey. We ask things like "Do you meet all of the requirements of the job spec " and "Are you legally allowed to live and work in the UK". These examples might not quite work for you but it is a quick and easy way of not wasting time. You might want to confirm their level of experience, that they have done this specific role before etc. (before you have to read a CV). You should also ask about salary expectation and notice. If 3 months is too long for you to wait, don't find this out after the interview - then everyone's time is wasted. If someone is interested in the role, they shouldn't care about spending 2 minutes answering some simple questions. Create a survey at SmartSurvey if you want!


A really important question I ask in the developers survey is for the applicant to measure their skill in certain subjects, say SQL Server and Cloud Systems. This does two things. Firstly, it provides another filter. If someone wants £45K, then that is OK, but if they score themselves 1 or 2 on each skill, they are unlikely to be worth £45K! Secondly, it directs the technical screening tests and ultimately interview questions that I will ask to qualify it. If someone doesn't claim to know much about HTML, I don't have a reason to doubt it and there is no point asking them questions about it. If on the other hand they think they are a 5/5 on SQL Server, you can bet they will get some SQL questions.

Technical Test

So by now, I have done the rough sort and it hasn't taken too much effort. Anyone who remains on the list thinks they meet all the requirements and has scored themselves on each skill so now I send them an online technical test. Again, relatively easy for me to initiate but another drop-off point from the funnel. I tailor these to the skillsets the candidate identifies and we run them from CoderByte which is good value for money and has a lot of pre-defined tests (in some areas more than others). Some people don't bother doing the test - great. That means they already have another role or they are simply not that interested. Others don't do very well. The tests are not mind-numbingly hard but I will read into a candidate who takes a long time to carry out a very simple task - especially if they think they are senior! There is no fixed pass mark but I would expect them to finish all the tests in the hour if they are senior and since the record is about 30 minutes, that isn't a big ask.

If the role is less technical and more subjective, like design, you can perform either a long-answer test or ask for a sample of work or even to carry out a specific task but remember we should not expect too much of their time unless we are to pay them.

Not everyone agrees with technical tests but certainly for my seniors, I want somebody who can think clearly with the clock ticking and someone who can perform simple tasks from memory. So many people say that they "can learn whatever else I don't know" but the truth is an experienced person can do something 10 times quicker than someone who doesn't so the fact that "we have Google" doesn't excuse people with no head knowledge.

CV Check

I don't bother checking CVs usually until this point because this can easily take 5 or 10 minutes per CV, not something you want to do with 50 CVs per week until later in the funnel. At this stage, they have demonstrated some technical ability but the CV is a good source or certain data. Although I occasionally ask the candidate to tidy their CV and make it clear, sometimes I won't bother if it is that poor, I won't assume they just haven't updated it, I will assume either they didn't bother checking it (poor attention to detail) or it is actually as poor as it looks.

So what can we tell from a CV that might not be obvious from elsewhere?
  1. Length of role. What if the candidate has only ever worked somewhere for 1 year at a time? Might be OK for sales but not so much for development. In my case, I want people to have seen the lifecycle of an application, which usually takes much longer. They might also have commitment issues - how much investment will you lose if they only stay 1 year?
  2. Inconsistent types of role. Are they unable to decide what they want to do or have they not done well enough to chose what they want, instead accepting whatever they can get? There might be personal reasons and you might be able to ask them but otherwise it makes me uncomfortable.
  3. When they got their skills. Someone claims 20 years in development but worked in a shop for the past 5 years is not the same as someone whose 20 years is up until now! Likewise for certain technologies, using SQL Server 10 years ago is not recent enough to claim it as a skill.
  4. Communication skills. Does the CV look tatty and lacking care and attention? They might be more technical people but are there typos? Small fonts? Poor typesetting?
  5. Does the CV spell out what they did? So often I reject a CV because it says something like, "the company produces an application that..." rather than "I was the main developer for the database design and produced a bespoke application that..." The CV should sell the person.
Apart from filtering, this is now the final information that I will use to dictate what we need to talk about at the interview. Some of these might be simple "If you can clarify..." e.g. why is there a 2 month gap in your CV, others might require more conversation, "Can you explain how you have management experience when none of your roles mentions this".


The idea is that you have automated out most of what you wanted to know which should help focus the interview. You already know they meet a technical level (but you might want to discuss their solutions), and that their CV is either OK or there are some points you need to clarify.

Although you can get clarification on the CV earlier, if it might be deal-breaking, otherwise, they make good opening questions for the interview. This is probably the first time you have met and they might be nervous so we try and show our friendliness and make sure we smile, remember during the interview not to make any negative responses that might be read as failures and also remind them that any further technical questions are not about passing and failing as much as the suitability for the role in question.

They should have a good understanding of the company by now and if they care, they will have visited the web site and found out as much as possible. If they haven't, I sometimes give a very subtle hint like, "that's interesting, any reason you haven't?" just to remind them that they need to come across well in the interview.

If possible, it is good to have a score card. You will already have scored them on certain things (pass fail or out of 5) but keeping this on record is good if anyone was ever to make an accusation about prejudice or discrimination on the process but another good thing about automating things is that you won't generally know about race/disability and possibly not gender until the interview so that helps show that it is a neutral process.

We are judging soft skills in the interview like confidence, being engaging, having passion, being able to communicate clearly. Some people have 1 word answers, some talk for ages without answering the question but although we try to help them, we are also imagining what it would be like working with them. There is no right or wrong, it might be better that they have fewer words or better that they are chatty and outgoing.

There shouldn't be too many outstanding issues by the interview because unless you are a company that everyone is desperate to work for, you can only make so many demands on the candidates time. You might have some follow-up technical questions or need to ask questions which are not answered easily on "paper" like "give me an example of where you had to deal with team conflict".

The Technical Test

Most of the time, the interview is enough to give an idea whether an offer should be made and for how much. Normally, I would not offer somebody below their asking salary, I would simply say they are not worth that money in my opinion, if someone would accept £50K, why are they asking for £60K?

In some cases though, the interview still leaves us feeling a bit undecided. Maybe some good things, maybe some bad, maybe the experience is not strong in any one area and Generalists are not usually good for a small company, you want some unique skills to make the team stronger. In this case, we set a paid technical test of about a weeks work, based on a real type of task, to see whether what they produce is very close to perfect or has lots of issues with it. This would only be for seniors who would be expected to produce good qork quickly. We would then say that an offer is dependent on the task being completed to a usable standard but they will be paid if they put the work in. There is some legal work and money required for this but if someone is able to produce well at the end of the day, that is what you want them for.