Recruit And interview people. Do not just fill roles

Are you recruiting people, or are you recruiting to fulfil a role? Here are tips and notes about recruiting and interviewing.

Recruiting vs filling a role

Too many companies seem to want to fulfil a role and bring in a candidate who ticks the right boxes in theory; instead of hiring individuals who can do most of what you want now, learn how to do the rest, and can offer you more than you thought you needed and take you to a level you never imagined.

When you recruit to fulfil a role you might: assess against a checklist, objectively weight points against specific attributes, and when you employ, you then squeeze someone into a rigid set of responsibilities.

When you recruit people, you gain access to their full range of experience and potential, and allow them to overspill the role and benefit your team in ways you didn’t anticipate.

Start with the Job Description

Anyone who has written a job description before knows that it is hard. It is a painful and bureaucratic activity.

How tempting then, to simply re-use one that you’ve written before, changing a few words here and there, or having a standard template for your company/department/team and then fill in the blanks and expand a little.

If you are recruiting to fulfil a role then re-using a previous description or a template is a good way to start. After all, you don’t really want to attract someone flexible that can add value in ways you don’t expect, you want them to conform to the role description.

A job description I saw this morning fit this model perfectly.

The Job Title was “Test Manager”, but the job description was a copy and paste from a previous role because the first line of the description read “Test Analyst …”.

There was repetition of this throughout the job description. Clearly not much thought had gone into the writing of this spec, after all when fulfilling a role, you don’t need to attract the best person, you just need someone who matches the listed criteria.

Description mandated “at least 4 years in…”.

When recruiting for a role having the ability to reject people based on years of working in a previously titled role makes it easy to evaluate. Very easy to review CVs and reject them based on objective criteria without having to consider what people learned over those years in the role.

When asking for good communication skills, ensure that your job description communicates well. Having frequent spelling mistakes and poor grammar does not set a good standard of the communication skills that you expect. e.g. “Excellent communication ability, analytic and report to the manager” does not set a high standard.

The Job description is the first, and possibly only, view that the candidate has into your organisation. If it communicates poorly then the candidate can rightly assume that you communicate poorly, and do not value good communication, or that you have incredibly low standards.

Unfortunately I could go on and pull apart a specific job description, but there is little point. It is more important that we fix the description to recruit the best people.

Fix your Job Description

If you do want to recruit people then remember that your Job Description is not simply a statement of what you want, it is also a filter. People read the description and then choose to apply, or reject it. If you don’t put care and attention into the job spec, people who do care will reject it and you have created a filter that draws in people who care less.

The number of years is less important than the lessons learned, the skills gained and the experience built up. If you can specify what experience you want to bring into your team and workplace then that will serve you better than years worked. This also opens up more interesting and valuable conversations in the interview. “What did you learn…”, “Given your experience, how would you approach it differently…?” rather than “How many years in…?”

The Job Description is your chance to reveal your culture and values to the candidate, if they do not shine through then you run the risk of attracting someone who works better in a different organisational culture. If you communicate your culture poorly then someone who values that, will filter themselves out of the process.

You know what gaps you have on your team, or in your department:

skill set gaps
experience gaps
interpersonal communication gaps
whatever

In the job description, describe the problems that you think having those gaps has led to - phrasing them as solutions.

“You will help us automate the execution of a web application using Java to add acceptance condition validation during the build process.”

For a more detailed example, compare the following two statements:

“We are trying to move from waterfall to Agile and need people with previous experience of Agile who can work on teams to help improve the way we work.”
“Experience working with waterfall and agile methodologies.”

If your job description simply states what you want, rather than why you want it, then the candidate has no ability to infer a context from your statement e.g. How should someone interpret the second statement “Experience working with waterfall and agile methodologies.”

Do you do both?
Are you transitioning?
Do you actually know what these words mean?
Do you have a hybrid process?
How do you expect me to apply my experience?
What is the lack of experience leading to?

The first statement “We are trying to …” provides a context and implies that you need to have experienced waterfall, and agile methodologies, and know how to transition them. It also provides an indication of the challenges the role involves and is more of an attract statement rather than a filtering out statement.

