The most common interview mistake isn't giving a bad answer. It's arriving unprepared to give any answer at all.
Preparation isn't a polish you add the morning of the interview. It's the work that happens days before — the research that lets you walk in knowing the company's context, the role's requirements, and the specific value you bring to this particular team, at this particular moment.
That preparation is the part of the interview most candidates skip. It's the part that separates the candidates who get offers from the ones who wonder what went wrong.
Learning Objectives
By the end of this lesson you will be able to:
- Build a pre-interview research framework that covers company, role, and interviewers
- Identify the four key sources of information that matter most before any interview
- Prepare specific, relevant examples from your past experience for technical interviews
- Use your research naturally in interview answers without sounding scripted
The Four Research Sources
1. The Company Website
Go beyond the homepage. Read:
- About Us / Mission: Understand what the company says it stands for. Do you believe it? Can you speak to it authentically?
- Products/Services: Use the actual product if it's publicly accessible. As a QA candidate, you're essentially auditing their quality. As a BA candidate, you're observing how well they've translated user needs into features.
- Blog or News: Recent posts reveal what the company is thinking about, what problems they're solving, and where they're heading.
- Careers / Culture pages: These tell you how they describe their work environment.
2. The Job Description
You've already read this to tailor your resume. Now read it again — more carefully — as an interview document.
Underline every requirement. For each one, identify a specific example from your experience that demonstrates you can deliver it. Not a story you'll tell in full (that comes in the next lesson), but a data point: "requirements elicitation → the time I ran stakeholder workshops for the inventory system overhaul."
Do this for every major requirement. When the interviewer asks "how do you handle conflicting stakeholder requirements?" you won't be improvising. You'll be choosing from a prepared set of examples.
3. LinkedIn (Company & People)
- Company page: Check recent activity. What are they posting? Are they hiring broadly, which suggests growth? Have they recently shipped something notable?
- Your interviewers: Look up everyone who will be in the room. What's their background? Have they written about their work? Do they seem to care about the same things you care about? This isn't surveillance — it's context that helps you speak their language.
- People in similar roles: Reading how other QAs or BAs at this company describe their work can tell you what the role actually involves day-to-day.
4. Glassdoor and Similar Platforms
Read recent reviews with scepticism (disgruntled ex-employees over-index here), but look for patterns. If three reviews independently mention "poor communication between product and QA," that's a data point. If five reviews mention "excellent onboarding and mentorship," that's worth noting too.
Prepare at least one question to ask based on what you read — questions that show you've done real research signal seriousness.
Preparing Your Technical Examples
For QA and BA roles, technical interviews often involve scenario-based questions. The best preparation is a catalogue of your own experiences.
Before every interview, write down two examples each for:
| Category | QA Example | BA Example |
|---|---|---|
| Finding a significant defect | A bug you found that had real impact | A requirement gap you identified before build |
| Handling pressure or disagreement | Pushing back on a release with known defects | Challenging a stakeholder's requirement |
| Process improvement | Improving a test process | Improving a requirements or documentation process |
| Collaboration | Working with developers to reproduce a defect | Facilitating a cross-team requirements session |
| Learning something new quickly | Picking up a new tool or domain | Getting up to speed in an unfamiliar business domain |
Having two examples per category means you can choose the better fit in the room, and fall back to the second if you've already told the first.
Using Your Research in the Room
Research only helps if you use it — and using it well means weaving it naturally into answers, not reciting it mechanically.
Weak: "I read on your website that you value innovation."
Strong: "I noticed from your recent blog post that you're expanding into cross-border payments. That domain has specific regulatory testing requirements I've worked with, and I'd be excited to bring that directly to your team."
The difference: the strong version uses the research to connect your experience to their context. It makes the interview feel like a conversation between two professionals, not a candidate proving they did their homework.
The Question You Must Prepare
Every interview ends with "Do you have any questions for us?" This is not a formality. Candidates who ask thoughtful questions are remembered. Candidates who say "no, I think you covered everything" are forgotten.
Prepare three questions before every interview. Make at least one of them research-based:
- "I read that you're migrating your infrastructure to microservices — how is the QA team adapting its testing strategy for that shift?"
- "Your engineering blog mentioned you've been investing in test automation. What does the balance between manual and automated testing look like on this team currently?"
- "I noticed your recent product update focused heavily on the mobile experience. What does that mean for how the BA team works with the design team?"
Pro Tips
Research the product like a tester, not a user. If the company has a public-facing product, use it deliberately. Look for inconsistencies, unexpected flows, and places where the UX doesn't match what you'd expect. Whether or not you mention it in the interview, it sharpens your thinking.
Prepare, don't memorise. You want to arrive with material, not a script. A memorised answer sounds like a memorised answer.
Arrive early — virtually or physically. Use the time before the interview starts to review your notes one last time. Not to cram, but to settle in.
Summary
Interview preparation is the competitive advantage that doesn't show up on a resume. Research the company website, the job description, LinkedIn profiles of your interviewers, and review sites — and use what you find to prepare specific examples and ask genuine questions. For QA and BA roles, the most effective preparation is building a catalogue of your own concrete examples, mapped to the key requirements of the role. Research used naturally in answers signals intelligence and genuine interest. Research left on your notes page is wasted.