Hiring - Job ads, Interviews & Processes

Job advertisements

When you write a job advertisement, you want it to reflect the details of the role, and to be honest.

If you convince the 'best people' to come and work with you on a false premise, there is going to be trouble down the line, as their expectations meet the reality.

Instead, being up front, and talking about what the role will likely entail allows the applicant to make an informed choice and ask questions. You might set out some pros, and considerations:

Pros (in favour of the role)

• We have a well maintained, tidy code base. As your manager I will read the code that you write, and encourage software engineering excellence.
• I understand work life balance. I like my reports to have the opportunity to work from home at least once a week, while I am in the office to assist with communication as needed. I will generally not ask you to work late, unless something unusual has happened, we should be able to complete our tasks within our regular working hours.
• We are working on the forefront of technology X! (For example VR or AR) As pioneers we have the opportunity to bring new experiences to our users and truly delight them in the way that touch screen phones with intuitive GUIs marked a turning point in mobile phone technology. By working together we can create an experience that we will feel proud of, that simply does not exist in the world yet.

Considerations (things to note)

• We are engineers, not designers. Although our feedback is welcomed and important, our role is to support the designers and implement their vision upon solid yet flexible software architecture. In this way we empower their vision in an agile way, allowing them to learn from prototypes, and iterate.
• We are a startup, and to quote Eric Ries "A startup is a human institution designed to create a new product or service under conditions of extreme uncertainty." This means that fluctuation and pivoting is likely, as we learn about the business.
• What we are building will take time to create - six months from now what will keep you enthused about this project? Why are you passionate about this particular endeavour?

Don't try to force people to be passionate about what you are creating. Find people who are already passionate about it, and explore why this is so with them. The time that we spend doing something can never be replaced, so what we work on needs to matter.

"“People leave managers, not companies.”

If you are going to become someone's line manager then you have a responsibility to that person. You are going to have an effect on their life, for better or worse. From the moment that you interview them, you have the moral responsibility to be honest about the position. Start with integrity, and maintain it. Don't gloss over or conceal negative aspects of the role, just because you want to hire the best. This will make retaining people easier later on, its the first step in earning trust, and later respect.

Don't bullet point 10 'key skills'

There may well be 10 important aspects of the job. But they cannot all be described as 'key', ten is simply too many. Try to limit the key skills section to 3 to 4 key skills, things that are going to be truly essential to performing the role. Otherwise you dilute the importance of each item in the list - applicants would have to guess which skills are truly key.

Avoid gender coded words

Once you have your final draft of the job specification, run it through a Gender Decoder, to avoid gender biased language. We have all seen words like 'ninja', 'rockstar' in adverts and yet they have masculine connotations. Although these two words above are not flagged at on the gender decoder at katmatfield.com I would personally avoid them as they are also rather vague!

Is being gender neutral enough?

This is entirely up to you. Personally I would argue for making the playing field level. Going beyond that and veering towards a non-neutral stance perpetuates a bias, regardless of your reasons for doing so. If you perpetuate bias than your actions can be used by others to justify bias - bias of any sort, gender, racial etc. Whereas if you hire in a neutral merit based manner, than you are making the system better for everyone.

Stage 1/3: An initial video call Interview

I suggest doing this either with Google Hangouts or Skype. It is not essential for it to be a video call, and the person being interviewed does not need to have a camera. But giving them the opportunity to see you as you speak together can build trust, and empathy. Through non verbal communication, they can see from your facial expressions and body language what you mean, more clearly, and vice versa.

Also if there are multiple people present at this stage (try not to have more than two, as it can be intimidating) it allows them to put a face to the name of each person.

Finally you are building a rapport, if they get invited for an onsite interview than there is recognition already, which breaks the ice.

Stage 2/3: An offsite coding task

I find it useful to have a piece of code to discuss with the people applying for the position who are invited for an onsite interview. This allows me to measure people's coding choices in a fair and equal way. And it is useful to have something to talk through together. But show some restraint, when you set this:

