Random Thoughts on Hiring

With a flurry of passionate blog posts on the blogosphere recently and a bit of on-the-job action, the topic of hiring has been filling my shallow, little mind with many deep thoughts of late.



So In this post, I’m going to throw lots of random thoughts at you. I’m not saying they’re good. I’m not even suggesting you should try them. And I certainly take no responsibility if you borrow my ideas and hurt yourself.



I wanted to put these thoughts in writing to gain clarity and headspace back. And I decided to blog them so that you wonderful people of the internet can all tell me how incredibly wrong, naive and foolish I am. Thank you all very much in advance.

Interviews should be stressful and uncomfortable… shouldn’t they?

Allow Candidates To Express Their Range of Skills

The role of software developer encompasses an incredibly diverse range of skills. Writing code, shipping software, collaborating with non-technical people, debugging problems, architecture, UX, leadership, teamwork, to touch briefly on just a few.



It is a fact that any candidate will have knowledge and expertise that you don’t. So I think it’s very foolish and shallow to only ask candidates questions to which you know the answer. Instead, I think you should give candidates an opportunity to talk about diverse topics and present information that you don’t know. Let them teach you something, basically. It’s astonishing how much you learn in interviews, and quite humbling.



Always remember, you could be the University of Bern who rejected Einstein because he was so far ahead you just weren’t smart enough to realise what a brilliant candidate you had in front of you.

Don’t miss out on candidates who are too good for your hiring process

(photo credit Wikipedia)




My current thinking is a three-staged hiring process. Firstly it’s an hour of coding. Let candidates loose on some of your code and ask them what they think. And then do some pairing together, understanding how they work and think. Maybe throw a few curve balls and see how they react. I like to do this at a developer’s desk in the office for an accurate representation of the company environment.



After that, I like to move onto architecture. Ask the candidate to draw some diagrams of systems they have built in the past. Allow them to explain some of the decisions that were made and how they might do it differently in the future.



Finally, it’s time to do some talking. Although in practice, the order doesn’t matter too much.



With the discussion stage, I prefer open-ended questions on a range of topics from process to teamwork to more technical questions. And of course, plenty of opportunities for candidates to ask their own questions.

Look for Potential Not Perfection

I’ve worked for a few companies who have an encouraging and passionate development culture focused on quality, delivery, and continuous learning. These environments bring out the best in developers. I believe all you need to look for during an interview is the potential for someone who will flourish given the opportunity in your culture, and not someone who is a perfect fit (because they are often time-consuming to find).



If you can only hire perfect-fit developers — what does that say about your culture?



Maybe a candidate’s coding sample was a bit dodgy in places. Maybe the candidate thought that deploying once a month was a best practice. Maybe the candidate even likes VB.NET. Many companies will review facts like these in isolation and instantly blow candidates away.



But I’ve seen what happens when you look for developers with potential — developers who can learn quickly, work well in teams, and are passionate about personal improvement. If your culture allows them to flourish, you don’t need to hire developers who are pre-rolled into the shape of your preferred ways of working.

Harvey saw potential in Mike — a college drop-out who became New York’s most talented lawyer. Even without a law degree (photo credit: Suits TV show)


One candidate who turned out to be exceptional and highly rated by everyone at one company I worked for wrote in his coding test notes: “here’s how far I got in an hour. The code’s not great but I ensured it was tested and structured in a reasonable manner. I didn’t do much of the UI because you said it wasn’t that important”. In fact, the UI was terrible and it didn’t even work properly — but we knew why so we didn’t assume guilt or lack of professionalism.



By not being elitist examiners who get an ego boost from failing candidates for explainable imperfections, we were able to hire an incredibly savvy and well-balanced developer who continually demonstrated maturity and leadership skills that we all aspired to.



Another candidate who turned out to be exceptional submitted a very average code sample. But in her notes, she mentioned: “I’ve only got a basic understanding of this language, but I’m very keen to learn more”. The code was tidy, with explicit naming and well tested. It just wasn’t very idiomatic for the language, and clearly demonstrated poor knowledge of the even the very basics.



But we brought her in for a face-to-face and were hugely impressed with her appetite for learning and her positive and collaborative attitude.

Pre-Interview Coding Tests Are Useful

As much as it causes extreme offense and patronisation to elite developers, as a candidate and an interviewer, I see value in coding tests prior to in-person interviews…. with a few caveats.



The coding test must be explicit about how it will be assessed. In one or two hours, with ambiguous requirements and no business stakeholders to talk to you will not get production quality code. The candidate will have to make assumptions about business context, requirements and what is needed from the code.



For example, in 1 hour of coding, you can write about 80 lines of production code assuming you view production quality as having good automated test coverage to support continuous delivery.



At this scale, design principles like SOLID offer little value. You can split 80 lines up into a bunch of small methods in one class. And that’s fine because it’s well tested, easy to maintain, easy to understand and it fits in your head. So if you are expecting people to over engineer 80 lines of code with unneeded abstractions, be explicit about that.



My own thinking is inspired by a number of exceptional developers who follow a heuristic along the lines of: “procedural until it’s painful” — where they let code get a little bit messy and they refactor later as abstractions emerge rather than trying to design perfectly first time. In fact, I first learned about that in the GOOS book.



Imagine that you wanted someone who can write production quality, well-tested code and you turned down TDD and OO wizard Steve Freeman because he was waiting for an abstraction to emerge before making important design decisions in his coding test.



There are two tactics I use to mitigate the problem of being too ignorant to recognise brilliant candidates who think differently. Firstly be explicit about what you are looking for, and secondly ask them to make notes about the decisions they made. Encourage them to explain how they handled ambiguities in the requirements, or what they would have done with more time, or how the constraints of the artificial scenario affected their solution.

Pre-Interview Coding Tests — But Not Always

Sometimes I think it is reasonable to not ask candidates to do a coding test. When you see a CV and you think the developer has a lot of potential, you should be worried that a lot of other companies are thinking the same. If that developer gets asked to do 10 coding challenges, do you think they are going to spend 40 hours doing all of them?



So occasionally it’s savvy to skip the coding sample and invite someone in straight away. You then have to decide based solely on an interview if they are a good fit. It’s a bit of a risk either way — you send them the test and you miss out completely, or you skip the test but have fewer chances to assess their suitability.



In my experience, missing out on in-demand candidates is by far the greater risk.

Coding tests are great — but you might miss out on sought-after candidates


My recommendation is to make reviewing CVs a team activity (more in the next section). Let each member of the team rate each CV with one of three recommendations:

  1. get them in ASAP
  2. send out the coding challenge
  3. no sorry

Then have a discussion afterwards and reach a shared agreement. If the team are collectively happy to take a small risk on someone then it’s enough confidence to go for it.

Hiring Is a Team Sport

From start to finish, I believe every stage of the hiring process should involve multiple members of the team. This is a very strong opinion I have for a number of reasons.



The first reason is ownership. When you make a decision to hire someone, you feel responsible. And it motivates you to do as much as you possibly can to make that person successful at the company. So if the whole team is partly responsible for hiring someone they all feel responsible for making their decision a good one.



Another compelling reason to do hiring as a team, and one that I touched on earlier, is that candidates know things you don’t. If a candidate can make just one person in your team start fighting their corner, your teammate’s credibility may encourage you to question your own beliefs. And maybe you won’t let an Einstein slip through your net.



And finally, out of respect alone you should get your teammates opinions on any new hire. It’s an important decision and someone they will be working with. It’s their right to have a say in the matter if you expect to build a strong team who feel appreciated and valued.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.