QA Hiring Guide for Engineering Managers: Interview Questions, Take-Home Projects, Red Flags

Defining the Role Before You Post

The most expensive QA hiring mistake is posting a job before you've defined what you actually need. QA is a broad function, and the specific skills required vary significantly by role type. Posting "QA Engineer" without definition attracts candidates across a spectrum — from manual testers with no automation experience to SDETs who haven't touched manual testing in years.

The Three Role Archetypes

SDET (Software Development Engineer in Test)

The SDET writes production-quality code for test infrastructure, develops automation frameworks, and may contribute to CI/CD pipelines, test tooling, and developer productivity. Strong coding skills are essential — at or near the level of a senior software engineer.

When to hire: you need to build or scale your automation framework, your pipeline needs test tooling investment, or your product teams need embedded engineering-quality automation support.

When not to hire: you need exploratory testing expertise, test planning skills, or manual test execution. SDETs hired into manual-testing-heavy roles will be bored and underperforming within three months.

QA Engineer

The generalist role. Strong understanding of testing methodologies, can write automation at the integration and E2E level, performs exploratory testing, participates in requirements review, and owns test planning. Coding skills are important but less intense than SDET.

When to hire: you need broad quality coverage across a product area, you're building out automation capability from a manual testing foundation, or your team has mixed manual/automation needs.

QA Lead / Senior QA

Owns the quality strategy for a team or product area. Mentors junior QA engineers, designs test architecture, defines quality gates, and communicates quality status to leadership. Strong communication skills, system design judgment, and cross-functional influence are as important as technical skills.

When to hire: you need quality leadership rather than individual contribution, you have junior QA engineers who need mentorship, or your quality strategy is undefined and needs a senior owner.

Writing the Job Description

The JD signals your understanding of the role before the candidate knows anything else about you. Weak JDs attract weak candidate pools.

What a strong QA Engineer JD includes:

• Specific technologies used (not a laundry list — the 3–4 most important ones)
• The balance between manual and automated testing work (in percentages if possible)
• What the team ships and how often (deployment frequency signals maturity)
• The biggest testing challenges the team is facing
• What success looks like in 6 months

What to avoid:

• Tool laundry lists ("must know Selenium, Cypress, Playwright, Appium, JMeter, Postman" — nobody's an expert in all of these)
• "Responsible for quality" as a responsibility — this is meaningless
• Requirement inflation ("must have 5+ years with Playwright" — Playwright is 5 years old)
• Conflating SDET and manual QA in a single role

Screening for Test Thinking

The first filter in your process should screen for test thinking — the cognitive skill of reasoning about what needs to be tested, what could go wrong, and how to verify correct behavior. This skill is more fundamental than any tool knowledge and more predictive of success.

The Phone Screen Question

Use one of these questions to assess test thinking in a 30-minute screen:

"Walk me through how you would test a login form. Don't worry about tools — just tell me what you'd test and why."

A strong candidate covers: happy path (valid credentials succeed), error cases (invalid password, nonexistent user), edge cases (case sensitivity in username, special characters in password, SQL injection attempts), state cases (account locked after N failures, password expired), accessibility (keyboard navigation, screen reader compatibility), and performance (response time under load).

A weak candidate covers: valid credentials succeed, invalid credentials fail. Maybe empty fields.

The delta between these responses is predictive of how the candidate will approach real test planning.

The Five Essential Interview Questions

These questions should appear in every QA interview, regardless of seniority level. The rubric describes what good answers look like — use it to calibrate across interviewers.

Question 1: "Tell me about a time you found a critical bug late in the release cycle. How did you handle it, and what did you change to prevent it from happening again?"

What you're assessing: Risk communication skills, judgment under pressure, retrospective thinking, and process improvement orientation.

What a strong answer looks like: The candidate describes a specific incident with concrete stakes. They explain how they communicated the risk to stakeholders (not just "I told the team"). They describe the decision made (ship with known bug, hold release, fix with workaround) and what tradeoffs were considered. Critically, they describe a concrete change they made to their process afterward — a new test case type, an earlier review step, a change to how requirements are reviewed — and they can speak to whether that change worked.

What a weak answer looks like: Vague description without specific stakes. No mention of communication to stakeholders. No retrospective improvement. "I made sure it was fixed before release" — which describes the expected behavior, not judgment in a hard situation.

Red flag: "The developers should have caught that." Blame-first candidates create adversarial relationships with engineering teams.

Question 2: "You join a team with no test automation and a two-day manual regression cycle. You have three months to improve the situation. What do you do?"

What you're assessing: Strategic thinking, prioritization, stakeholder management, and realistic self-assessment.

What a strong answer looks like: The candidate starts by asking what they don't know — what's the risk profile of the product, what's the release frequency, what's the team's coding experience with testing? They describe an audit phase (what's failing in prod, what takes longest to test manually, what's most critical). They prioritize automation candidates based on ROI (stable, high-traffic flows first, not whichever is most interesting). They mention stakeholder communication — keeping leadership informed of progress and managing expectations. They identify realistic scope for three months rather than promising to eliminate all manual testing.

What a weak answer looks like: "I'd implement Playwright for E2E automation and start with the login flow." No audit phase, no risk assessment, no stakeholder consideration, no scope management. This describes a candidate who picks tools before understanding problems.

Follow-up: "You've been there two months. Coverage is improving but the team's developers aren't writing any tests. What do you do?" Strong candidates describe enablement strategies — pairing, documentation, showing ROI — not escalation or complaint.

Question 3: "A developer tells you a bug you found is 'by design.' You disagree. What do you do?"

What you're assessing: Influence without authority, business context integration, professional communication, and knowing when to escalate versus defer.

What a strong answer looks like: The candidate asks clarifying questions — what requirement does this behavior satisfy, is it documented? They describe checking the specification, user story, or design document to find the authoritative answer. If the spec is ambiguous, they bring in a product manager or designer. If they still disagree after that, they escalate with a business case ("this behavior will confuse users because…") rather than asserting they're right. They describe accepting the outcome if the business decision goes against them, while logging the disagreement in the appropriate tracking system.

What a weak answer looks like: "I'd escalate to their manager." Or "I'd mark it as a bug anyway." Both describe conflict avoidance or force — not influence.

What this reveals: Quality engineering requires influence without authority. Candidates who default to escalation or conflict will struggle in every team they join.

Question 4: "How do you decide what not to test?"

What you're assessing: Risk-based testing judgment, coverage prioritization, and understanding that test coverage has diminishing returns.

What a strong answer looks like: The candidate describes risk-based testing methodology — prioritizing test effort based on probability of failure, impact of failure, and cost of testing. They identify factors that reduce testing priority: stable, unchanged code with existing coverage, low-risk features with limited blast radius, code that's been in production unchanged for years. They mention explicit test coverage decisions that get documented so the next person understands the rationale. They might describe a coverage matrix or risk register they've used.

What a weak answer looks like: "I test everything." This describes either naivety about time constraints or inability to prioritize. Neither is good in a senior candidate. For junior candidates, it's less disqualifying — inexperienced QA engineers haven't yet developed risk-based intuition and this is a teachable skill.

Follow-up for senior candidates: "You have a new feature with a tight deadline. You can cover the happy path and two error cases, or spend the same time covering eight edge cases. What do you choose?" Strong candidates ask about the feature's risk profile before answering.

Question 5: "Walk me through your approach to investigating a flaky test."

What you're assessing: Systematic debugging skills, root cause orientation, and patience with ambiguous failure modes.

What a strong answer looks like: The candidate describes a systematic investigation process: reproduce the failure reliably first (run the test 10+ times in isolation), rule out environment issues (does it pass locally but fail in CI?), identify the failure category (timing, data, ordering, environment), use logging and traces to narrow the cause, and fix at the root rather than adding retry logic as a first resort. They mention that flaky tests are often symptoms of production code issues (timing dependencies, race conditions, inconsistent state).

What a weak answer looks like: "I'd add a wait" or "I'd add retry logic." These are the two most common anti-patterns in flaky test management. They suppress the symptom without addressing the cause and make the underlying problem harder to find later.

Bonus signal: Candidates who've built flaky test detection infrastructure (quarantine mechanisms, automatic retry-and-report, flaky test dashboards) demonstrate senior automation engineering capability.

Designing the Take-Home Project

The take-home project is the single highest-signal interview step because it reveals how candidates approach real work rather than how they perform under interview pressure. Design it carefully.

Project Design Principles

Scope it for 2–4 hours. Longer projects discriminate against candidates with family obligations, second jobs, or limited free time — they don't select for better engineers, just more available ones.

Test a real target. Use a public API (GitHub API, JSONPlaceholder, OpenLibrary) or your own product's public-facing features. Avoid artificial "test this function" exercises — they don't predict real test planning ability.

Leave it deliberately open-ended. Don't specify the framework, the test count, or the coverage approach. You want to see how candidates make decisions, not whether they follow instructions.

Ask for a brief write-up. "Explain what you tested, what you chose not to test, and what you would do with more time." This is often more revealing than the code itself.

Sample Project

"Write automated tests for the GitHub public API's repository search endpoint. We're interested in how you decide what to test, how you structure your tests, and how you communicate your approach. Time limit: 3 hours. Include a short README explaining your coverage decisions and what you'd add with more time."

Evaluation Rubric

Coverage thinking (30%): Does the candidate test beyond the happy path? Do they cover error responses, edge cases (empty results, special characters, pagination boundaries)? Is their coverage justified, not just comprehensive?

Code quality (25%): Is the code readable? Are tests independent (no shared state between tests)? Are assertions meaningful? Would you accept this as a pull request from a team member?

Documentation (25%): Does the README explain the reasoning behind coverage choices? Does the candidate articulate tradeoffs? Do they identify gaps honestly?

Professional quality (20%): Does the project run without setup errors? Is the README accurate? Are commit messages meaningful? This predicts attention to detail in daily work.

Red Flags in Resumes and Interviews

Resume Red Flags

Excessive tool listing without context. "Selenium, Cypress, Playwright, Appium, JMeter, Postman, LoadRunner, SoapUI" across four lines is usually a candidate who lists tools seen on job descriptions rather than one who has deep expertise in any. Ask which two they've used most heavily and in what contexts.

Test counts as accomplishments. "Wrote 2,000 test cases" is not an accomplishment without context. What were the outcomes? What was the coverage delta? What bugs did they catch? Quantity metrics in QA are almost always vanity metrics.

No evidence of process improvement. Strong QA engineers don't just execute tests — they improve how testing is done. A resume with no evidence of process improvement, tool introduction, or methodology change suggests someone who executes tasks rather than improves systems.

Interview Red Flags

"We should test everything." Risk-based prioritization is a fundamental QA skill. Candidates who can't articulate when not to test something will waste time on low-risk areas while missing high-risk ones.

Blaming developers. "Developers should have caught that in code review." "If they wrote better code, we wouldn't find so many bugs." QA and engineering must work collaboratively. Adversarial relationships with development teams are the leading cause of QA team dysfunction.

Tool-first thinking. The first question from a strong candidate is about the system, not the tools. Candidates who immediately ask "what automation framework do you use?" before understanding the product, the architecture, or the testing challenges prioritize their comfort zone over the team's actual needs.

No curiosity about failure. Strong QA engineers are professionally curious about how things fail. Candidates who give polished answers about success scenarios but struggle to articulate failure modes, edge cases, or system weaknesses lack the investigative mindset that distinguishes good QA from checkbox execution.

Inability to explain a technical concept simply. QA engineers communicate quality status to non-technical stakeholders regularly. Ask a candidate to explain a testing concept (code coverage, flaky tests, test debt) as if explaining to a product manager. Candidates who can't simplify will struggle in cross-functional communication.

SDET vs Manual QA Hiring: What's Different

The hiring process for SDETs and manual QA engineers differs significantly in the technical evaluation.

SDET Interview Additions

Algorithm and data structures: At the SDET level, expect candidates to solve LeetCode medium problems. Test their ability to write clean, readable code, not just correct code.

System design for testability: "Design the testing architecture for a payment service that processes 10,000 transactions per day." Strong SDET candidates think about reliability, monitoring, test data management at scale, and failure mode coverage — not just which framework to use.

Code review exercise: Give the candidate a test file with 3–5 real issues (shared state, non-deterministic assertions, missing cleanup, poor naming). Ask them to review it as they would a pull request. This assesses code quality judgment and communication of feedback.

Manual QA Interview Additions

Test case creation exercise: Provide a functional specification (2–3 pages) for a feature and ask the candidate to write a test plan in 30 minutes. Evaluate for completeness of coverage, structure, and prioritization.

Exploratory testing session: Give the candidate 20 minutes to explore a real product feature and report what they find. Strong manual QA testers find multiple issues in any 20-minute session — not because the product is bad, but because they know where to look.

Offer and Onboarding Tips

Set calibrated expectations in the offer stage. Be explicit about the balance between manual and automation work, the current state of the test suite, and the biggest quality challenges. QA engineers who join with unrealistic expectations about automation-forward work burn out when they find themselves manually executing regression tests.

Build the onboarding checklist before day one. QA engineers need access to source code, CI/CD pipelines, test environments, test data sources, and bug tracking before they can be productive. These accesses are often forgotten in standard engineering onboarding and take weeks to obtain — which wastes the first month of a new hire's time.

Assign a "break this feature" task in week one. Before asking a new QA hire to write tests or update existing coverage, have them spend one week exploring the product with no deliverable other than finding issues. This builds product knowledge, calibrates risk understanding, and typically produces valuable bug reports. It also gives you a concrete view of the candidate's quality thinking in your actual product context.

The right QA hire — whether SDET, QA Engineer, or QA Lead — fundamentally changes the team's quality trajectory. The process described here is more rigorous than most engineering hiring processes, and for good reason: the cost of a wrong QA hire isn't just wasted salary. It's automation debt, adversarial team dynamics, and quality problems that don't get caught.