A current trend, with the advent of Chat GPT, is to use LLM tools to generate portions of the job description. I’ve seen “written with the help of Chat GPT” as a badge of honour in some descriptions. Presumably, I’m supposed to read that and think “Wow, what a hi-tech and advanced company, using AI in the recruitment process”. In reality, I read that and think “Wow, what a lazy recruitment process, they can’t even be bothered to properly craft a job description”.

Attract the Best

To fulfill a role, make statements that can be answered “Y/N” and are easy to filter CVs through. This will not attract the best people to your role because they need to see that you understand why you are recruiting and can appreciate the value that they can bring to your organisation.

To recruit people, write your job description as a sales pitch which describes your environment, the challenges you face, and the gaps that you need help with.

To write job descriptions like this you need to more fully understand why you are recruiting someone in the first place.

I don’t recruit just to meet numbers of staff, I recruit because there are specific aspects of the work that I need to improve. And to do that, I need to understand my team, teams, or department well.

As a consultant, part of my work is helping managers understand what the gaps are, and how they can best fill those gaps. Also helping them shape the recruitment process to enable them to recruit the staff they need.

You want to attract the best, not have them reject you because your job description fails the test.

Recruitment Process

You have four main opportunities during the recruitment process to recruit the right person:

filtering in or out via the job description
reviewing the CVs and cover letter
interview over the phone
audition face to face

Using Job Descriptions to Funnel In

You want the job description to attract people with the flexibility to excel in the job. Most job descriptions I see, filter out people who can excel because they are so poorly written that they put people off, rather than attract them in.

A bad process filters out good people

A bad recruitment process can filter out good people.

Approaches that have caused me to drop out of recruitment processes:

multiple choice coding tests
take home coding exercises
writing essays about my background
creating presentations

All of the above mean a very formal process that does not factor in the individuality of the candidate.

I turned up for an interview and was asked to do a multiple choice coding test. Had I known this was part of the process I would have pulled out earlier. Immediately upon turning up at the company I was taken into a room, and left with a bit of paper and a pen for 30 minutes. I was finished in ten minutes and had to sit bored for twenty minutes. Then I had to wait for an additional twenty minutes as the test was marked, only to be told that I had passed “like they knew I would”. I wasn’t being treated as an individual human, I was being treated as a gradeable cog in a machine. The interview process was pointlessly bureaucratic and inflexible which didn’t create a favourable impression of the company.

I was consulting at a company that used online multiple choice coding tests as part of their filtering process, and they would only move forward with people who gained more than 80% on the test. I paid to go through one of the tests they used, in a programming language that I didn’t know. I achieved a mark of more than 80%. I suspect that my lack of knowledge meant that I was able to interpret ambiguity in the question in a way that someone with more experience might stumble and go “do you mean X or Y?” “well, it depends on the scenario, are we doing Thing A, Thing B, or Thing C”? I suspect the test filtered out people that were experienced, rather than filtered out inexperience.

I dislike take home coding tests. I usually drop out of interview processes that use them. Very often the team creating them haven’t actually done the exercise. Often the team creating them have more domain knowledge and underestimate how long the test will take. I’ve never seen any company that uses coding tests, look at the online portfolio of a candidate, which again means that the people coming through the recruitment process are not being viewed on the individual skills and what they can uniquely bring to the company, they are being evaluated as a homogenous resource.

Even though many of the above items are used to avoid bias in the recruitment process, I think they bias towards people who have time. These tests are harder for people to do if they have young children, or a current job that takes a lot of time, or a whole host of non-skill related responsibilities. If someone is actively looking for work and are faced with 3 or 4 hours of extra work for each application, that doesn’t feel like the most inclusive recruitment process.

I once pulled out of a recruitment process that required me to write an essay on my background and how well I did at school in science and maths. After more than 20 years of experience, I was being asked about Maths at school, rather than the 100+ projects I’d created on Github. That didn’t seem like a process that was designed to recruit experienced staff.

I’ve dropped out of processes that required me to create presentations and then present them in the interview. I could do a presentation. I’ve prepared and presented hundreds over the years, at conferences and the evidence is online.

Most of the time I drop out because I see from the process that the company is not interested in me as an individual. Ther are interested in a standarised process. The standardised process takes a lot of the work off the company and puts it all on the candidate. Most of the work on the candidate is assigned without the candidate even having spoken to someone at the company or identifying if the company is a good fit for them. I take the view that if the recruitment process is not a good fit for me, then the company has actively created the process to filter people like me out, and therefore I have to assume that I’m not a good fit for the company and drop out.

