Made by Many are going through a phase of growth and the number of projects we have meant that continuing as the lone QA was no longer an option. Because QA is part of our core offering — and how important it is to be involved in projects from the very beginning — we recently decided to hire a junior QA engineer at Made by Many. My task seemed simple: find and hire a suitable candidate who could pick up our QA methodologies and process.
Some might say this is a relatively simple task: surely there are plenty of people who would be interested in the opportunity to start a career in testing/QA, from recent grads to people looking for a change in career. However, it proved somewhat harder than expected...
Finding the right talent
Although most agencies would have opted to hire a seasoned QA to get up to speed quickly, we decided to look for someone who had little or no prior experience. Our reason was simple: we didn’t want someone who was already set in their ways when it came to testing and QA. At Made by Many, our approach to QA is different: we place the utmost importance on the end-user and their experience.
We wanted to mould and shape a junior to champion the end-user and to be able to constructively voice their opinions and views on how to improve process. We wanted someone to not just perform functional tests to see if a feature works, but to ensure that the feature actually delivers the best user experience too.
After much deliberation with the engineering team about what the role would entail, we wrote a job description and posted the job advert.
We used BeApplied, a recruitment platform that helps businesses remove bias during the initial applicant evaluation process. For this to work, we had to write a number of questions that would probe the mind of the candidate, enabling us to understand their working knowledge, how they break down problems and come to workable conclusions. BeApplied distributes the anonymised answers to a broader team, who evaluate and score them based on defined criteria (which are written along with the question). This allows us to involve more people and perspectives in the recruitment process and helps us to reduce the unconscious biases we all have.
Almost immediately the applicants began working through the questions and uploading their CVs. One thing that became very apparent was that many applicants seem to think employers are looking for employees who “stay late”, “work through lunch” and “bend over backwards to complete a task.” It was quite a shock to find that candidates still think overworking would be a massive benefit to their would-be employer! We all understand that sometimes in life there is a necessity to work late, but this should really be kept to a minimum. When it does happen, it only really highlights poor time management and/or a lack of communication of the problem or task at hand.
Once applications had closed and we’d processed the anonymous answers, we could clearly see the applicants who best matched the mindset we were looking for. Only now did we look at the applicant CVs, ultimately arranging telephone interviews.
I was in for another surprise during the phone interviews. I understand that applicants are keen and want to show an array of skills in a short space of time all through a phone conversation lasting 30 minutes. However, it soon became apparent that applicants were dropping in many buzzwords, such as agile, automation, exploratory testing... the list goes on. All very relevant to the role, but bearing in mind that this was a junior position, I wouldn’t expect an applicant to be an expert in these areas. Hearing the candidates using these buzzwords — when they obviously didn’t know what they were — was frightening. The moral of the story is: don’t use terms unless you have some semblance of an idea of what they mean!
This leads me on to what I was looking for. The answers to the questions we set were designed to give us an insight into the applicant’s problem-solving skills, analytical thinking and how they would manage their time effectively, all of which are directly related to the role of junior QA.
What were we looking for?
I wasn’t looking for amazing academic history nor a computer science qualification (I don’t have one). I wanted passion: a passion to learn, a passion to understand, a passion to discover QA, a passion for products and apps — buckets of enthusiasm with a sprinkling of communication skills thrown in for good measure! If you are truly excited about a role/career, learning new skills and techniques is a breeze, and the desire to immerse yourself in a sea of information is appealing.
This also threw up other bumps in the road with some good applicants only really applying for the role as a bridge into the career they really wanted, for example design or product management. This became obvious through the lack of passion for the role and, digging a little deeper, you could uncover their desire to want to move into their career of choice. Now, this I found difficult to come to terms with. Did these applicants think that QA was kind of easy and even a half-hearted approach would lead to success and a move into their desired career path? Maybe I’m overreacting here, as I have forged my career through passion, hard work and the desire to learn — and I love the role I’m in.
In conclusion, junior positions — especially ones not requiring previous experience — are pretty hard to recruit for. My advice is to look for candidates with passion and enthusiasm, the desire to learn more and to discover the art of being a QA. In my opinion these are far more valuable attributes.
Ultimately, the process worked. We hired a junior QA who has all the qualities we were looking for and who is currently on the road to becoming an awesome, fully-fledged QA engineer!
Marian came on board with little knowledge of QA and her only experience was working as a voluntary tester on a games platform. Since starting, Marian has hit the ground running, learning the hard and soft skills required to be a successful QA. These include but are not limited to Agile, exploratory testing, web and mobile testing and embracing our QA culture.
—The no-longer-lone QA :)
Tools embody working practices. New tools can disrupt working patterns and foster practices that overcome organisational inertia caused by routine and ing...
Designing to learn requires a shift in thinking. It means approaching user research with an open mind and a willingness to hear and act upon fresh perspec...
As part of our series on Employee Experience we explore what really makes someone stick with their job.