I have a friend who was hit by a workforce reduction at a company I used to work at (as was his entire department). He is a brilliant engineer who has worked on some massive projects. But is struggling to find somewhere new in-part due to the insane way the recruitment process works in our industry.

I’ve had a lot of conversations about recruitment in the last few months for seemingly random reasons and unfortunately there are still lessons that appear to need to be learnt. This post is to share my opinions on hiring in tech, specifically Open Source remote workers but some can be applied to other roles. My opinions here may not be popular but feel free to comment.

Degrees vs Experience

There is a case my wife witnessed many years ago where there were two candidates for a specific job. The first had many years experience in that role, the second had an unrelated degree and had no experience. The company jumped straight onto the second candidate. This wasn’t a tech job but unfortunately the same thing is happening in tech.

In my case I do not have a degree, but I have many years experience. I have been a Principal Software Engineer for a large tech company. I have been the team lead on large software projects with engineers working for me (one project that failed three times under other people but succeeded under me). I have been a keynote speaker at an O’Reilly conference. My point is I am probably not too bad at what I do (that isn’t for me to judge).

Yet I know of HR department in certain companies that would instantly throw my CV in the bin because a degree isn’t listed on there. I’m not so concerned for me right now but this is happening to other really good engineers who would be an asset to a company.

Don’t get me wrong, a degree is a great way into this industry but it should never automatically trump experience. Both should be accessed with some balance. Some of the best engineers that I have worked with have had degrees, but some have also come from military backgrounds or were not fortunate enough to be able to go to university and had to work hard in other ways.

A few years ago I noticed that a local friend who was a chef was gifted enough to understand code. I helped train him up in how to be a good engineer and he got a job as a junior PHP developer. Today he is a team lead at a software company in a nearby city. He doesn’t have a degree but is extremely dedicated, a very fast learner and very good at what he does.

Whiteboarding

I have tweeted about this a few times recently, for example:

For those who don’t know, whiteboarding is an interview where you will be given a certain coding task to do on a whiteboard. For example, code a binary tree, or code X sorting algorithm.

I have failed these tests every time (apart from one company where I told them that they had failed the interview). They are almost never relevant for the job. You don’t have your tools, resources and colleagues with you. Sometimes the job is to work in a language you might not even know yet.

I had an instance where I needed to hire a new engineer for a job to work for me. I picked the guy who probably didn’t have the most experience but had a clear history of having an ability to learn quickly and was a better personality fit for the team. A manager above me gave the two candidates a whiteboarding interview and overruled me, hiring the other person. I actually left that department soon after that.

This process might be a good way of weeding out recent graduates but I can say with some certainty that many of my past colleagues who have worked on software that is pretty much the backbone of the Internet would (and do) fail these.

I have literally heard these interviews referred to as hazing processes or a way for recent graduates to try and outsmart experienced engineers. Whilst I like to defer to Hanlon’s Razor (“Don’t assume bad intentions over neglect and misunderstanding”) I can see where these views are coming from.

Companies that interview in this way are throwing away talent in favour of people who can memorise interview cheat books and algorithms from the 1970s. Almost no engineer ever looks at these again after they graduate.

What does work?

I’m gearing this part more to remote work Open Source engineers because that is what I know, but some of this will also apply to other tech jobs too.

Many experienced engineers have contributed to projects on GitHub. Unfortunately GitHub doesn’t always have the right UI to show you this. Make sure you look at contribution history and those projects as well as their repositories. My main projects work using developer branches inside the projects so they do not show up in my repositories (and often don’t show up much at all because master isn’t updated often).

If you really do need to test their development abilities give them a write-in test. Give them a code sample to debug. But not in a face-to-face setting. The experienced candidate will have certain tools and processes for how they work. Throwing a Mac with a US keyboard layout in front of them and asking them to fix something when they only used Linux with a UK layout is going to struggle.

You could get the candidate to look over the source code of your project in their time and get them to answer questions on how they think some parts work. You may not always get right answers and that isn’t bad, people are sometimes wrong and being wrong sometimes is a good thing (that is probably for another blog post). But you get a clearer picture of how they communicate ideas. Also really important that such tests are vetted by your team first.

The key things I hire for are experience in the industry relevant to the role (a junior probably won’t have much experience), the ability to learn and a personality that will work well with our team. I often hire home workers which also require a certain discipline to get the job done which I look for, it isn’t for everyone.

Drilling down into experience and ability to learn. The candidate doesn’t have to have any experience in the language that we use. Often candidates will come to me with experience in several different programming languages and just like human languages, once you have a few under your belt it is pretty easy to pick up more. As long as the candidate is showing willingness and ability to learn.

This is the kind of industry that you are forever learning in. There is new technology all the time, the field grows exponentially. I don’t (and couldn’t possibly) memorise the entire syntax for every language and library I work with, but I have memorised where to quickly look them up when I need them and which is the right tool for the job. Having this index card type ability is way more important than how to write a sort algorithm off the top of your head that is pretty much built-in and highly optimised in every language’s standard library.

In my own experience I have made hiring mistakes before. Most of the time for not following my own rules and trying to get a candidate to fill a role quickly rather than finding the right person for the job. I have learnt from them and hopefully it won’t happen again. If you hire someone that doesn’t fit then it might be possible to move them to a department where they will, or as a worst case scenario there is the probationary period.

I know my opinions in this post will not be shared by everyone. There are many big companies who’s hiring techniques are the polar opposite of what I have said here. I do hope as an industry we can improve things so that the right people get the right jobs. But it is never going to be an easy task. Some mistakes will be made along the way.

Please comment on your own experiences and thoughts on the subject. I would be really interested to learn beyond my own bubble.

Image credit: Steve Jurvetson, used under a Creative Commons license