Book Notes : How to Recruit and Hire Great Software Engineers

How to Recruit and Hire Great Software Engineers: Building a Crack Development Team
How to Recruit and Hire Great Software Engineers: Building a Crack Development Team by Patrick McCuller
My rating: 4 of 5 stars

You should be hiring people with the right attitude and the capability to learn, master and teach since although you know what you are doing now you don’t know what you’ll be doing 1,3,5 or 10 years from now.

Hire top performers, hiring anything less than the best will hurt your bussiness. Talent bring talent, incompetence repels talent. A mediocre or low performer will not aid the team and will actually diminish its performance though having to deal with messed up projects or missed deadlines. It is generally easy to identify low performers and exceptionally high performers, the challenge comes with the mediocre ones – once hired these people are very difficult to remove because they are not doing anything wrong they are just not capable of performing at the high levels which you need. Top performers perform between 10 to 16 times more than an average one.

Understand your current pool of talent, ask them to periodically update their CVs to map out the teams current knowledge and experience. Knowing who is in the team will identify holes in the team if they need filling and will help you focus your recruitment if you need to replace someone. Critically the profile needs to look at leadership, experience (tenure, technologies etc), style (cautious, quick, adventurous, perfectionist) and roles (build engineer, tool engineer, user interface developer etc). Engineers have two preferences, either creators or optimisers. As a project changes from the start-up/creation phase into the optimisation phase this might mean that the people in the team needs to change to ensure that the engineers are still being suitably challenged.

Hire ahead where possible – the pressure of hiring someone urgently to fill a role will always lower quality through subconscious if not though concious bias.

First hires on a team are critical – you need engineers who are leaders and great communicators, who inspire the team both technically and on a personal level developing and coaching them.

Its a race – how quickly can you hire? because if someone else can hire quicker the candidate might be off the market before you have got very far through your process. Look at the process, the barriers and try to reduce the process to as short a time as possible – could you go from candidate to decision in one day? Can you speed things up, remove steps or reject candidates earlier? There are ways to make things quicker without lowering the quality of the candidates.

Candidates as customers. Candidates will be more likely to work for a company with a simple and enjoyable hiring process. If your candidates experience is exceptional, they will notice, talk and refer others to you. You will turn down a lot of candidates so if they are treated well rejected candidates can still spread the word about your company. So ask the candidates how they found the process, see what they say and improve things. By being as open with the candidate as possible they will know what to expect and so can perform at their best – provide a guide for the candidate to know what the steps of the process are. During the interview the words chosen should be straightforward – uncommon or complicated words should be avoided, not just for people for who the interviewing language is not their first language but for all candidates. There are some people who should just not be allowed to interview – for whatever reason they are not the suitable, these people should not be forced to interview as these people will leave a bad experience with the candidates.

Passive candidates need wooing – this might be extra steps such as a getting to know you phone call, speaking with developers, pre screening etc. Reduce the barriers to entry – such as not requiring a fully up to date CV however all candidates should be treated fairly. Don’t make exceptions for one if you are not prepared to make exceptions to all.

Active candidates contain a large number of people who can’t hold down a job, don’t have sufficient skills (e.g. new graduates). These sort of candidates gain a lot of experience at being interviewed.

Job descriptions are not inspiring – why would anyone work for a company based on a job description. If your target is passive candidates especially then they will either ignore or not care for the job description, so how can you attract such people but still provide them with the details of what they will be doing? A passion statement, this shows the passion for the company – Why are they doing what they are doing? Why should people work for you? and don’t present it in a dull form.

Great software engineers know other great software engineers, tapping into their network is immensely powerful but engineers themselves are usually not very good at seeing or networking. Additionally it is likely that their immediate group of contact are not looking for a job but encouraging them to speak about your company both to their immediate network and their wider network (friends of friends) is a great way to spread the word about your company.

Recruiters want to make money, if you reject all of their candidates they will not send you any more. The best way to improve this is better explain the candidate you are looking for to them, to explain the company, to help them better understand what you are looking for. The more information they have the more suitable candidates they will send to you and thus the better the candidates the more you will hire and the more money they will make. So spending time with recruiters is a great way to improve the quality of the source of candidates. Just remember that because the recruiter is incentivised to hire people they are likely to do whatever they can to help the candidate get the job (such as leaking interview questions etc).

Contract hires, instead of a long laborious interview process hire more freely on a short term contact then if they are performing well look to give them a permanent contract. To the author this has always turned out to be counter productive and a distraction rather than a benefit.

Unfortunately it is part of the concious for people to want to hire people “just like them”, this introduces bias be it sexism, ageism, universityism etc these are a challenge so when people say why they should not hire someone try to get to the root of it. For new starters working in another country it is likely that this bias is even greater. Don’t bother searching the internet for details about a candidate – it is as likely that you will find out irreverent information as relevant information, as such the risk of bias is greatly increased. Consider if the interviewer actually needs to have seen the CV or not – if the interview is competency based then there is no need for a CV then they should not see it since this will introduce additional unneeded bias. The HR team should redact any information which is not important to the hiring process and could introduce bias – such as gender, age, marital status etc.

Identify the source of the candidate, where you get a good source spend more time getting candidates through that source. Different recruitment companies and even recruiters have different approaches so try to focus on the ones which work best for you.

Lower the barrier to entry. Do you really need 6 years of Java experience? CV screening is quick simple and cheap – but this drastically reduces your pool of candidates for no good reason. Someone doing the same project for 6 years gaining Java experience is very different to someone working for 2 years on a variety of projects. Interviewing is expensive but it is better to look at your interview process, such as telephone interviews, rather than being harsh on CV content. When going through CVs look for positive points, negative point and neutral points. If the positive outweigh the negative then the candidate is worth interviewing. Positive items are things such as length of experience, relevant experience, variety of experience, education, computer science experience (such as university but specifically computer science rather than just Java courses), patents and publications (though reading these is not recommended), responsibility. Negative items are “wall of words” but not saying what the individual did, lengthy CV and quickly changing companies. Things to discard when reviewing a CV, things such as breaks in service, irrelevant information, small spelling or grammatical errors – especially when dealing with people who’s first language is not English.