I don’t think companies even track the number of people who drop out of the process when they learn what it involves.

And companies can’t track the number of people who never apply due to their pre-knowledge about the process.

It is important to review recruitment processes for all the filter points that can happen and make sure that the company is aware.

Companies often say that they ‘recruit the best’. The reality is that they ‘recruit from the subset of people that comply with the recruitment demands’.

Ask for a Cover Letter

Many people do not tailor their CV to the job description. Primarily because most job descriptions are so poorly written and generic that there is no need. When you write a good job description encourage the writing of a cover letter which allows the candidate to re-use their standard CV, and write an interpretation of how they can fulfill your well-written job description.

The process should honour the time commitments of both candidate and employer. A template driven job description values the time of the employer because it was fast to produce, but dishonours the candidate because they have to spend time interpreting what you mean. Very often the expectation from the employer is a custom written CV to match their vague requirements - again this takes a lot of time. It is faster for the candidate to write a cover letter, and this provides you with more insight into how they have interpreted your role.

Review the CV to build a list of questions which you can use during the phone interview.

Interviews

Phone Interviews

Phone interviews are important because they honour the time of everyone involved.

No travel time or cost
Agreed time
Agreed duration
Expectation of preparation on both sides

As an interviewer or interviewee, a phone interview has the advantage that you can cut it short if it is obvious that there is a mismatch between the candidate and the role.

Use the phone interview to ask questions of the candidate about the CV, if the CV doesn’t describe their experience very well, then ask questions to find out what they learned and how they would approach the task differently.

Phone interviews are hard. They should be performed by someone with the requisite skill to understand and ask detailed follow-up questions based on the answers. This is particularly true if you want candidates to perform technical activities, the interviewer must know how to perform those activities well otherwise they may be misdirected by technical language.

Ensure that the candidate asks questions to help them decide if the role or company culture is a good fit for them.

No-one wants to waste time in a face to face interview for a candidate without applicable experience, or for a non-suitable role or culture.

Audition face to face, Interview over the phone

The face to face interview should be an audition. If you spend all the time talking then you have wasted an opportunity to see the candidate perform the job in action. Try to recreate activities they would do as part of the job. This means avoiding:

written questions “to test for knowledge” - if you require this, do this way before a face to face meeting
whiteboard coding challenges - have them actually write code
talking exclusively - this allows people who can ’talk the talk’ into your organisation, despite them not being able to ‘walk the walk’

When I am recruiting for testers, either for my own teams when working as a manager, or as a hired consultant helping companies recruit good staff, I audition based on the problems we want this person to help solve or the skill gaps that we perceive we have.

Interviews as Auditions

Recruiting for Exploring

If we want to recruit a tester with experience of testing web applications, interacting with them through exploratory testing and going deep into the technicalities of the application to expose problems and identify risk then I would:

sit them down in front of a computer where they can test the application
restrict the testing to a small subset of the application
provide a high-level summary of the functionality and a demo of it in use
pair with them as they test the application

If they are not used to explaining what they do as they test, then I would ask questions like:

what made you do that?
what objective do you have in mind at the moment?
etc. to help them verbalise their thought processes

I might even ask:

does that look right? asking about a particular observation on screen
etc.

Lots of etc. because this is an open-ended process where I want to gain an insight into how they approach the testing.

I also know that the audition setup is not how they would normally organise their work so I want to know what omissions we have:

How would you normally communicate the testing you perform?
Would you take notes? how would you take notes?
Are there any additional tools you would use for this type of work? How would you use those tools? How do those tools help you? What other tools can you use to do that?
Are you checking results in the system at all the places you would want to check them?
etc.

Then I would let them direct the action. If you were testing this for real:

What else would you need to know?
How would you approach it?
Are there any risks you would be concerned about?
etc.

Recruiting for Automating

If we have gaps around automating then I need to know if the candidate can:

identify strategies and approaches
read code
maintain code
improve code
write code
architect code

After a demo:

How would you automate this?
What do you think would be hard about automating this?
How would automating this help?

