Recently, I had a task to hire new members to the testing team, and 2 positions were opened: Middle QA and Junior QA. Let’s take a look at the Junior position.
The selection consisted of 3 stages:
The vacancy was looking for a candidate with zero experience, but a good theoretical base. I know that many people want to get at least some first job for the sake of experience, without really filtering projects/companies. This initial stage had the task of writing a checklist for one of the product web pages.
Initially, when I was thinking over this task, I introduced it with the aim that when applicants came for an interview, there was already an understanding of the product that they would have to work with. But in the end, I got more than I could expect.
Out of more than 20 reviewed responses, I highlighted the main errors, even though they overlap with each other, brought them out separately. In order to have a successful junior qa interview make sure you keep in mind the following steps.
If the task is to draw up a checklist, make it exactly:
In this case, “more” does not mean “better”. This shows that you do not know your way around terms and cannot solve the most basic problem. Accordingly, you get a refusal.
I perfectly understand that the QA position implies improving the quality of the product, but:
I avoid companies that give us the task of finding bugs in their software. In this case, you do not go through the selection stage, you already work as QA, only for free and without any further guarantees.
Going back to the analysis. Yes, it may sound strange that finding bugs for QA is a mistake. But in this case, it was not in the assignment. Especially writing bugs found in IE is bad manners. Thus, even those candidates whose CVs I liked were eliminated.
If earlier I was skeptical about different initial courses on testing, because I believed, and still think, that it takes a couple of weeks to google the basic definitions and understand them. Now, the certificate of completion of any of the courses in the CV gave me more confidence that the interviewee would be able to tell about, for example, software testing levels.
There were only 15 questions, and there were none that you couldn’t find out about by googling “Questions at the interview for the position of a tester”. But many could not clearly answer even half of them.
I also gave a test of 15 simple questions taken from the training at ISTQB, where, with 8 correct answers, this task is considered successfully completed. Here it was important to see that the interviewee knows their way around the theoretical part, which was not included in the oral interview.
Leave an application and get a free consultation from our manager.
As a result of these two stages, there were 2 candidates suitable for the vacancy. One of them turned out to be very knowledgeable in technical subtleties which made the second interviewee look not that good. But I had a suspicion that it would not be easy to work with him. Experience has shown ─ with good brains, but a bad temper, work will go slowly.
Therefore, we decided to introduce the next stage.
I searched through a bunch of articles and tried to find some kind of test. I found the test, passed it myself. I was convinced that it reflects the real picture closely enough, but I was not sure that the answers would be given honestly. As a result, it was given as an auxiliary tool.
I began to recall my own experience of conflict solutions, which have accumulated enough over 4 years of work. I made 18 questions, even rather a description of situations where, by the totality of answers, it became clear how easy it would be to communicate with a person.
Imagine that you have a conflict with one of the programmers, and the next day the manager gives you a test of a feature that this programmer was developing. The described requirements are not enough, you need to contact them for information. How will you behave in this situation?
So, the interviewee with excellent hard skills did not even try to approach this developer and did not report this problem to the manager. “I’ll check it as I see it’s as necessary,” he replied, a person who is going to the position of Junior QA.
In general, the imbalance in soft skills between these candidates was huge, and soft skills were my preference. And, after a while, I can say that I was right.
When they took another Junior to the team, I decided to get rid of the test based on ISTQB. I concluded that at the stage of the conversation, the level becomes clear, and the tests confirm this. But I added more questions on software, so as not to conduct second a face-to-face interview, but be able to draw a conclusion as soon as this or that candidate is suitable.
For those who are horrified by the described “exam”: the article lists the main points which I think are worth paying attention to as I did not intend to retell the interviews with each candidate in detail.