Interview - QA Engineer

PenguinForce

Hi, I am going in for an interview for a Graduate QA Engineer position on Friday. I am looking for some advice on how I should prepare for this and also what I should expect.

Thank you.

seamus

Look at the job spec, make a note of the key experience or qualifications that they're looking for and do some research.

Take 4 hours out of your day, and read this wiki article, including any branch articles which seem interesting or relevant.

http://en.wikipedia.org/wiki/Software_testing

You're going for a graduate position so they don't expect you to have any practical knowledge, but if you can discuss the difference between UAT and Unit Testing, even at a high level, then you're already a head above most of the other candidates.

The key to a good interview is not rattling off stock answers to mundane questions. It's about showing enthusiasm for the main topics that the role involves.

One question will come up which is, "What attracts you to the job?". This is actually two questions in one and the answer to neither is "the paycheque", because that's a given. The two questions in this are, "What attracts you to our company?" and "What attracts you to the role of QA Engineer?". Consider them both honestly and give honest answers. They may be one and the same, you may be drawn to being a QA engineer in that company because of what they do, but otherwise you wouldn't be caught dead as one. But either way, just have a think about it, so you can answer the question without much hesitation.

PenguinForce

Thanks for the reply. I am looking over some sql and software testing articles. I am getting quite nervous :P

Ray Palmer

Don't be nervous. While the above is good general advice I will add some more specific stuff about testing.

You are not there to identify every fault: Testing is a task to reduce risk and identify areas with potential problems.

Repetitive nature: You will be doing the same things over and over again. Let them know you are aware of this. Good to say "I hope to learn some automated testing to reduce this but I understand it is a big part of the job"

You are not the guardian of releases: If there is a bug there and you believe it will adversely effect the client/customer your job is not to stop the build just let people know. They make the decisions on releases you just let them know the risks

Good with people : Your job will involve telling people they missed something, programed poorly or didn't do the right thing. People don't like this and developers can be very defensive of their work. You have to be able to this in a friendly non confrontational manner. You may also have to deal with UAT people who will have very little technical knowledge. That is two big extremes and you will be talking to both within seconds of each other and sometimes at the same time.

Investigation: When testing you will find issues. Saying it is just a bug and sending it back to development is not what a QA engineer should do. Investigation of what the bug is and what parts are working is an important part of the job.

If you relay this information it would show you have an understanding of the true nature of the work rather than the text book definition. There is more but it should be enough to be useful and also give you an idea if you even want to do it.

PenguinForce

Ray Palmer wrote: »

Don't be nervous. While the above is good general advice I will add some more specific stuff about testing.

You are not there to identify every fault: Testing is a task to reduce risk and identify areas with potential problems.

Repetitive nature: You will be doing the same things over and over again. Let them know you are aware of this. Good to say "I hope to learn some automated testing to reduce this but I understand it is a big part of the job"

You are not the guardian of releases: If there is a bug there and you believe it will adversely effect the client/customer your job is not to stop the build just let people know. They make the decisions on releases you just let them know the risks

Good with people : Your job will involve telling people they missed something, programed poorly or didn't do the right thing. People don't like this and developers can be very defensive of their work. You have to be able to this in a friendly non confrontational manner. You may also have to deal with UAT people who will have very little technical knowledge. That is two big extremes and you will be talking to both within seconds of each other and sometimes at the same time.

Investigation: When testing you will find issues. Saying it is just a bug and sending it back to development is not what a QA engineer should do. Investigation of what the bug is and what parts are working is an important part of the job.

If you relay this information it would show you have an understanding of the true nature of the work rather than the text book definition. There is more but it should be enough to be useful and also give you an idea if you even want to do it.

Thanks for the advice

Mr. Loverman

Ray Palmer wrote: »

You are not the guardian of releases: If there is a bug there and you believe it will adversely effect the client/customer your job is not to stop the build just let people know. They make the decisions on releases you just let them know the risks

