5 tips for recruiting an open source job candidate | Opensource.com

5 tips for recruiting an open source job candidate

Let's look beyond exam scores and hire open source candidates based on their ability and potential.

Two hands holding a resume with computer, clock, and desk chair
Image by : 
Opensource.com
x

Subscribe now

Get the highlights in your inbox every week.

This is one of those more open-ended posts in that I don’t have any good answers, but I’ve got a bunch of questions. I’d love to have feedback, comments, and thoughts if you have any.

Recently, it was "results week" in the UK. Here, there are two major sets of exams that most students take: GCSEs and A levels. The former generally are taken by 16-year-olds, with around 8-12 in total, and the latter by 18-year-olds, with 2-4 in total (3 being the strong median). A level results are one of the major criteria for entry into universities, and GCSE results typically determine what A levels students will take, and therefore have an impact on university course choice in the future. 

Both GCSEs and A levels are determined, in most cases, mainly by examination, with even subjects like PE (Physical Education), Dance, and Food Technology having fairly large examination loads. This was not always the case, particularly for GCSEs, which, when they were launched in the mid-1980s, had much larger coursework components than now, aiming to provide opportunities to those who may have learned and retained lots of information, but for whom examinations are not a good way of showing their expertise or acquired knowledge base.

At this point, I need to come out with an admission: exams suit me just fine. I’ve always been able to extricate information from my memory in these sorts of situations and put it down on paper, whether that’s in a school setting, university setting, or professional setting (I took the CISSP examination ages ago). But this isn’t true for everybody. Exams are very artificial situations, and they just don’t work for many people. The same is true for other types of attempts to extract information out of people, such as classic coding tests. Now, I know that coding tests, when designed and applied well, can do a good job in finding out how people think, as well as what they know—in fact, that should be true for many well-designed examinations—but not only are they not always well administered, but the very context in which they are taken can severely disadvantage folks whose preferred mechanism of coding is more solitary and interactive than performative.

A family friend, currently applying for university places, expressed surprise the other day that some of the Computer Science courses for which he was applying didn’t require any previous experience of programming. I reflected that for some candidates, access to computing resources might be very limited, putting them at a disadvantage. I’ve made a similar argument when discussing how to improve diversity in security (see Is homogeneity bad for security?): we mustn’t make assumptions about people’s potential based on their previous ability to access resources which would allow that ability to be expressed and visible.

What does this have to do with recruitment, particularly? Everything. I’ve been involved in recruiting some folks recently, and the more I think about it, the more complex I realise the task is. Finding the right people—the people who will grow into roles and become really strong players—is really tricky. I’m not just talking about finding candidates and encouraging them to apply (both difficult tasks in their own rights), but choosing from the candidates that do apply. I don’t want to just find people who examine well (looking solely at their academic grades), people who perform well (who shine at coding exercises), people who interview well (those who are confident in face-to-face or video conference settings). I want to find people who have the ability to work in a team, grow the projects they’re working on, contribute creatively to what they’re doing. That may include people who fall apart in exams, who freeze during coding exercises, or whose social anxiety leads them to interview “badly.”

I’m not sure how to address these problems completely, but there are some things we can try. Here are my thoughts, and I’d love to hear more:

  1. Look beyond exams and rate experience equally with academic attainment
  2. Accommodate different working styles
  3. Be aware that the candidate may not share your preferred interaction style
  4. Think “first language” and work with those whose native language is not yours
  5. Look beyond the neurotypical
  6. Consider any existing open source contributions (e.g. on github) - not having any shouldn't necessarily count against them, but if they're there, use them!

None of these is rocket science, and I hope that the recent changes in working habits brought around by the pandemic have already started people thinking about these issues, but let’s work harder to find the right people—not just the people who look and think and talk (and take exams) just like us.


This article was originally published on Alice, Eve, and Bob and is reprinted with the author's permission.

Looking at a map

There are many roles in tech for people who aren't engineers. Explore some of them in part 2 of this series.
Stack of books for reading

Open source makes software knowledge accessible to anyone, so formal training isn't the only path to a technology career.
Looking at a map for career journey

Our past lives can be exciting and funny. Here are some surprising ways folks have made their way to open source.

Topics

About the author

Mike Bursell - I've been in and around Open Source since around 1997, and have been running (GNU) Linux as my main desktop at home and work since then: not always easy...  I'm a security bod and architect, co-founder of the Enarx project, and am currently CEO of a start-up in the Confidential Computing space.  I have a blog - "Alice, Eve...