Show some code we have written to automate this:

How does this code work?
What does it do?
Does it do it well?
How might you write it differently?

Have some code that doesn’t work:

Does this work?
Can you make it work?
Can you now make it better?

Can you implement some new execution paths?

How would you structure the code to make it more maintainable and adaptable in the future?

Given how we have written this, and the tools we have used, are there any parts of our test process that this does not support?

Could we use this to test the system under load? Is that the best way to do this?

etc etc.

Make it Real

I used to use MS Paint as a ’test this’ application.

I had 2 charters:

A “risk identification tour” charter
A Scenario charter: “Function A” has changed - the existing automated tests have passed but it has a lot of internal dependencies - can you give it a quick once over and a quick regression of “sub function Y” and let us know what you find?

But… I’ve never worked on MS Paint. I never will. We don’t test applications like MS Paint. So it was a non-representative exercise.

As much as possible we want to see them in action, doing the stuff they would do in the real world.

So I’d rather test or automate the actuall applications that we work with and make the hands on sessions as real world as I can.

Similarly I’d never ask someone “How would you test this pen?” or “How would you test this chair?”.

Because I know that my response to those questions would not be favourable - “I’m sorry I thought the job description was testing web applications, not pens”. I’d feel as though we were wasting time and that I was being patronised. I’d react with scorn and feel my time was being wasted on ‘cute’ exercises rather than a serious attempt to see if I was a good fit for the company. I’d feel as though the company was not a good fit for me.

This might be more challenging for management roles that are less hands-on, but you can simulate scenarios or ask how they would handle specific situations, and how they have handled them in the past.

When you audition, you can very quickly see gaps in the experience of the candidate, and then you can decide if that gap is a blocker to hiring or something that you can work around.

Experienced Evaluation

I find it much easier to evaluate candidates with an audition process, after having filtered them out through a talking process over the phone. This also avoids the need for multiple face to face interviews which often serve to prioritise company time, above candidate time.

Throughout this process, it is essential that you have experienced people evaluate the candidate. It is too easy to talk the talk to someone that doesn’t know how to do the role, and it is too easy to bamboozle someone in an audition if they don’t know how to actually do the work themselves.

All of this is about helping your candidate make the best impression on you, and demonstrate their skills as an individual and the additional value they can provide. Rather than trying to fit them into a role based on what they say they can do.

Interviewing Nuances

Normally when we recruit someone it is because we:

have stuff we want them to do
have ideas of the ways we want them to do it
know why we want things done that way

But we often don’t put that in job specifications, because the people doing early CV filtering can’t filter on those items, because the people filtering lack the required experience necessary to draw the above out of a CV to identify the people that we might want to work with who can add value in our teams.

I try to interview based on the person, and I will ask questions around the stuff we want them to do:

how do they interpret what I have said?
have they done anything that they think is similar?
what did they learn from doing that?
what worked? what didn’t?
how would they do it next time?

There are no right answers, I have to interpret the answers based on my experience. I’m also looking to see what else this person can do, and determine if those experiences or thought processes could help us (perhaps what they offer is more important than the capabilities we were seeking).

A role based approach will not help you hire people who can add value beyond what you were looking for, or change what you thought you were looking for.

During the questioning I am building a model of this person and how I think they might fit into the team and do the tasks we want done. I ask questions to build this model. I want them to ask questions of me to question my model of the work and envisioned required capabilities.

I also have them engage in an audition, where I pair with them to:

do they type of stuff we want them to do e.g.
- maintain code that automates the application,
- review code to figure out how it could be better.
- test the system
- review the system to see what risks they identify
- explain the system and engage in an iterative Q&A session so they can build a model of the system and explain how they might test it

Rather than questions, I have samples of work and systems and I work with them or question them to see how they deal with the work and systems.

I might have a list of questions to prompt me during the interview to see if my model of the person covers these areas:

how does this person stay up to date?
what have they learned from their testing in the past?
what have they learned from automating in the past?
do they have absolute and rigid beliefs or approaches related to the job?
etc.

I generally don’t ask these as questions to them, these are questions to me, to allow me to check my model of the person.

I adjust the audition around the person based on the job, first by having them explore my model of the job and discussing how their experiences map to the model, and then a hands on practical audition for aspects of the role.