This episode is part of a recruitment mini-series; where I will be focusing on various characteristics that I believe are important in recruitment. And while I believe many of these themes are universal, I will, of course, be focusing on software development. In this episode, I talk about the actual interview. Interviewing an individual to gauging future performance is far from a fool-proof means of recruitment. Unfortunately, it is commonly the only option available to us. I'll provide advice, from my personal experience, on what works well and a few things that don't.
Or listen at:
Published: Wed, 11 Mar 2020 17:05:41 GMT
Transcript
First things first;
No interviewing technique or approach is perfect.
Interviewing, by its very nature, is an artificial activity.
We attempt to assess an individual's future actions based on their interpretation of past performance.
The whole process is hardly ideal.
But of course, there are better practices than others. Just remember there is no silver bullet.
Let's start with the general approach.
We should be aiming to make the interview as pleasant an experience as possible.
We want any candidate to leave the interview feeling that they have not only been welcomed - but that the organisation has gone out of its way to provide them with the best possible opportunity to shine.
Even if they aren't offered the role, you want them to come away telling people it was the best interview they've ever had.
Remember that recruitment is as much about selling as anything else. Going out of your way to be welcoming goes a long way in that.
Think about them as being a great prospective customer; how would you welcome them?
They are someone that could revolutionise your organisation.
You want them to want to be part of it before you've even asked the first question.
Remove any difficulties that the candidate may have.
If it is difficult to park, make sure you have a parking space allocated for them (and let them know).
If they aren't local to the area either recommend, or even better pay, for a hotel.
Make sure they have an opportunity to freshen up before the interview.
Make sure that they are offered water, tea or coffee.
Make sure that they are comfortable in the room.
Again, think about all the things that will have the candidate telling people it was the best interview they've ever had.
This not only helps with that candidate; it adds more to your brand as an employer.
We should also remind ourselves at this point that everyone is different.
Diversity in the human condition is a broad and wondrous thing - so you should always be cognizant of the individual and how they are handling the situation.
I've previously suspended an interview before because the candidate was suffering considerably from anxiety. I allowed them the time to take a break, gather their thoughts and restart when they wanted to.
You have to work with the candidate to get the best interview you can.
Subjecting everyone to the exact precise cookie cutter interview can disadvantage great people - people that you simply won't get into your organisation if railroad over them with a quickfire list of 100 questions.
You are trying to get the best out of that individual - as such, you should be focused on the role at hand.
You should not be artificially adding additional stresses and pressures to the interview.
Interviewing can be a stressful enough activity without inadvertent or, god forbid, intentionally adding more pressure.
Thus, I'd recommend avoiding anything that is designed to see how they handle pressure or stress.
I've seen some ridicules activities which ultimately don't help anyone; such as:
- putting the rooms aircon up a few degrees
- asking Google-esk questions like "How many golf balls can you fit into a car?"
- having a good-cop, bad-cop routine.
While I can understand that you may want an employee that can handle pressure; it is unlikely that the role requires them to be able to perform the impossible in a closed room, on their own, while the people who hold power over their career stare menacingly over the table at them.
Focus on the role you are recruiting for.
When it comes to interviews, I will generally try to use a two interview process.
The first a telephone call. The second face to face.
Make sure that you've told the candidate ahead of time what form any interview will take - as I said in episode 29, put it in the briefing document. The telephone call allows both parties to make sure we are both on the same page. More than once, I've had a candidate come to interview believing the role is something different than on offer.
The telephone interview allows a somewhat "low effort" activity for both parties to make sure there aren't any immediate show stoppers.
I'd start the telephone interview by checking their expectations for the call;
Are they excepting the call from me?
Are they in a good place to talk?
Do that have the time to talk?
I generally like to allow 30 minutes - but sometimes this doesn't get passed on by the agency.
I'd rather know they can only talk for 10 minutes at the start of the call and adjust rather than have to cut off unexpectedly.
I then talk them through the format of the call, who is on it (generally two people interviewing) and if they are comfortable with that.
I'll generally use the first five minutes describing the organisation and how the role fits into it - highlighting anything that we will likely discuss in the call or likely to be of importance to helping the candidate frame any responses - along with how I (and anyone else on the call) fit into it.
I will use that time to subtly sell the organisation and role - highlighting the essential aspects.
I'll then ask the candidate if they have any questions from my description.
We'll then move into asking the candidate several questions based on the role and their CV.
I find that its best to have those questions pre-defined before the call. Often many of those questions will be the same for any candidate applying for the role.
I'll make notes as we go so that I've something to refer back to when considering the candidate later - not merely relying on an impression.
Following those questions, I ask again if the candidate has any further questions.
After address those, I close out the call by setting expectations with the candidate what the next steps in the process are and when they can expect a response.
The second interview is face to face and generally longer - I usually allow for about 90 minutes - although typically its closer to 60.
Most roles I've interviewed for have been office-based; thus, I feel it's essential for the candidate to see the office and area they will be working.
Early in my career, I interviewed a candidate that, on paper, I would have given my right arm for.
After having walked them through the very loud and busy open office, they immediately said that they simply wouldn't be able to work in such an environment. They had spent many years in a small office mainly on their own with minimal distractions. They knew straight away that the environment wasn't right for them.
While a disappointment, it was the best outcome.
Now I make sure that every candidate gets an idea of the working environment - you may remember I even mentioned in the briefing document in episode 29.
If the role is 100% remote, then I'd probably relax that and perform the interview virtually. I would, however, still want to offer the candidate the opportunity to come into the office.
The face to face interview follows a relatively similar format to the telephone interview in its structure; * Make sure the candidate is comfortable and at ease * Summarise the format of the interview * Expand on the organisation, role and how it all fits together * Get any early questions from them * Go through the interview proper * Again, provide them with an opportunity to ask further questions * Wrap up and let them know what the next steps are and when they are likely to hear back
The thing that does differ is the content of the interview.
While I've tried, and been on the receiving end, of various interview techniques, I find that a split between questions and practical action works well.
The questions will generally be a combination of some technical and some personality traits. None are designed to catch people out - instead, to establish if I have a good understanding of the person in front of me.
The practical action is usually a small development task working as part of a small mob programming group.
For those that haven't listened to episode 24; Mob Programming is the act of multiple people working on the same problem on the same computer. One person acting as the driver - operating the keyboard and mouse - while the rest of the team take on the role of navigator. They help to direct the driver through the work. The role of the driver is then rotated through the team - generally, each driver having 5-15 minutes at the computer.
In the interview, the candidate will take the role of the driver and then myself and a second interviewer will act as navigators - potentially swapping the roles if appropriate.
The aim is not just to see how the candidate solves technical problems, but also how they interact with others while they do it.
What questions do they ask to clarify the work?
Are they able to articulate their thought process?
Are they able to understand an alternative point of view?
Many times I don't see (or indeed expect) the best technical solution in the world. So much of development is thinking about the problem - time away from the keyboard - something you're going to struggle to get spot on in an interview. Its more to get an idea of how they approach a task and engage with others - not the actual task itself.
I thought I'd finish this episode off with a few things that I don't like;
Things that may seem like a good idea on the face of them.
It became quite populate a few years ago for agencies to get a developer to go through an online test - then provide the organisation with the test results.
As I say, on the face of it, this seems like a great idea - a level of proof that the developer can do what they say they can.
But I've found two problems with it.
Firstly, all the agencies seemed to be using the same test. It was a service that could be subscribed to by the agencies.
At one time when I was between contracts, I found that I was sitting the same test multiple times. It got to the point where I could recognise the questions.
Now imaging an individual who doesn't necessarily have the technical experience, but is being tested by a variety of agencies - after a point they will effectively ace the test based on repetition and familiarly rather than knowledge or experience.
Secondly, some developers where simply put off. While there will be a variety of reasons - part of it will be merely feeling they are too good to be "vetted" by such a blunt instrument (which will undoubtedly be true) and fear of being shunned by that agency if they have an "off day".
We all have "off days" - would performing poorly on this test then following them for potentially years to come in the jobs market?
The other idea is asking the candidate to prepare a "sample application."
For one role, I was asked to prepare a simple website that would show the top news stories from the BBC. I was expected to perform this in my own time, then provide the work to the employer to review.
Again, in theory, this feels like something that should work;
If the candidate is prepared to spend their own time; then they are keen on the position.
You get to see a sample of their work for very little effort.
In practice, however, it is just a massive turn off and can rule out a lot of the better candidates.
The sample application I was asked to build was expected to take around 4 hours.
That's a considerable amount of time to spend if you have busy commitments (work, family, etc.). Especially if this is being done before the company has even made an effort to "sell themselves".
If every employer was doing that, I could have a full-time job just completing test applications.
It also sets warning flags around how the business works. Is this sample application a typical way they work? Is it representative?
Is a typical day going to be receiving a short written briefing and being told to have it done by lunchtime?
I doubt it, but it doesn't come across well.
The thing that both of these activities has in common is the attempt to save the organisation time.
Both activities are attempting to save time talking to what they would consider poor candidates.
It's so much quicker to review a test score or a sample application that actually talk to the candidate face to face.
And of course, they are probably patting themselves on the back by filtering out the time wasters that can't be bothered to take the exam or create the sample application.
That's similar to the clothes store that congratulates themselves on not have long lines at the till because they didn't turn the store lights on.
In this episode, I talk about the interview processes I use.
I've talked about how this is about understanding the candidate as well as possible.
I've advised to actively reduce stress and make the individual as comfortable and welcoming as possible.
I've gone through my standard two interview process - a telephone interview followed by a face-to-face.
And I've talked about how I run those and the things I believe work well.
I've also touched on some practices that I believe are unhelpful - if not destructive - in the process.
And though the whole process I've reminded you of the need to sell your organisation.