Author Archives: norry

Pairing with your recruitment manager

As an industry we are getting much more practiced in the art of pairing with various roles or specialties across our engineering teams (Developer, Scrum Master, Tester, Product Owner, User). The benefits have been well documented by Lisa Crispin, , James Bach, Katrina Clokie, and many others.

But what about pairing with your recruitment or hiring manager?  What benefit could that have to either of you?

I started doing this with my recruitment manager a few years back and wanted to share some examples of areas in where we paired and what we discovered along the way.

Exploratory Testing

Yes really!

When we first started on this journey the recruitment manager joined me over the period of two weeks while I was testing a feature. He joined in a number of exploratory sessions to experience first hand how we worked, the questions we asked, and the challenges we faced.

What they learnt: That testing wasn’t at all what they though it might be

How it helped: They gained a greater understanding of some of the work that we do and were better able to evaluate potential candidates based on that experience.

Writing job adverts

We wrote the job adverts together, sat side by side. Removing the potential review cycle sometimes observed by sending documents back and forth.

What we learnt: We gained a better understanding of the language that we liked to use and how our context differed. I wanted a job advert that I would apply for and they wanted a consistency with the other job adverts we already had.

Questions we asked each other: Why does that sentence matter to you? Why does it matter that’s its written in that style? or that format?

How it helped: We ended up with a job advert that we were both happy with, so much so that we repeated the process with other roles.

CV Reviews

Instead of emailing CV’s back with a reason for rejection we worked though a bunch of CV’s together. They would start with a CV that they felt I would like and we would repeat until they were much closer at understanding what I was looking for and why. We also reversed the process by starting with CV’s they felt I wouldn’t be interested in.

What they learnt: What I care about in a candidate and why.

Questions they asked me: Why does that matter to you in a CV? I thought this was a poor candidate based on this CV, what made you interested in them? I thought this was a perfect CV, how come you were not so keen?

How it helped: That identifying a potentially good candidate is much more than a keyword search and some great candidates just have poorly written CV’s.

Telephone Screening

This was much more of a listening, and questioning exercise for the hiring manager.

They would be a silent partner while I talked to potential candidates on the phone. I had a basic model of what I would talk to a candidate about but would often deviate from the model if I discovered something worth exploring with a candidate (much like testing).

What they learnt: They could see how I used a model to provide consistency to my questions for various candidates but also the value in having a freedom to explore. By being a silent partner they could also begin to understand ‘why’ I deviated sometimes.

Questions they asked me: Why did you explore that area of a CV for one candidate and not another? Why did you not ask that particular question to a candidate?

How it helped: We are now at a stage when if the hiring manager says I will really like someone they are usually right.

Technical Interviews

On a few of our technical interviews we would ask the candidate if they didn’t mind the hiring manager joining the interview in an observation role.

What they learnt: Our testing interviews are much more about the conversation than a question and answer session.

How it helped: To develop a deeper understanding of the people we would like to hire and importantly how we interact with them.

Booking interviews

I sat with the hiring manager while they went through their process of booking in interviewers. This would normally also involve asking me for suggestions  as we hire into a number of different teams with different requirements.

What I learnt: Booking interviews can be a difficult job for the hiring manager as they have to coordinate a number of varying peoples calendars with that of the times the candidate can come into the office. Couple that with the fact it wasn’t always the same people involved and I would change the people based on a number of factors. They didn’t know these factors!

Questions I asked them: How can I make this process much easier for you? What additional information can I provide?

How it helped: I’d always known this was tricky for them but not really appreciated it until I’d sat with them as they went though their process. I ended up producing a model of how I choose people for interviewing. They could then apply this to make their choices easier and without having to check with me for each candidate. It looked something like;

If interviewing for team ‘awesome’ then choose Jane and Mike, and either Claire, Karen, or Peter. If Jane can’t make it choose Harry, if Mike can’t make it choose Laura. And so on…

Feedback to candidates

Historically feedback for candidates would have been made by the hiring manager based on comments from those involved in the interview. We still do that now, but the way that we construct that feedback has changed since I sat with the hiring manager one day while they gave our feedback to a candidate. The feedback we had been giving wasn’t that helpful, and it wasn’t until I heard it repeated, and the subsequent questions, that I realised it.

What I learnt: To construct my feedback in such a way that the hiring manager could use better.

How it helped: To bridge the understanding gap between what I intended to be heard and what I actually conveyed.

So what did we learn together?

  • I learnt that hiring testers is hard. In fact hiring anyone is hard when you don’t work in that role.
  • They learnt that testing is a complex and varied activity.
  • I learnt that it’s harder for people to understand my thinking patterns if I don’t provide them with a model first, and then show them how I break that model.
  • They learnt how to ask smarter questions for testers
  • We both learnt more about each others role
  • We both learnt how we could present information in such a way that was easier for the other to understand.
  • We both learnt how to communicate with each other better.

And importantly we both learnt that pairing isn’t just something that is valuable only to those members in your immediate team or department.