1. Only ask for something that can be achieved in 2 hours or less. State this in the definition of the task so that people understand you are being reasonable and not careless with their time. Computing is vast and people have different skill sets and experience. People have lives and jobs outside of applying for this position, you do not want them staying up through the night or spending their weekend doing this, do you?
2. Do not ask the applicant to make the code neat and tidy. If you care about this (I do) then you will learn whether they also do. But if you ask them to make it neat, everyone will regardless of their normal inclinations. If what you've asked them to do can be achieved in less than two hours, then tidying it at the end will only take an extra 15 minutes or so.
3. Supply images, example output, everything you can to make the coding task definition obvious and understandable. That is what a good manager does when they set goals, they make it easy to get right, and hard to get wrong.
4. Ideally pick something that they might have the opportunity to use later within the role. That could be very satisfying, and show forethought on your part.
5. Give them at least a week to complete it. Explain that you want them to approach it when they are in a relaxed state of mind, and that although the task can be achieved in 2 hours, it is up to them to manage their time and choose when to do it. This is a work related task - beyond work people have families, travel, groceries, laundry, and entertainment to consider. Those are needs. They are likely interviewing for other positions also, and will appreciate being given the time to do this when they can fit it in to their personal time.

Stage 3/3: A final onsite Interview

Try to be flexible about the timing of this. Personally I'm willing to stay late and conduct it outside of my core working hours, if it means that a candidate can do it after work. The same applies to before work, but I think after is better as it removes the time pressure of having to go to work afterwards. By offering the possibility of this, you'll stand out as someone who cares about other peoples time, and respects the fact that most candidates would otherwise be at work. Or you might schedule it so there is the opportunity for them to leave early, but not have to take half a day off. This is kind.

Do not assume that every programmer needs to work onsite. The world is changing, and people do great work offsite too. Similarly the final interview does not have to take place onsite, if this is not feasible.

Take this opportunity to get the person to walk you through their code, ask them about the choices they made in a friendly non judgemental manner, and discuss with them what they might have done given more time, or to simplify refactor the code now that it is complete. Ask them about class and method naming, method length, and structure. You should of course have read through all the code before hand and made some notes so that you have equal familiarity with it. If there are things you don't understand in the code, don't hide that, explore it with them.

Programming on the White Board? Really?

You should not need to ask people, because you've already set a Coding Task. Programmers do not program on white boards, even at university. I've never seen any programmer dry run code on a white board, it is uncomfortably vertical, and archaic.

Unless you are interviewing for a lecturing role, why would you do this?

In meetings yes we use white boards but not to write code, much less test it. Everyone has a favourite editor, and is probably enjoying the benefits of syntax highlighting, autocomplete, fixed width fonts and other features common to modern programming.

I once did a whiteboard programming exercise surrounded by five other programmers as part of a day long interview.

Needless to say they all had laptops in front of them, and were sat in various desks arrayed around the room, facing me. whereas there I was with a blue marker pen standing facing the board writing code.

I was reminded of Jeremy Bentham's Panopticon.

I could not remember the names of the different people in the room, but they would ask different questions, and as soon as I answered one on the board, another one would pipe up, wack-a-mole style. Only in retrospect did I realise that a new question was a sign that the answer I'd given was accepted, in the instances where it was not the person asking would proceed to cross examine me while their peers looked on.

Aim to choose three or less people for the final onsite interview

You don't need to hire someone perfect for the role. You need to hire someone with the potential to be perfect for the role.

As a manager, your job is to take someone with the potential to be perfect for the role, and help them realise it. So don't waste your time and other people's time interviewing ten people for 1 role!

If you have found three people that have succeeded at Stages 1 to 2, then it is time to invite up to three of them in for the final onsite interview, and make a choice.

• All three of them have the potential to do this role.
• Even if you have only found one or two people who have succeeded, this is enough make a choice from.
• They won't want to wait forever, and you need to respect their potential.

Be respectful and honest with the people you turn down. Explain that you are not being overzealous and interviewing tens of people for the role. Commend them on their success, and perhaps ask if you may add them on LinkedIn? These are people who you may yet work with in the future, if you behave respectfully, and show gratitude for their interest.

If their their work in their coding task has impressed you in Stage 2/3, you could take a moment to recommend them on those skills that they have impressed you with. Giving something back will not take long, but it can mean a lot, and feel liberating!