This is a written version of a talk I gave in the main hall at PyCon UK 2018 based on prior talks, advice, and feedback I’ve given previously. Accompanying slides available on Speaker Deck.
Hiring is hard to do well, but easy to do badly.
Determining exactly how to do it well is hard and requires nuance and context. But avoiding common mistakes is much easier.
Fundamentally, hiring processes reflect the organisation.
If you’re on the hiring side, think hard about what you’re putting in front of people who want to join you, if that will attract and select for the people you want, and correctly filter those you don’t.
If you’re on the other side of the table, think about the people who created the system you’re going through, the kind of things they’re setting up for success and failure, and the kind of people who’ve likely got through the process before you.
Some of you are or have been in the position of making hiring decisions.
Some of you are or have been involved in hiring processes as interviewers or reviewers.
Even if not, you’re probably in a position to influence someone who is, and you may even be in that position yourself in the future.
Even if none of that, chances are you may be trying to get hired at some point, and I just want you to know that it can be better.
Job Ads
Job ads are usually people’s first contact with an organisation’s hiring process.
Yet so often they’re a mess of stock phrases and checkboxes, blindly copied from something else before being thrown onto a website somewhere.
I believe in the wisdom of the Spice Girls:
Remove your terrible requirements
Biggest way to annoy with a job ad? “Require” things you don’t actually require.
The list of things you actually require is probably quite short
A previous organisation I worked with required (roughly) the following:
- Good command of the English language - they were a distributed international team, English was the language they standardised on
- Self directed learner - they were a small company without significant infrastructure for internal training - they’d support your learning, but they needed people who could own their own learning process
- Baseline understanding of building software for the web - they emphatically didn’t require you to know the exact tools they used, but they needed you to have a rough idea of what they were doing so you had the context to learn more
- No previous convictions for financial crimes - they worked in FinTech and this was essentially mandated by their lawyers/insurers
That was it, those four things.
Most “requirements” you see on job ads are really “things that are good to have”. Sometimes they’re “things we think would be useful”, sometimes they’re “things we think correlate roughly with success”. Whatever they are, list them, but be clear about exactly what they mean to you.
Let people tell you what they bring to the table
Tell people what you want, give them goals, and let them tell you how they satisfy them.
If you have all your services built in Django, and you want someone comfortable and experienced with modern Django, then say exactly that.
If you can express that more concretely then even better.
Don’t make up an arbitrary checkbox like “must have n years of experience” and hope that it maps to what you actually want.
You almost certainly do not need a degree
You do not need a degree in computer science to write code or work in tech.
You often need a relevant degree to practice medicine or law, but these are relatively isolated examples.
Do I think a computer science degree is useful? Absolutely. Do I think it’s necessary? I’ll go as far as saying “never”.
If you’re hiring people to work on hardcore database or kernel or language internals, then, sure, I get it, they’re quite heavy on the computer science, so a computer science degree would be super useful. But a degree in computer science is not the only way to know about computer science, and definitely not the only way to know about tech or programming.
A degree is a form of evidence, and absence of evidence is not evidence of absence.
Telling me you don’t know of any bugs in your code is very different to telling me there are none.
So what do you do?
Tell people what you’re like, about the team, about your tech, about your problems, about your goals.
Remember you’re trying to sell people on the job, it’s a two way street.
Take Home Tests
I feel like I see more and more jobs setting homework for applicants - “go away and write some code to do X”.
It always feels like they require a certain level of bravery and confidence to write and assign.
You’re sending someone off to spend time doing work on a task you’ve set, with limited opportunities for feedback or clarification or guidance or encouragement.
Quite often people seem to use this as part of the application process - before a (potential) candidate has even had a chance to speak with someone - rather than part of the interview process, at which point they’re relatively uninvested in the process.
If you’re swamped with applicants, I can see the value in putting a filter in place - especially for places that are a household name.
If you’re struggling to find quality candidates though, make sure you’re not dropping roadblocks in front of people you’d actually love to hire.
Fundamentally though:
Tell people how to succeed
Help people succeed by telling them what success is like.
Give people your scoring system. If you don’t have one, fix that, and stop winging it.
Quoth the Zen of Python: Explicit is better than implicit.
If you expect to see comprehensive tests for someone’s code, say so explicitly. Don’t claim “that’s part of good software development” - part of good software development is judging where to spend effort, and writing comprehensive tests for some small contrived exercise is not an obviously-valuable use of time and energy.
Be realistic
If the job is going to consist of mostly writing relatively straightforward web apps to move data around, don’t ask people to implement sorting algorithms.
Unless it’s somehow relevant or useful, don’t have them reimplement bits of the standard testing library!
Give people realistic things to do.
If they’re going to write lots of ad-hoc tools for data analysis, have them write an ad-hoc tool for data analysis. If you want them to be good at thinking about tradeoffs, give them an exercise that needs them to consider and make some.
You’re not going to be able to fully or adequately represent their job in a single exercise, but you can make sure you’ve at least thought about what you’re trying to see in them.
Set boundaries
The more self-contained and well-bounded the work is, the better.
Open-ended “impress us” tasks can easily end up over-privileging the time-rich.
When I was 21, I was dangerously keen to spend evenings and weekends hacking on cool problems. Now I’m in my 30s I’m somewhat more thoughtful and conservative about how I spend my time.
Different people will do different things, especially if you don’t have a clear scoring rubric.
The candidate who decides to spend extra time adding un-asked for test suites to the one-off web crawler you had them build? They’re not necessarily better than the one who just solved the problem and moved on.
Give people something they want to do
If you’re struggling to get applicants, a take-home test can be the first place worth looking hard at.
Test your exercise on people around you.
If the people who’ve already been hired struggle with the take-home or don’t enjoy it, then how can you give it to people you want to attract.
So what can you do?
“Here’s something with a test suite and some bugs, fix it up so the tests pass” is a good starting point. It’s closed-ended, it’s got a clear pass/fail scoring system, and we’re all used to having bugs so you’ve no worries about realism!
You’re not going to construct a perfect test, but you can at least make sure you’re setting people up for success and getting things you want out of it.
Interviews
Be Realistic
In a typical development job, you have an IDE with autocomplete, you have Google, you have Stack Overflow.
So asking me to stand in front of a whiteboard and regurgitate or invent an algorithm to detect cycles in a linked list? I’m not a fan.
It’s always going to be a somewhat artificial and contrived environment, but you can at least try to make it more realistic and representative.
Be supportive
You want to get the best from your interviewee. Help them show you their best.
Interviews can be strange, interviews can be scary, but they don’t have to be adversarial.
One of my favourite early interview questions is as follows:
Can you tell me a bit about why you’re applying to us? (“I need a job and yours didn’t look too bad” is an entirely reasonable answer!)
That bit in the parentheses is important.
Sure, I’m interested in the actual question of why someone’s applied - if there’s something that particularly appeals to them.
Without the addendum though, it can easily come across as “I want to hear you tell us how we’re awesome”, and that’s not particularly interesting or valuable - I want to be clear that I want their honest, human answer, whatever it may be.
Nobody likes magic answers
There’s been a bit of a trend of asking “magic answer” questions - “how many piano tuners can you fit inside an African swallow flying over New York City”.
Sometimes they know the answer / have encountered a similar question before, so it doesn’t tell you much. Sometimes they can work it out, but an interview is not a pleasant or fun environment in which to have to do this. Distressingly often, it’s a show of superiority from the interviewer.
The Curse of Knowledge usually means that once you know the method/trick it’s obvious, and incredibly hard to recognise how hard it is for someone who doesn’t.
You can still do this well - use it as an exercise to see how people think, how they approach a problem, techniques and tools they use, rather than “do they know the answer or can they get there”, but you need to be supportive and very clear about your expectations.
Don’t just drop a question and sit there waiting!
So
There are lots of ways you can easily do not-great things while hiring.
Hiring is important
Hiring and recruitment are some of the most important activities an organisation can do, and should be treated accordingly.
Stop blindly copying others
So many problematic things originate from sloppiness, from cargo culting, from just blindly copy-pasting something seen elsewhere, or something someone had the misfortune of experiencing themselves.
Don’t just Google the top 100 interview questions and pick ones that sound good.
Don’t just ask semi-obscure questions where you happen to know the answer.
Don’t just have someone write some arbitrary code that sounds interesting.
Be thoughtful!
If you own or can influence the process, be really thoughtful about it; think about about the tradeoffs you’re making, and what you’re doing.
Test what you’re doing! Get data, get feedback, learn and change accordingly!
Questions
I had some great questions when I gave this talk at PyCon UK 2018. I’ve tried to paraphrase them below:
Q. How would you go about convincing people of some of the more unconventional advice here?
I loved this question!
I had to ask exactly what they meant by “unconventional”, because one of the problems I had when writing this talk is that (thanks Curse of Knowledge!) to me it all felt fairly straightforward and obvious - think about what you want, make sure what you do reflects that, no really.
So, they clarified:
Q. How would you go about convincing people that they don’t need to require a degree when hiring?
My go-to answer here is quite flippant: it’s a competitive market, so personally I wouldn’t, I’d go and enthusiastically hire all the awesome people they’re missing out on!
I’ve been fortunate enough to work with a whole bunch of fantastic people. Some had degrees in computer science. Some had degrees in other subjects. Some didn’t have a degree at all.
A degree in X is a reasonable signal that someone knows about X. It is not the only way, and it is not a guarantee.
I don’t have stats or citations here, only my own anecdotes and experience (not that that’s stopped me yet), but I consider “a degree in X” in the same way I do “Y years of experience” - if someone tells you they have it, great, but if that’s the shape of the filter you require everyone to fit for, you’re going to miss out on a whole lot of awesome.
Q. We do a lot of work trying to make hiring as objective and analytical as possible - what do you think about that?
I think it’s useful to differentiate between things you measure and things you assess.
You measure objective facts / stats / properties, quantitative things; lines of code committed, salary, years spent using a given tool.
You assess more subjective things; is someone a good software developer, does a job make you happy, is someone good with a tool.
Measurements can broadly guide you towards an assessment; if someone’s committed no code this month then they might not be doing so great as a software developer, if your salary isn’t enough to pay your bills you might not be happy in the job, and if someone’s been using a tool for 30 years then you’d hope they’d be competent with it.
It’s dangerously easy to feel like measurements or metrics give you the full picture.
Structuring your assessment (e.g. with a scoring rubric) is great, using metrics to augment your assessment is good, but I don’t believe you can yet make good decisions from metrics alone.