Do not index
Do not index

How to Screen Developers

Nothing makes a developer run away faster than the prospect of 4 rounds of interviews and a 10-hour test task. Who in their right mind would want to put themselves through that? It's a miracle that any developers even consider participating in the process. I mean, who would be up for such an ordeal when they could just be hired by a company with a streamlined, no-nonsense screening process?
A screening process, without the rigmarole, could look like this
  • Initial brief video call to find out about the candidate and what they are looking for
  • Meet the team/CTO interview; deep dive in their technical skills; and to ‘sell’ the team, the tech, the product, the vision etc
  • Make your offer or provide detailed feedback why it didn’t work out
Can it really be that simple? No need for pesky coding tests, reviewing portfolios or GitHub profiles? What sorcery is this?

Personal projects and GitHub: a note of caution

Using open-source contributions and GitHub profiles in particular are becoming the latest and greatest way to screen developers. The argument goes that interviewing developers is really hard, and anything to make it easier must be great, and get this there’s this one giant library full of code we can scour through to figure out if they’re any good or not.
That's the logic, anyways.
If you judge a developer's worth by their publicly available code, you're missing out on so many awesome candidates: it doesn't take into account those with NDAs - most people aren’t going to be able to show you code they wrote at another company; it ignores those who don’t use it as an extension of their CV - who use it as a sandbox for experiments, for backups, and those who don't have the time (or the desire) to make their account look pretty. It also ignores those who don't contribute to open source projects - there is no evidence to suggest there is any correlation between programming ability and open source contributions, unless you count ‘the existence of free time to do them’ as ability.
If you want to find out whether someone is worth hiring as a software engineer, their code is of very limited value compared to talking to them, discussing design and architecture, the constraints they've had to work around, the wrong paths they've taken (and what they've learnt from them) and what they’re like at recognising and solving problems.
Don’t assume that a lack of public code demonstrates a lack of interest, or care, or competence. People have plenty of valid reasons not to spend their spare time on their job. Don't think you've figured them out just because they're not sharing their code with the world! Treat personal projects and tech community involvement as “information about the candidate A”, and not “this makes candidate A a better prospect than candidate B”.

Coding Tests

So code testing may have some value in screening junior developers with little or no experience, but for mid and senior developers, who have years of experience, and numerous products under their belt, it's basically the equivalent of a slap in the face. Coding tests can leave decent developers feeling disrespected and insulted and kind of salty - Instead of having a meaningful discussion about software design, process, and quality control, they get asked to prove they're 'good enough' to code.
Coding tests are the bane of any self-respecting developer's existence.
A coding test may be a way to filter out the bottom candidates, but it's also a great way to give the best ones the middle finger.
It’s a surefire reflection of a culture that's so afraid of making a mistake, they don't even want to try to figure out who the real A players are.

Technical Interview

The only way to truly figure out if a developer is actually any good is to have them talk with their peers about programming. Yes, that means involving the developers on your team in the process!
Just half an hour of technical chat about the projects they’ve worked on, what mistakes they’ve made, or what they’d change,, the design process, how it solved the pain, requirements, expectation management, why tech decisions were made - and you'll get a real sense of their skill. If they can't converse with their peers about the topic, chances are they can't code it either.
Team interviews that make a candidate discuss technical topics with people who can call bullshit on them is the best way to find the best developers for the team.
The way we hire people now needs participation from the interviewer, not just observation. If it’s a struggle for you, it’s time to take a step back and let others participate, and make the call when it comes to the hiring decision. Get as many people on your team involved in the technical interviewing as you can - it's time to put your team to the test!
 
Annie Garland

Written by

Annie Garland

Co-Founder & Finance Director here at Lunem