Telephone screening provides its own challenges because of the unnatural narrow band of communication. A simple problem can become difficult and a tricky problem can become impossible over the phone. Asking open questions such as about recent projects can just use up valuable interview time because the power is passed to the candidate. Posing coding questions should be short, typically 30 seconds and can be conveyed without confusion and the answer to which are just a few lines long. An alternative is to use a shared screen so that there is no room for confusion.

To maximise the use of interviews ensure that there is some coordination over who is going to ask which questions to prevent repetition. Four or five experienced interviewers are the optimal number. When handing over the candidate don’t discuss the candidate to prevent bias. Gain feedback from interviewers independently before discussing the candidate.

If the candidate says that they are suffering from outside stress offer to reschedule the interview for a time when they are better able to focus on the interview process. During interviews candidates will be at their best. As an example if the candidates English is a challenge it is likely to be worse once they are hired, however a thick accent should be forgiven since after a day or two of working with the individual you will quickly get used to the way they speak. If the candidate makes inappropriate jokes or comments these are likely to be more prevalent once they start. If the candidate has strange mannerisms (such as restless legs etc) these can be medical conditions or stress induced and should be ignored. If there is silence then let it happen, this could be the way the candidate thinks and so you should be happy to let a little time pass for the candidate to focus. A large number of candidates lie, if you suspect a lie push it a bit to find out more – it is likely the candidate will admit to a misunderstanding however if the candidate gets caught up in their own lie the author has highlighted the issue and contradictions and then ends the interview process. Candidates expect certain questions, if you ask questions which are similar to these but are not the same then the candidate might inadvertently answer the wrong question in which case you should highlight the difference to clear the confusion up for the candidate. Where possible get them to do the job you will expect them to do and see how they get on, for jobs where you can’t do this ask them questions about their past jobs but remember it is likely the responses will be on the positive side. The book goes into many more details about interview questions than I am going to cover here.

Interviewers are only able to asses people of a similar level – it is very hard for a junior developer to asses the difference between a senior and a principle developer. This can be a real issue where you are looking to recruit a competency into a team that you don’t currently have as people will be recruiting outside of their field of expertise. Training interviewers through shadowing, classes and workshops, documentation and guides, coaching, practice interviews and then once they are actually interviewing candidates to continue to provide feedback so they are always improving. It is especially important to get interviewers to understand between domain knowledge and capabilities, if the candidate does not have the knowledge but has the capabilities then they will quickly pick up the knowledge.

Hire the best engineers you can afford and keep going till you run out of money/budget. During hiring there is always a margin of error. Hiring a poor performer is quickly correctable, you can just let them go. It is difficult to fire someone for doing just and “all-right” job. Hire the candidate is all of the things you want and nearly none of the things you don’t. “Nice” people are not enough, they need to have capability the nice people who are pleasant to everyone but when they start have no capability to do the work are the hardest to let go. You should never hire people who: slam former employers, severely irritates anyone, lies or deceives, ignores goals. Never hire below your standard, the hire will have impact for their entire tenure at the company which could exceed your own.

Feedback can give the option for a candidate to argue about an already made decision and potentially could give the option for a legal challenge. As such, if the HR team do not already have guidelines of what you say, the author recommends giving more generic feedback such as “You were not a great match today. Gain some more experience, hone your skills-coding, design and so on and consider applying again in a year or two”.

Keep and analyse records – not just of the candidates but of the recruiters. Review the data regularly. If you hire someone then let them go, was there any data which could have given you the information earlier? If a candidate performs really well were there things which you could pick up on to help identify this earlier? etc.

The amount you pay developers falls between the bounds of local market rate at the lower end up to creating golden handcuffs at the top. If you want great developers you need to pay them appropriately but over paying people will mean people who should not take the job take it only for the money and get tied in so they can not leave. Decide what your offer is and make it, this should be the maximum which you feel would be appropriate and explain this to the candidate so they know their is no room for negotiation. Make sure that you hire at the appropriate level, someone being interviewed for a developer role who is at a principle level will sail through the interview but they are not right for that role. Let the candidate speak to others on your team, even after the interview process, by being open and honest with them they are more likely to feel that they have made the right choice. If the candidate does not respond within a week don’t assume that they are not interested, instead get the highest person in the company you can to call to speak to the candidate as a sell call – this will set your company apart for a candidate who might get a couple of offers and your CEO has phones to speak to them.

The recruitment process is not over until the candidate is settled into their new job. Once they accept send a welcome email to them, giving them details about the work they will be doing – a large number of candidates will be passionate to know about some of the technologies they will be using before they actually start and will do some investigation at home. For people who relocate they will need even more help with things which you take for granted, e.g. where to rent a place or where shops are etc speak to them before they begin to see what help you can give them. Think about the first day – make sure they have a desk, their network account is set up, arrange for people to go out for lunch – everything you can do to make the new starter fell welcomed and part of the team. Try to arrange things for their first week to get them to start settling in this should cover the team, bussiness and technologies. Perhaps give them a peer mentor that they can chat to, someone who is an aspiring leader will usually enjoy taking on this role. Everyone is different and so will need to be treated a little differently to help them fit in.

Top talent want top talent requiring jobs, if you hire top talent make sure that the work they are doing is suitable. The things which turn off top talent are incompetent developer and low quality work.

View all my reviews

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.