To keep the balance you have let some dark in

It might sound a bit Sith, but playing your best traits is not the only thing that will land you that QA job. Usually, especially when the interviewer is not a QA person (which probably makes him / her a development leader of sorts), triggering one of the common fears is an immediate way to get disqualified. If you can address these fears (even when not specifically asked about it), you gain some very helpful points.

Tell me what’s *ahem* bugging you

 

To understand what is not being said during your interview, we will need to delve into the developer psyche. Not too deep, since unlike the QA counterpart, it is a disorganized mess. But with me as a guide, you will be able to escape madness.

 

This peg does not seem to be round

 

First thing to understand is that your interviewer does not really understand QA. That’s OK, it’s not her job. She knows she needs a QA person, but not really sure how it works. Imagine your feeling when interacting with a specialist that you find believable, but uses technical jargon that you will never understand. Now imagine you need to interview that person for that very same job, (that you don’t really understand). If you find the intricacies of mortgage, insurance or taxes baffling, imagine having interviewing and comparing agents of these specialties. Some development managers attack this issue by simply interviewing the same way the interview developers. Some try to create some generic logic meter tests, and the rest will simply insult you by treating you as a less intelligent version of a developer, mostly by creating some “QA test” that only shows what THEY know about QA (which means it is a very ineffective test).

 

I need you, I don’t need you, and all of that jiving around

 

Here comes fear #1: “I, as a development manager, am aware that I need a QA person to improve the quality of our product, which means that the person will find many faults in the existing product and processes. I, as a human, don’t want my faults to be thrown at my face, made visible to all (including higher management) to see”.

This is nothing new. This is the very same reason we all hold off going to the doctor, because we know something is wrong, and prefer to live with it for a while, and avoid the official recognition of our medical state.

How to negate this fear and get yourself hired:
Be friendly, use a positive language. Describe how you helped to make things better, and avoid insulting the profession of software development. Stories about finding issues and correcting them before deployment are good. Stories about how you got half of the developers fired by mailing a bug report to the CTO – less so.

 

Splintered reed

 

Fear #2 – “If the QA will not be 100% reliable, I will not be able to sleep at night, and probably end up deploying bad code to production, making me look bad”.

This is actually a very good point. If you cannot believe your QA when you ask if something is tested, or if something is production ready, then there is no reason to keep paying him. No one can test everything, no one can find all issues in the tested code, but one thing should always be treated as true – your QA person tells you the truth.

How to negate this fear and get yourself hired:
First, if for some reason your are not a reliable person, pick another profession, or work on yourself first. Given you are a very reliable person, make sure you do not accidentally trigger this fear. It’s not easy to demonstrate your amazing reliability, however it’s very easy to break the spell. Make sure that you can back up everything in your CV. Don’t imply you have work experience with something you don’t have actual work experience with. Don’t say anything you cannot back up. Avoid exaggerations, since someone might take them literally. If you are asked about traits that make you good at your job, mention that you are reliable. Even if you are not asked – let it be known that you think that being reliable is the most important trait.

 

Disruptive (in a bad way)

Fear #3 – “Introducing a person whose job is to find fault in the work of the developers will result in disruption of the teamwork, and will lead to bad blood, and finally reduced productivity”.

Again, good point. Being a people person is a bit much, but a QA should have one people skill mastered – communicating issues found in a non disruptive way (read more about it here). This is  a common fear, and I remember encountering it whenever I was interviewed for a job.

How to negate this fear and get yourself hired:
Make sure you work in the discussion the lessons learned in this post (The first API you should learn). In short, you should demonstrate that you give a lot of attention to communicate issues found in a non disruptive way, based on your experience and people skills.

 

Do you know of another common fear that can be used as a secret weapon in your QA interview?
Add it as a comment, and help your QA sisters and brothers to get employed!