Heheh. In an ideal world Ray.

What happens in reality is this:

Management will ask you can they release. You say "quality is still bad". They ask why. You squirm as you try very hard not to ruin your relationship with the BAs and developers. (Probably the specs were vague and incomplete, and the developers didn't care / didn't do a good job, and the QA time was eaten up by longer development time and poor quality, and the company don't understand QA, etc.). They then ask again "do you think we can release?". You try to explain you just report quality, it is not your job to decide whether you release or not. They will then say but you are accountable for quality. So you are forced to say "well if I'm accountable for quality we can't release". They then get pissed off because your decision will affect their bonus, so they apply a lot of pressure on you to release. They just want you to take the fall if things go tits up. Eventually you compromise (no choice) and release a substandard product. Bugs are found. Management are angry. You try to re-explain you just report quality. You can't actually create quality. You might even try to get them to give you more power so you can better control the entire software development process. They won't give you the power, the developers will continue to get away with their bare minimum work standards, and everyone will think the QA team are causing lots of bugs.

It's an utterly thankless job, misunderstood by management everywhere. I would advise people to think long and hard before entering QA as it is hard to break out of once you're in it. If you do enter QA, try to become an automation engineer as soon as possible. The money is good, it's politically very powerful, and everyone leaves you alone.

All being said, if you're smart and are the type of person who doesn't care, you can have a pretty easy life in QA. There are a lot of slackers working in QA and they don't get fired.

PenguinForce

Just an update. Did the second interview last Tuesday with the manager and now just waiting for a reply. The manager was really nice, I think it went well but not going to have high hopes as you never know what they actually think. Only thing I know was from my friend in the company saying to me that the four people that interviewed me on Friday liked me.

Didn't really got asked anything technical, seems like they want to know how I will fit into the team. The manager said it will take about a week to a week and a half for a reply. He also told me he doesn't have the final say in hiring process and that others have to agree as well before the final decision is made.

My friend that is in the company applied last year got the job 2 weeks after his interview. Hopefully I will get a reply if at all, this wait is killing me :P

Ray Palmer

Mr. Loverman wrote: »

Heheh. In an ideal world Ray.

What happens in reality is this:

Management will ask you can they release. You say "quality is still bad". They ask why. You squirm as you try very hard not to ruin your relationship with the BAs and developers. (Probably the specs were vague and incomplete, and the developers didn't care / didn't do a good job, and the QA time was eaten up by longer development time and poor quality, and the company don't understand QA, etc.). They then ask again "do you think we can release?". You try to explain you just report quality, it is not your job to decide whether you release or not. They will then say but you are accountable for quality. So you are forced to say "well if I'm accountable for quality we can't release". They then get pissed off because your decision will affect their bonus, so they apply a lot of pressure on you to release. They just want you to take the fall if things go tits up. Eventually you compromise (no choice) and release a substandard product. Bugs are found. Management are angry. You try to re-explain you just report quality. You can't actually create quality. You might even try to get them to give you more power so you can better control the entire software development process. They won't give you the power, the developers will continue to get away with their bare minimum work standards, and everyone will think the QA team are causing lots of bugs.

It's an utterly thankless job, misunderstood by management everywhere. I would advise people to think long and hard before entering QA as it is hard to break out of once you're in it. If you do enter QA, try to become an automation engineer as soon as possible. The money is good, it's politically very powerful, and everyone leaves you alone.

All being said, if you're smart and are the type of person who doesn't care, you can have a pretty easy life in QA. There are a lot of slackers working in QA and they don't get fired.

That maybe reality for some people but that is because they haven't made their role clear to others. QA is not accountable for quality they report on what the quality is the developers are accountable for the quality as they make the stuff. If it misses business analysis matching user requirements that is again not QA. QA have to say where it fails.
If you are able to say where and what is wrong nobody can be annoyed with what you are doing. If you are worried about relationships and you can't do this without somebody freaking out then they have the problem are you are being rude to them.
If you manager is blaming you for missing a deadline then they need to be told you have no responsibility for that unless it is delayed due to test estimates being wrong. If something goes wrong after going live you should have spotted you maybe responsible. As QA you can be mislead by documentation.
If you are in a company as you described I would leave as that is a bunch of people failing to act like professionals and put responsibility in the correct place. I have been there and you either leave or you make your position 100% clear with agreement from the manager or PM. If they think differently they are simply wrong so there is no point sticking around as you will be blamed for everything. There are elements of give and take but blaming anybody is rather foolish the idea is you keep trying to prevent faults and it all you can do is "try" and generally reduce issues.

LuckyLloyd

PenguinForce wrote: »

Just an update. Did the second interview last Tuesday with the manager and now just waiting for a reply. The manager was really nice, I think it went well but not going to have high hopes as you never know what they actually think. Only thing I know was from my friend in the company saying to me that the four people that interviewed me on Friday liked me.

Didn't really got asked anything technical, seems like they want to know how I will fit into the team. The manager said it will take about a week to a week and a half for a reply. He also told me he doesn't have the final say in hiring process and that others have to agree as well before the final decision is made.

My friend that is in the company applied last year got the job 2 weeks after his interview. Hopefully I will get a reply if at all, this wait is killing me :P

I started as a QA Engineer with absolutely zero technical experience and my interviews at the time generally kept away from technical stuff. Most things can be learned on the job in my experience. It's really important that people are positive and open minded and communicate well. After that, a QA Engineer job can be a gateway to a long career. Best of luck, and keep the chin up if it doesn't work out. The experience of doing the interview will stand to you.

PenguinForce

Haven't posted in a month but the company that I interviewed with offered me the position few days ago after another interview They haven't told me when I will be starting but I will be on probation for six months.

Ray Palmer

PenguinForce wrote: »

Haven't posted in a month but the company that I interviewed with offered me the position few days ago after another interview They haven't told me when I will be starting but I will be on probation for six months.

Good for you.

Everybody does 6 months probation so I wouldn't worry about that.

InReality

In my last job the QA Manager was being asked to reduce known bugs serverity so a release could go ahead.

She refused. Although she got some stick from some managers she got praise from others and got a promotion a bit later.

I think if you try and keep everyone happy , i.e developers , managers etc I think you just end up stressing yourself.

macnug

Just an open question here in regards to QA roles in general, do you have to have a completed bachelors degree to get an interview? Im doing a part-time IT degree in which I can exit with a diploma soon or go onto do the bachelors which would take another 2-3 years, do you think I could go for a role like this while still in college or is there too much competition from graduates?

PenguinForce

macnug wrote: »

Just an open question here in regards to QA roles in general, do you have to have a completed bachelors degree to get an interview? Im doing a part-time IT degree in which I can exit with a diploma soon or go onto do the bachelors which would take another 2-3 years, do you think I could go for a role like this while still in college or is there too much competition from graduates?

The job description for my graduate QA position requires a Computer Science Degree but I'm pretty sure other companies take in different qualifications as well.

The company that interviewed me said they've interviewed way over 100 people and they are only hiring 10 graduates. But most people that interviewed just say things like "just try to get my foot in the door" or "they want to get into development role through QA" and they don't like that.

macnug

PenguinForce wrote: »

The job description for my graduate QA position requires a Computer Science Degree but I'm pretty sure other companies take in different qualifications as well.

The company that interviewed me said they've interviewed way over 100 people and they are only hiring 10 graduates. But most people that interviewed just say things like "just try to get my foot in the door" or "they want to get into development role through QA" and they don't like that.

Were all those 100 or so graduates? Yea Ive heard not to say about the development thing lol.

Mr. Loverman

I have interviewed probably over 100 people for QA roles.

Here's a question nearly no one can answer satisfactorily:

Why do you want to work in QA?

You might be asked it. Have an answer which makes some sort of sense...

Cravez

macnug wrote: »

Just an open question here in regards to QA roles in general, do you have to have a completed bachelors degree to get an interview?

I'v been doing a QA role for 2.5 years. Don't have a degree nor did I have experience prior to the role (they did originally ask for a Degree however). I was in the company in a different capacity prior to the role and got on the job training when hired.

I think the most important aspect of QA is having good technical and business analytic skills for writing up specifications, test scripts and also identifying issues and ideas to resolve them.

It depends on the QA role however, some testing is either Black or White box testing so for some roles Coding knowledge is required/advantageous and others it is not.

Generally from my experience of most Employer's or Agencies hiring for these roles generally want people to be fully focused in QA, but they've also said that those in the job tend to generally not stick with it (3-5 years max) and move onto other roles such as development etc.

macnug

Mr. Loverman wrote: »

I have interviewed probably over 100 people for QA roles.

Here's a question nearly no one can answer satisfactorily:

Why do you want to work in QA?

You might be asked it. Have an answer which makes some sort of sense...

Yea its not an easy question to answer because if you are using it as a stepping-stone to another career (which is not abnormal in other industries but for some reason in IT its frowned upon) and answer it honestly like what PenguinForce said, you might not get the job. At the same time if you say what the interviewer wants to hear you might sound a bit fake.

I'm not looking at it as a stepping stone though, it really does interest me as I find fault finding/trouble shooting very satisfying, id be lying if I didn't admit the pay and conditions are pretty attractive too (although probably taboo to say in interview).

macnug

Cravez wrote: »

I'v been doing a QA role for 2.5 years. Don't have a degree nor did I have experience prior to the role (they did originally ask for a Degree however). I was in the company in a different capacity prior to the role and got on the job training when hired.

I think the most important aspect of QA is having good technical and business analytic skills for writing up specifications, test scripts and also identifying issues and ideas to resolve them.

It depends on the QA role however, some testing is either Black or White box testing so for some roles Coding knowledge is required/advantageous and others it is not.

Generally from my experience of most Employer's or Agencies hiring for these roles generally want people to be fully focused in QA, but they've also said that those in the job tend to generally not stick with it (3-5 years max) and move onto other roles such as development etc.

Thing is, I think I have good technical skills considering im not finished my degree yet (as I do a bit of studying outside of college) and I think i could demonstrate them well if I get an interview, but im just wondering if a diploma is enough to get past HR.

Mr. Loverman

macnug wrote: »

I'm not looking at it as a stepping stone though, it really does interest me as I find fault finding/trouble shooting very satisfying, id be lying if I didn't admit the pay and conditions are pretty attractive too (although probably taboo to say in interview).

There's an easy way to prove the above. Sign up for one of the open source test teams (e.g. testing Firefox) and mention you do this as a hobby.

That alone will really impress the people interviewing you. They'll be thinking, finally, someone who actually likes QA.

macnug

Mr. Loverman wrote: »

There's an easy way to prove the above. Sign up for one of the open source test teams (e.g. testing Firefox) and mention you do this as a hobby.

That alone will really impress the people interviewing you. They'll be thinking, finally, someone who actually likes QA.

Didn't realise they had dedicated test teams for open source projects, thanks for that.

PenguinForce

My job got back to me through email for two references on Wednesday even though they've already given me the offer. I know one of them already completed the company's reference form and sent it back today and told me they gave me a very good reference. But Im not sure if my second reference which was my final year project supervisor did it yet.

I've asked for his permission last year as a reference to put on to my cv before my exams and he said its fine.I emailed him today to see if the company has contacted him and he has yet to reply to me.

Should I be worried if my project supervisor haven't responded or might not respond to the company that contacted him? The company already gave me a start date and they've booked a medical for me for Tuesday. Although I still havent received my contract in the post yet the HR emailed a pdf of the contract to me to let me review it and said the contract will be sent out to me before I start.