Recruiting Technical Team Members Part 2

23 May 2017

Photo: Matthew Sleeper

This is the second in a mini-series of posts. In the previous one, I outlined some thoughts on recruiters from a hiring perspective. This one covers some observation’s from reading lots of candidate CV’s. (I do mean lot’s as well!)

Tip 1 - Quality

“Good developers can write well.” I have read that countless times and always wonder where that comes from. I am constantly surprised by the lack of spell checking and grammar in most of the CV’s I receive. There are a lot of tools out there that can help you prepare your prose. Hemingway app and Grammarly are two that I recommend for most.

I see a number of CV’s that have obviously been copied and pasted onto a recruiter’s template. These recruiter versions always look awful. They obviously do not take any time in ensuring formatting is copied as well. If you are using a recruiter then find out if that is something they will do. If they do, then ask to proofread the recruiter version. It is your career they could hamper with the terrible presentation.

Tip 2 - Quantity

A lot of the CV’s I receive are just too long. I mean, 5 pages long for someone with a 4-year career history. Let’s be honest and say that if I am hiring you I am interested in the most recent roles that you have had. If you worked in a burger restaurant when you were 18 and you are now on you eighth job, it should be referenced and no more.

Your Cv shouldn’t be more than 1 page of career history per 10 years of work with a page for education and personal information.

Tip 3 - No lists

When reading about your previous roles I want to know what you did and how you achieved it. That does not mean you should list every technology stack and acronym out there. It also means that if you tell me that you use Node, I do not need NPM listed as a skill as well. That is implied especially when you go on to describe the amazing products you built with Node. (Replace Node for any stack with peripheral elements such as package managers).

Tip 4 - Be adaptive

You do not need just on CV. You should try and adapt it to the roles that you are applying to. Look at the skills they want. Change the content of your CV to highlight your matching skills and experience.

Tip 5 - Be creative

A CV does not get you a job. Believe it or not your CV only gets you the opportunity to apply for a job. On a desk full of print outs what will make yours stand out? When reading CV after CV what will make me think back to yours over my dinner? Given that we are talking about developers I am shocked there are not some great quirky ways to present a CV.

Tip 6 - Order

The order of your CV is important. Technical experience needs to start on the first page. In fact, the text relating to your current role should not overflow from the first page. Education should go at the end.

Tip 7 - Personal statements & hobbies

Personal statements are pointless. I know that will induce meltdowns in some people but they are of no use to anyone and are just a waste of space on your CV. I read a CV once for a developer that sold him in a glowing light. Four months into his employment, he threw an air conditioning unit at a developer. All because that developer had accidentally unplugged his second monitor. Now I guarantee his CV doesn’t have a Personal Statement outlining the fact that he is bat shit crazy. Personal statements are pointless. If you must have one make it short so there is more room for your real skills and experience.

This also applies to what you do outside of work. If you do something of note that leads to an achievement then mention it in passing at the end. If you “like going for walks, watching films and playing the Xbox” then don’t include this in your CV. To be honest I will not select or reject you on what you do on your own time.

Tip 8 - Include portfolios

Last but not least share your git repo’s or your side project details. Nothing makes selecting candidates easier than being able to look at the code they have developed. The earlier in the process that is the better chance you will have. It doesn’t matter if your home projects are in Elixir but you are applying for a Java role.

Obviously, do not share repo details for an employer’s code base. I have seen this and not only is it not cool but I will let the employer know for legal reasons.

Conclusion

So there are some thoughts about CV’s. I look forward to an improvement in those that I receive in the future.