Graduate QA interview ideas

#1

hey hows it going.
(apologies if this topic was discussed earlier, searched but couldnt find any)

I would like to get some ideas on how people are getting around interviewing graduate QA candidates.
Currently we have something called the sink (wash basin) test in which the candidate describes various ways to test the sink - water pressure, hot/cold water, drain blocks etc

But is there any other way to see if the candidate at a graduate level has the QA mindset and is fit for the role

thanks

#2

Would you treat a graduate the same as a trainee/junior in terms of what you would ask and make them do?

For me, the thing with anyone brand new to a role is that they are sponges to learn, and just because they can’t think of all the tricks of how you would test a sink, doesn’t mean that means they wouldn’t be any good at testing.

What about pairing them with something you actually build/test, so you can see how well they follow directions, communicate, ask questions, depending on if they are driving or navigating.

#3

thanks Lee,
I guess with the sink test I was more referring to assessing the mindset
graduate/trainee/junior - ya anyone who is new to the role

Thanks for the last point “pairing them with something you actually build/test”

any other ideas most welcome.

#4

I use something rather like your Sink Test, and it tends to be very helpful. But I do also like to set the candidate up with a regular “testing interview” software problem and see how they go with it - usually it’s not as good as we’d expect from someone with experience (sometimes it is, and sometimes even better), but hearing how they think through the problem relating to something a bit more familiar and relevant to our work can reveal a big difference to that other, more abstract test.

Other than that it’s about a good interview, good team fit and lots of passion for testing as a career. We recruited for a junior or graduate recently, and the number of candidates who had put serious effort into becoming a tester without getting that first tester job role was amazing.

1 Like
#5

Hello,

I like your question and can’t stop myself to reply to you…

Actually I would like to share my first QA interview questions with you…I hope it would be helpful to you…

They ask me so many questions such as…

What is the difference between QA and Software Testing?
Can you explain the bugs cycle?
What things do you include in your test strategy?
Types of Software Testing? (My Favorite):wink:
Do you know Agile testing?

These are the questions, They ask me during the interview, So I would like to suggest you prepare simple kind of things…and Try to improve your QA skills

Thanks

#6

It probably all depends on what you want the graduate for. But if he is applying as a software tester, let him have a go at something like fixture finder or some other faulty software and let him describe what he finds. Have him describe a bug and how he would phrase it, if he would attach a screenshot etc. Then play a developer who doesn’t see this as a bug and have the applicant “defend” his bug.

#7

For my very first testing job (how I got the interview is a story in itself), the interviewer was a manager who worked in testing for a long time. He asked the following question:

“Our system does the following {describes system}. The problem we have is that for each country where the system is sold, the standard settings have to be different. These settings should work for about 20 countries, and there are dozens of settings. How would you test this?”

The actual answer I gave was, to put it bluntly, very wrong. But what I didn’t know at the time was that I wasn’t being judge on the answer itself, but how I reacted to the question. If I had started my answer with “This is how I would do it…” and then listed off a bunch of test steps, then I wouldn’t have gotten the job. Instead, I started asking questions, as I didn’t quite understand the context of the system. “How have we created testability?” “How have we tested it in the past?” “Can we modify the settings?” “How much time does it take to do the tests now?” “Can we automate portions of the testing?” … and so on. We talked for about 20 minutes just to get to the wrong answer. (Interesting side point, my answer had mostly to do with automation, and what we eventually did was scripting combined with increasing testability and observability).

So here’s what I liked about that question and process.

  1. It was about a real world problem. Asking about a sink would have been fun, but would still feel fake.
  2. They used it to judge my process for getting answers rather than the answer itself. A brand new tester couldn’t possibly know enough to get the correct answer on the first shot.
  3. They used it to judge my interaction with them as a team. If I didn’t ask my own questions, then they might have doubted my ability to ask questions (let alone the right questions) when it really mattered in the context of a project.

So my advice would be that most people who make it as far as the interview would know enough to test a sink/ coffee cup/ pen/ etc. And most people who make it as far as the interview would be willing to learn new things. The trick to the interview would be in finding out if they-or-their-style is right for your team.

4 Likes
#8

We ask a similar question, but we use a blender instead of a sink. Depends on the types of projects you have, but we also ask how they would test a simple website, just text and pictures, then slowly add complexity as they work through it (“okay v2 has a form, that when submitted leads to a video”, etc).

My favorite one is “have you been in a situation where you knew you were right, but got told not to worry about it?” On our team QA needs to have a voice and be able to push back when devs (and sometimes product) underestimate the scope or severity of the issue.

1 Like