In the secondย of a four-part series, Mike Ritchieย looks at how screening can work well for both you and your candidates.
See also
- How to hire a developer: Part 1: Hiring for the future.
- How to hire a software developer: Part 3 โ Online tech tests and alternatives
- How to hire a developer: Part 4 โ Why in-person technical interviews still matter
We’d love to see all candidates face to face, to have a complete view of their background, character and ability before making a hiring decision. In practice, it’s almost impossible for organisations to commit this sort of time.
More importantly, we don’t want to take up the candidate’s time if we think it’s unlikely we’re going to hire them. They’re busy people too. They’re generally in employment, and if they’re in Job Hunt Mode then they’ll often have multiple job applications live at any given time.
Done right, screening gives you and the candidate a way of building confidence in each other. As your investment in each other grows, so does your confidence.
I want to emphasise that this needs to be a matched investment. At every stage, the candidate needs to feel they know more about you, in the same way you know more about them. If this investment becomes unbalanced, then trust is eroded, and however appealing your job advert was, you’re back to sending a signal that this is really just about your company and its requirements.
Also remember that screening is supposed to be quick, focused, and relatively lowโinvestment for both sides. I talk to experienced developers who find the process that companies put in place timeโconsuming and and burdensome. In some cases they’ll make a choice to go with companies who have a simpler and faster selection process.
This is not because they’re lazy people, but because they’re busy people. Inโdemand developers will simply not have the time for your sixโstage interview process spread over three months. You need to keep it efficient – hire people with confidence, but don’t test their patience and make them look elsewhere.
You can keep loading on more tests and assessments, but you’ll just have fewer people engaged. You won’t get to the finish line with the best candidates, you’ll get there with the ones that are left.
You have a finite amount of time with a candidate. Make it count.
Tโshapes and technical specifics
A theme that’s going to be running through this and the next article is that we should look for breadth. This “Tโshaped” model of personal and professional development is often used to illustrate the point. The thinking behind this is that you have a set of core skills forming the stem of the T.
The idea is that you continue to develop those deep, core skills, but you also develop broad skills and knowledge of other disciplines – the cross of the T.
Now, it’s just a model, and a way of thinking about professional development, but it does ring true for me. Before I even knew this existed, whenever I was asked what the difference was between a beginner developer and a proficient, experienced developer, someone who worked really effectively in a team, I’d always reply “breadth and depth”, and I’ll be returning to that phrase in a minute.
You want T-shaped people. Even if they don’t always exercise that breadth, the knowledge they have of other disciplines means they can empathise and communicate well with a wide range of people.
That said, I understand how specific your requirements might be, and how complex a technical domain some of you might be working in. It’s possible that you’re hiring specific tech skills that can’t easily be picked up, or you’re looking for a depth of experience to help mentor newer developers.
For most of the next two posts, I’m going to have to make some assumptions. With the infinite variety of technical backgrounds that might be important to you, I don’t want to be constantly issuing caveats.
So, here’s my assumption : if you’re hiring experienced developers with a specific skillโset, I’ll assume you’re smart people, that you know about the technical domain you’re hiring for, and that you can apply good judgement as to whether the candidate has the right experience or not. We’ll look at the broader picture in these posts.
And you, Technical Manager…do you code?
If you’re not handsโon with development, you need to be handsโoff with developer hiring. Nonโdevelopers just aren’t in a position to assess developer skills, and their uncertainty and lack of confidence in code will mean they’ll focus on other traits. Most likely they’ll focus on the wrong traits.
This isn’t about technical elitism, it’s about engagement: the way we hire people now needs participation from the interviewer, not just observation. So, it doesn’t matter that you used to code – everybody used to code – what matters is whether you code now. The easiest way to check is to do the online test, the assignment, or the live interview challenge yourself.
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. Hopefully you’ve heeded my advice and got as many people in your team involved in technical interviewing as you can.
CV and cover letter
For each candidate, there’s only one question that needs answered at this stage: “Can I picture this person working as part of our team, in this role?”. That’s it. I try to blot the rest of the selection process out of my mind – it’s a simple, standalone decision about a single candidate.
If the answer is “yes”, or “maybe”, I’ll have a phone conversation. If the answer is “no”, or “it’s really unlikely” then the best thing for the candidate is to give them as much feedback as you can, and let them concentrate on their other job applications.
If you have hard requirements on experience level, depth, or breadth of technical experience, you should be able to judge this quite easily if you’re working in the same technical domain. Putting aside your technical specifics, here are some things I view as strong positives in a CV, that would make me want to know more about a candidate.
- Breadth and depth: breadth is a multiplier – people with breadth add capability to teams far beyond their core skills. If you’re hiring developers, look for signs of interest in other disciplines – test automation, product design, accessibility, broad industry knowledge, anything.
- Selfโimproving: evidence of personal or openโsource projects is great, as well as attendance at any local meetups or conferences. I like to see people who are engaged in a wider technical community, although I have some important caveats on this later. Initiatives, experiments and innovation that people do on the job are things I always see as signs of selfโimprovement too.
- Coaches: I’m reassured when I see some signs that this person helps other people, because it gives me a good sense of how someone is going to work in a team. This can start in the earliest stages of a career, too, it’s not something just for more experienced developers. Any signs that people are keen to share their knowledge and expertise – at whatever level – are attributes to look out for.
- Ethical developers: you want to hire developers who care about their users, customers, and colleagues. If I see some indications that developers are motivated by making things better for people, this makes me happy. This could be adoption of better testโdriven approaches to get the product right for users or more secure code to protect them, more efficient code to improve battery life on a user’s device, or improving readability and clarity of code for their colleagues.
- Actionโoriented: it’s something of a Silicon Valley term, but it’s widely applicable in tech as a desirable trait. You want people who are going to do things, measure how they work, learn, and adapt. Some of this will be shaped by the way their organisation works, but still look for evidence that people run spikes, experiments and proofsโofโconcept, and adapt their approach.
Personal projects and meetups: a note of caution
Although it’s great to see evidence of personal projects on GitHub or elsewhere, remember that this can be a lot easier for some people than others.
It’s important to gauge this from a diversity standpoint. People with a lot of discretionary time can work on personal projects, make open source contributions, and attend meetups and conferences. However, people with childcare or eldercare commitments often can’t, and these commitments tend to fall disproportionately on women.
Also remember that some technical communities are far less inclusive than others, and it would be egregious to penalise women engineers for the exclusionary behaviour of others.
In those cases where candidates do have these projects and activities, sure, view them as positives, but always remember that personal circumstances play a part. And if you’re a cisgender, straight, white, male technical manager, understand that your experience and perception of tech communities are likely to be different from those of women, LGBTQ+ and nonโbinary folk, and people of colour who work in that same technical field.
Treat personal projects and tech community involvement as “more information about candidate <a>”, and not “this makes candidate <a> a better prospect than candidate <b>”.
Phone screens
Phone screens used to be quite the big thing: Technical Interview Lite, effectively. Typically these would be short calls, and you’d be armed with a set of technical questions. These questions were supposed to be sure-fire ways of choosing the best candidates to go forward to the next stage.
I’ve used them that way in the past, in rapid-fire Q&A mode, but always found them stilted, awkward and ineffective, and I think candidates did too. It’s a strange sort of conversation, barking questions into a mouthpiece apropos of nothing.
Good candidates blank and stumble over answers when they don’t have context. Other candidates will have memorised every Google search result for “technical interview phone screen questions”, and wing it, sometimes convincingly.
I still think there are merits to phone, Skype or Hangouts contact though. It’s a chance to check in with the candidate, let them know there are actual human beings involved on your side of the process, and that they’re regular developers too. They also give the candidate a chance to ask questions about the company, your technology, culture and teams. A matched investment.
Although I still value phone screens, I do these very differently now. I use a much more conversational style, and tend to base questions around a candidate’s experience, on what they say they know rather than what we think we need. The value in these is a consistency check, looking at experience and sense-checking against what technical knowledge we can assess non-awkwardly over a phone.
With this approach, you follow the trail of the discussion, and spot opportunities to ask some technical questions along the way. It’s more natural, tends to flow better, and you get a more accurate impression of the candidate to base decisions on.
What I’m looking for at this stage is consistency rather than probing for very deep knowledge and experience. The knack to this is to make the segue from general discussion about past experience into more technical discussion as unforced as possible, using the cues the candidate themselves give you.
This is a much harder format for the interviewer to run than having a set question list – for one thing, you need to have good conversational skills yourself, and you also need to be able to show the same genuine enthusiasm and interest you’re expecting the candidate to show. It needs you to think on your feet, but I think you get a better feel for the candidate.
Do these calls in pairs to give a balanced view. Remember from the first post the point about diversity in your pool of interviewers? Well, like any contact with the candidate, this is a point in the process where diversity of opinion matters, and give thought to who should primarily lead the conversation, and who should primarily listen.
One specific behaviour to be a little wary of is hyper-confidence by the candidate. You’re looking to hire self-aware, reflective people who learn as they go. A career presented by the candidate as an unbroken series of ever more glorious successes makes me nervous, because I work in software development too and have a decent understanding of what the reality looks like. It may just be an adrenaline rush on their part because of the call, or it may be something else entirely.
These calls can take as little as 20 minutes, although if the candidate has a whole bunch of questions, don’t cut the call short with questions unanswered. Set more time aside for the call than you think it’ll need, and use any spare to write up informal feedback.
Assessing the phone screen
When you get to the end of the screen, and discuss with your co-interviewer, focus your discussion around these points:
- “We talked to this candidate because we could picture them working with us. Is that still the case after speaking with them? More so, or less so?”
- “Did everything seem consistent? Did the narrative we got from the candidate correspond to what we read on the CV? When we asked technical questions, did the answers seem consistent with the experience that was being described? Were there any obvious gaps? Were there answers that were obviously wrong?”
- “Did the candidate seem comfortable talking about the work they’d done, or did they hesitate? Did they try and steer the conversation away from detail and technical questions?
- “Did we get a sense of enthusiasm and excitement about the technical domain, and also the role and our company?”
- “And finally, allowing for the candidate being nervous, would we change our view on any of these points above?
And make your decision like this: “Based on what we now know about this candidate, do we now think it’s more likely or less likely that we’d hire them?”
Coming next
It turned out I had a lot more to say about screening than I expected, so we’ve split this post into two parts. What can I say? Estimation was never my strong point.
In the next part – which I guess I should future proof by referring to as “Part 3 in a series” – we’re going to look at online tech tests and alternatives.
Mike Ritchie is a developer and technical coach. He helps teams with hands-on development, and builds technical capability through coaching.ย You can find him on LinkedIn.
See also
- How to hire a developer: Part 1: Hiring for the future
- How to hire a software developer: Part 3 โ Online tech tests and alternatives
- How to hire a developer: Part 4 โ Why in-person technical interviews still matter
Sign-up below to receiveย email alerts for Part 3ย and 4.
More
Follow us on LinkedIn and Twitter for the latest blog updates.
Find out more about becoming an employer partner with CodeClan.
