You are a talented and ambitious SQA professional, and you want to make a career move.
So you got a call from the really cool company that you submitted a resume to, or perhaps they found you on LinkedIn and contacted you via InMail.
Then you have a good phone screen call from the hiring manager or recruiter.
Now, it's time for an onsite interview for a few rounds of face-to-face interviews with your potential new co-workers.
You have a game plan to impress them: Look good, polished, wear that snazzy business suit that cost you $800 at Hugo Boss, and smile and be attentive to every question and try to get along with every person on the interview schedule.
Ok, great. But more is at stake here: an important career move for you, for a variety of reasons.
It's even more important for the potential employer to impress you as much as you want to impress them.
Being a SQA professional is a tough gig. SQA is almost always a neglected part of the engineering team. SQA is almost always fighting for respect and recognition as an important contributor to a great product offering. SQA team is often regarded and thought of as less talented than the development team.
You won't find a perfect team or a perfect job, but you might find a really good one, and certainly one that you can enjoy working on and be a productive and important member of. So I recommend asking 3 crucial questions to the team during our onsite interview, most especially to the hiring manager:
1) Who's responsible for quality?
The answer you are looking for is: everyone.
This answer reveals a greater consciousness that delivering quality is a requirement from each member of the team. From the receptionist, executive assistant, janitor, sales, product management, development and SQA resources. It's a team win or lose.
2) What software development process do you use and how has it been improved over the past year?
The answer you are looking for: probably something like Agile development where it de-emphasizes multi-tasking, encourages closer collaboration between product, sales, development, and QA teams, uses Retrospectives for team discussion on improvement. The main thing you are looking for is all parts of the team taking responsibility for both good and bad things that happen.
3) A critical bug is found by a customer. Where do you start investigation how the bug got into a production environment?
The answer you don't want to hear: SQA missed this and is at fault.
There are several factors that are possible that might precede a critical customer-facing or production bug: Compressed/inadequate development schedules, lack of unit testing by development team, requirement/use case not revealed by product management team, not enough testing time, late or last minute code changes. And, in some cases, SQA didn't test that part of the product or use case.
The point here is that you don't want the default scapegoat to be the SQA team every time a bug is missed in the testing activities. In some cases, yes, QA for whatever reason is the entity at fault. But usually, many other factors contribute to bugs, which the SQA team has very little control over.
Asking these types of questions will provide you with a lot of great information about if the mindset and practices of the potential employer, and if team aligns with your desired work environment for a SQA resource. So make sure to ask these and many other questions to be sure you are fully informed on the cool opportunity.