Skip to main content

Recruiting Software Testers… It should be easy, Right?

Recruitment, A process that I know is painful for the recruiter and candidate(s). So how do we get this right? How do we know we are asking the right thing to ensure any candidate is right for the job but also the role is right for the candidate? 1 hour/1.5 hours isnt a long time to make a decision.

After many exhaustive hours dealing with recruitment over the past 18 months or so I don’t believe I am perfect at it but I do feel I have learnt a lot about what I am looking for.

Stage 1, The Phone interview: 

This stage of an interview should be kept to a minimum, a brief discussion of experiences.

I generally use the phone interview to pick up on 5 key points:

 - Have they done any research on the company/role
 - Why they want to make this move
 - What methodologies have they worked with
 - Manual and automation experience
 - How they keep up to date with modern testing techniques

I want to ensure that they are committed to the application process, they have worked in a similar environment and understand the methodologies. Another key attribute I look for is confidence… this is so important!

Give candidates the opportunity to ask questions, depending on what they come back with will demonstrate how keen they really are.

Stage 2, Face to face interview: 

It’s important to facilitate a face to face interview with structure behind it, it’s easy to ask exhaustive questions, let’s be honest this is tedious for everyone involved. If we apply a standard structure it becomes easier to compare candidates.

Competency questions

It’s important to warm up with questions to understand why an individual has chosen testing, an honest answer like “They fell in to testing” isn’t a bad thing, they have still chosen to stick with it, ask them why and what motivates them?

Let’s find out if they have a specific pattern or model they follow, ask them to explain how they approach testing. I always like to find out about their current work and what challenges they have faced? And follow up asking how these challenges were overcome?

We also need to look at the candidate’s character. Being able to make a decision is a good attribute, but maybe if we turn that around and ask whether or not they have made a bad one and how they corrected this for the future?

How does the candidate deal with conflict? We all have to deal with that one challenging colleague that always contradicts you.

I’m always interested in what improvements they would make to how they work in their current role.

It’s obvious we need to determine a candidates testing skills too.

Have they any experience of test strategy or test planning?

How do they prioritise testing and what may influence decisions?

How do you know when to stop testing?

Do testers have a role in managing risk? What is it?

How do they approach testing if they were to be given a tight deadline?

There is so much more we could ask but I think this will give you a good indication.

Automation skills are generally hard to gauge unless a candidate is tested during the interview. We will look at this shortly.

An open question will give a good overview, have they automated their tests? If so, how? What tools are they using to automate their testing?

I’d always ask their opinion on what they believe is a good test scenario to build in to automation? And why they believe so?

As anyone would agree learning and improving is important. I like to understand how an individual drives their own personal development.

Find out what their ideal role is, this helps you understand what it is they are looking for in the move and whether or not this is something you can offer them.

I’d say 10 to 12 questions is probably enough but be prepared, if your anything like me questions bread questions! But this is fine, it just means you are trying to draw the best out of the candidate J

Practical tests

Practical tests are usually quite daunting for candidates, they are done to essentially support their claims. Keep it realistic and relevant to the role in which they have applied for.

Someone may have Selenium on their CV, this doesn’t always mean they have been consistently using it for the last 12 months. It could be that they used it 4 years ago and haven’t since… I believe it would be rather unfair to put this in front of them so ask the question to understand usage first.

They need to demonstrate the ability to learn, if they can do this then I don’t see much of a problem.

Never test somebody against a tool that they just won’t use in the role in which they have applied for. Seriously, what’s the point? Nobody gets anything out of this and let’s face it we don’t need to put a candidate in an unnecessary position.

Alongside tooling practical’s there are also other elements we can test, and that’s the mind-set of a tester… to me this is one of the most important practical tests.

Understanding what they would put in a test strategy is good, can we give them a scenario to work from?

Giving them a basic user story and allowing them the time to break it down in to testable scenarios is a great way to find out how their mind works!

It’s a great idea to see how they would apply testing in the real world. See how they would cope with questions such as:

How would you test a pen? Ask them to think logically…

The kind of responses we would be looking for are:

 - What kind of pen is it? A reed pen, a metal nib pen, a fountain pen, a ballpoint pen, a felt-tip pen, a rollerball pen or any other type?
 - Is it intended to be used only with paper or other writable surface too?
 - Who is going to use it? A student, a teacher, a writer, a poet, a doctor, a bus conductor, a mountaineer, a scuba diver, a desert dweller, an Eskimo from Antarctica or an astronaut?

There is loads of ideas on this website, give it a whirl!

Asking how they would test a brick is usually a good one J  same concept…

As a recruiter, there is one thing to remember! They have to impress us of course but we also need to sell the company/role to any candidate… The start of a good working relationship is a shared understanding of what’s ahead.

If you do anything different that I haven’t mentioned, feel free to get in touch.



Popular posts from this blog

My Testbash Brighton 2017 Notes

This was my second Testbash... if you ever get the chance in the future these conferences are a must!
I took copious amounts of notes from the 9 talks and tried to highlight my key takeaways here... hope they make sense but please comment if you have any questions :-)
Amy Phillips - Continuous Delivery
A survival guide to joining a fast paced environment/project…
Where does testing fit within Continuous delivery:

As highlighted, basically from start to finish…
There are lots of things we can do when joining a project that is using Continuous Delivery but one of the main points from this talk was to do your research! There should be an element of "Continuous" in every aspect of the project.
·Learning the ling, what's the difference Continuous Delivery, Continuous Deployment, Continuous Integration, Continuous design, Continuous Improvements etc.? ·Understand what your role in the project is going to be ·Understand the teams values, What's going well and maybe what the team p…

Is TestBash an Invaluable experience?

Over the last few years, I’ve attended four single track conferences at TestBash Brighton and Manchester. Most recently, September 2018 and April 2019.

One of the most common questions I get after the conference is, Was it worth it? Especially now given, I’m a contractor, and I attend at my own expense.

In short, Yes It’s definitely worth the trip!

That leads me into my question; does a single-track conference work for me, or could I get more out of TestBash?

Of course, there are pros and cons, some talks may not be as engaging, but this is no disrespect to the speakers, for me, it’s because I probably favour certain subjects and I’m pretty sure others will think the same.

Do I make the most of what’s on offer at TestBash? It pains me to say, No! I don’t make the most of the events leading up to and post the single-track conference so I could get more from the week.

TestBash offers master classes on automation. A full day of workshops. Test.bash() with talks on automation and technica…

The way we work shouldn’t be ‘Alien’ anymore, Should it!?!?

It’s been a good while since I have written anything (Mainly because I’m not that good a writer) but given my 16 months in the public sector I thought it was time… 
For a good number of years now the DevOps trend has given rise of buzzwords and methods aiming to speed delivery and it’s now an assumption of mine that most organisations are au fait with the term ‘Continuous Delivery’.
I was wrong…
Within the organisation that I am currently placed I believe I have a high-functioning collaborative team who work flexibly and in continuous cycle. We also involve the users which is a huge benefit to the development teams, but that’s not saying we get everything right 100% of the time! Teams must continue to learn and evolve to remain productive.
Our team work in one of several delivery groups and with this comes multiple challenges; Silos No single environment strategy lack of communicationsVaried ways of working.  And thats just to name a few, which is interesting when all delivery groups …