Hey first, grats on getting an interview. I assume this means you’re looking for a new job. I’m glad to hear it.
I’m glad, because software is everywhere, and a lot of data’s flying around that needs to be handled correctly. Testing is extremely important, and we need skilled people out there mixing it up and cultivating quality.
So I’d like to impress on you how important and how big a responsibility QA is for any software company. It touches every department in a company.
Think about it:
- managers’ stress levels correlate to how good or bad the software is
- developers spend more or less time developing new revenue-generating features, or not, if bugs hit production
- customer service spend more or less time getting their ears hollered into, depending on how well the code behaves
- revenue streams grow or shrink relative to code quality
- operations and support have to spend more time doing ticket triage if the code in the wild is not up to par
- company branding takes a serious hit if a big bug hits their users.
The perception of a company’s success can last awhile, but if they fall on their face, man, the public are like spectators at the Colosseum.
Not trying to spook you! Don’t cancel the interview! Please?
What I mean is, QA is such an integral part of a company that it’s important to branch out from the standard point-and-shoot questions (i.e.: what do you need tested?) and get a more complete, clearer picture of the entire company.
Because, while you will be working at a desk, that desk is part of a company, which contain people, and that company has a flavor and character, because of the people, that will guide how you work.
Remember: They brought you in because they have a particular need to fill. They need more testers. The question is, Why?
Below are some QA Questions I use at every interview, to gauge the temperature and pressure points at a company. It’d be really cool if I could assign points to different answers, and then be like, “Hm. Well they only scored 75 out of 200, so meh, pass.”
Likely you’ll be asked some questions about testing, and may have some working examples to do, to see how much you know about it.
That’s fine. I don’t really want to focus on the technical side of it.
Instead, I want to focus on the kind of questions that will help you gauge what kind of company dynamic they have, how the team works, what’s possibly constipating their revenue stream, and what you might be getting yourself into.
So, what questions should be in mind during an interview?
The complete list of questions can be found right here, but I want to break out the sections so you know why they’re there.
Company Name: This is at the top so you know right away what company you’re looking at later, when you’re reviewing notes. It’s likely if you’re going on one interview you’re going on many. If not, you should be. I may write something about that at another time, but it’s out of scope here.
Who’s Who?: This section holds the info about who’s performing the interview, and what positions they hold. If you have questions for a person in a specific role, then you’ll know who to direct the question toward. Also, it comes in handy later when you send a thank-you note for their time after the interview. That’s bold for a reason. It might be important.
Questions About The Position: This is near the top too, so you can tell sooner what position it’s for.There are also some questions about why the position is there. Tactfully ask why the position exists–is it because someone left? Is it newly created? Maybe it’s there because they just need more people helping test or automate. If so, that’s a good data point. Why do they need more? Do they have a lot of bugs or do they want to get out in front, and they have devs producing faster than they can test? Intriguing… Subsequent questions will drill down into what their pain points actually are.
Bugs and Bug Reports: People who eat food gain energy but also produce poop. Companies who produce software gain revenue but also produce bugs.
This section is to glean information about how the company measures their poop, and whether there are certain parts of the system that have a higher concentration of it.
Sorry. I meant bugs.
This section is important. When they give you answers, document everything.
Sometimes they may not even realize that there’s a trend to the kind of bugs they have until someone asks them the question.
But if there’s a lot more of a certain kind of bug in the system, then that’s probably a pain point for them.
In the time between accepting the position and actually starting, you can be thinking about how you can resolve these issues–maybe even defend against a whole class of bug. Now that would be cool.
You can also ask about the tools they use to track the bugs. Jira is pretty popular (I almost said “poopular”), and I’ve been at places that use Bugzilla and TargetProcess. I believe all of these can at least be researched and kicked around on at home, so you can be somewhat familiar with them on your first day.
Also be sure to ask what kind of testing they’re doing. If they say they’re having problems with certain kinds of bugs, but the way they’re testing wouldn’t easily catch that kind of bug, that’s a solvable problem right there. And I bet in 2 weeks you can think up a method to do it.
Lastly is the question of how much time people spend fixing issues. Time spent fixing issues is time spent NOT producing revenue-able code. It’s also very costly in terms of context switching.
So if the company or team is spending most of their time firefighting, that’s a big problem–albeit a solvable one–that indicates the first thing needing to be done is to do what it takes to carve out time for your team and the company.
Process: How does a customer request work? This section is to determine how deep the stack is from customer to producer, and back again.
If a customer wants a feature, how many people does the request need to get through, before it gets to you?
If it’s a deep stack, the request will get filtered through many eyes and ears before it gets to you. You may get a better quality output. But, it may be slow. It’s possible to get concurrent requests stacked up, too, plus there’s the stigma of not releasing quickly like what all the cool kids are doing these days.
If it’s a short stack, then you’ll get work faster. The turnaround will be a lot quicker, but you have to be careful–it’s easy to release some really terrible product at breakneck pace. Also: the customers are likely used to the speed at which they get results. You can probably speed up the output as long as the quality is good, but slowing down the output can be a hard sell.
Culture: What’s the culture like? What’s the ratio of devs to testers? How do testers fit in? What’s the pace like? How is work handed off to testers?
All of these questions, together, will give you a view as to how collaborative people are.
Companies all behave differently–they’re all unique. Some of them use Agile practices, while some use Waterfall. Some companies want work to pass like a baton, while some want every discipline working in parallel.
How Can I Help You?: The interviewer(s) likely have an idea of what they want, but if you have your listenin’ face on, you can ascertain what it is they need.
Ask the questions about what looks like a good fit to them, and also whether they’re feeling pain anywhere.
Now I’m not saying that a potential employer is a big dummy and doesn’t know anything. But like with physical pain, sometimes it’s so bad you don’t know where it’s even coming from, and it takes an outside party (like a doctor) (or a tester!) to come in and fix the owie.
Extras: Finally at the bottom of the list is a space for any extra questions you might think of to ask later. Reserve this space also for changing up the list for yourself, for the next interviews.
This is by no means set in stone, so feel free to take an iterative approach to these questions and revise to fit your situation. And: if you find some new questions to ask, leave a comment! I’d love to hear what you would want to know when interviewing at a company.
Have fun, and good luck at the interview!