Hiring Software Developers is hard
Hear from Nick Brook, Head of Engineering at KisanHub who describes trials but also useful tips, when recruiting Software Developers and Engineers.
TL;DR*: Hiring is hard. Hiring good software developers is even harder. In fact it’s probably the hardest thing you’ll have to do in a startup. You might have a brilliant product idea, but without the right group of people to actually build it, you’re dead in the water. So here are some tips that might help.
Where are all the geeks?
There just aren’t enough of them, particularly in the UK. This has been the case my entire working life, and I’m still utterly bemused as to the reason. I mean - what other professions can be learnt entirely on the internet, for free, pay really well from the start, are genuinely fun and intellectually challenging? Seriously kids - learn to code.
So how do I find the good ones?
Well, it’s tricky. The problem with software is that the most useful skills don’t really come across on a CV. Most recruiters (and candidates) seem to think that having a specific set of well defined skills are the most useful aspect of a developer. I can see why - they’re easy to list and match off against a list of required skills, and hey, skills are hard to learn right?
Well, no, not really. Good developers pick up new stuff really easily. This is because they have the most important meta-skills of “enthusiasm” (i.e they really like writing code) and “quick learner” (i.e they pick up new stuff easily). Having lots of different skills and platforms on your CV is simply a proxy for this. Having existing knowledge of your particular tech stack or language is certainly an advantage, but really not a massive one.
These metaskills are particularly relevant in software because the technology just changes so damn quickly. The framework / language / methodology you used to great effect four years ago is probably now completely obsolete, which is a pretty brutal Darwinian filter for developers that can’t keep up.
(Incidentally: the easiest way to stay ahead of this rollercoaster is to only work in startups)
Education is overrated
The one thing I don’t really care about is the education section. I never read it. While there may be a correlation between education and software prowess, it’s mainly because clever people often go to University, and developers are clever people. Clever people can become great developers and just skip the university step completely - it’s not required in this equation.
Or rather they could if every single job advert didn’t insist on some kind of degree. This is just madness: by insisting on a degree (or worse: a degree from a particular set of universities), all you’re doing is loading up an entire generation with a massive amount of debt for no obvious reason.
A vanishingly small percentage of graduates actually use their degree - most of them only went to university because they knew that they had no chance of getting a decent job without a degree. In the UK all generations up to and including mine were incredibly lucky: the state paid all our fees and living expenses. Every generation after that has been progressively screwed. So please, employers, stop being the problem.
So how on earth do I filter?
Well, there’s still useful stuff on a CV around the candidate’s recent projects and roles undertaken. A variety of projects using a collection of technologies is certainly good evidence of those useful metaskills, but the only real proof that a coder can code is pretty obvious: get them to code. If you’re really lucky the candidate has worked on some good open source projects or has an active Github account, but you will usually need to set them a coding assignment to really gauge their abilities.
What should my coding test look like?
Well, it’s probably easier to start off with what it shouldn’t look like.
It shouldn’t take up an entire week of evenings just to complete. If your candidate is any good they’ll already have a job, and they’ll certainly already have a life. Asking them to commit a large percentage of both on the off chance of getting a new job is just plain rude.
It shouldn’t be about clever algorithms. A miniscule fraction of developers will ever work on clever algorithms. If we need them at all (and we usually don’t), we’re just plumbing them in as a black box (and yes, this is true for almost all “AI” or “deep learning” stuff out there).
And here’s what you should aim for:
A good developer should be able to finish it in an evening, but give them longer: I generally allow a week to submit.
It should be in the same domain as the eventual role. For example, if you’re hiring for a front end specialist to work on your graph-heavy dashboard webapp, get them to write a simple app to show a graph.
If your target platform requires a large amount of setup boilerplate to get to the starting line, provide that for them.
It should actually run! It’s amazing how many assignments I’ve had back that just didn’t work. This isn’t necessarily an instant fail: it’s very easy to simply forget to commit a file, particularly if the file was autogenerated, but it can be evidence of sloppy thinking and will reflect badly.
What you’re trying to do here is get a sneak peak of how the candidate would behave actually in the role. It’s a good way to weed out candidates that haven’t been entirely honest in their CVs: a really poor assignment is enough to stop the whole process dead.
Usually it’s the ones in the middle that are tricky: assignments with one or two glaring problems that aren’t bad enough to reject outright. Often here I’ll tell the candidate about the problem and ask if they can fix it before we can proceed. If they can, that’s an excellent sign: they learn from their mistakes.
When setting the assignment, don’t immediately discount a candidate that had to learn the language or framework for the job. After all: a candidate that can make a good stab at learning something completely new for an interview is showing the two golden metaskills in spades, and have often turned out to be my best developers. A good assignment will give you an excellent way to structure a full technical interview and hopefully result in a great addition to your team.
*TL;DR stand for 'Too Long; Didn't Read' provides a summary what this article is about. It is commonly used on online articles and blogs.
About the Author
Nick has been writing software for nearly 40 years, and oddly enough is still enjoying it. He's worked on an alarmingly diverse array of languages and platforms, but is currently playing with Python, Angular and DevOps automation with Kubernetes.