🚀 Product startup

// Round by round

3–4 rounds · typical sequence

1. 1
   Founder or HM screen— 30 min· Founder, CTO, or hiring manager

   Why QA matters to them, how you have owned quality solo or in a small team. They are evaluating scrappiness and judgment, not polish. Expect questions like: 'What would you do in your first week?' and 'How have you set up testing where there was none?' This round is quick — they want to know if you can make decisions independently.

   Scored: Ownership instinct, communication clarity, breadth of experience, cultural fit.

2. 2
   Practical take-home task— 3–5 days (open-ended brief)· Completed independently

   Write test cases for a specified flow, or automate a small scenario against a live URL — no scaffolding provided. The brief is often deliberately sparse. A strong submission covers edge cases beyond the brief, includes a 'what I would do next' section, and is written as if a non-QA PM would read it. Weak submissions test only what was explicitly listed.

   Scored: Coverage breadth, initiative beyond the brief, quality of written reasoning, professional presentation.

3. 3
   Technical review and defense— 45 min· Engineer and/or hiring manager

   Walk through your take-home, defend every decision, then extend the task in new directions live. 'Why did you choose these test cases and not others?' 'What would you automate first?' They are testing reasoning under pressure, not just execution quality.

   Scored: Trade-off reasoning, ability to defend decisions, adaptability when the brief changes mid-interview.

4. 4
   Team / culture fit— 30–45 min· 1–2 team members (engineer, PM, or designer)

   How do you work, how do you give direct feedback, how do you handle ambiguity, what is your tolerance for a process that does not exist yet? Often conversational and deliberately unstructured to see how you navigate open-ended questions.

   Scored: Self-awareness, communication style, culture fit, comfort with uncertainty.

// What they weight

The signals that distinguish strong candidates from average ones in this archetype.

• Ownership and initiative: they want someone who notices a problem before being told and drives a fix without waiting for a ticket. Candidates who need direction at every step are a risk in a 15-person team where there is no QA manager.

• Breadth over depth: the first QA hire at a startup covers manual testing, automation, bug triage, environment issues, CI, and release calls — often on the same day. Narrow specialists who cannot switch contexts are a liability.

• Take-home quality as a signal of judgment: startups give open briefs to see what you choose to focus on. Minimum viable coverage signals minimum viable effort. An extra section explaining what you would test next, and why, is the differentiator.

• Speed of decision-making: they cannot afford a QA who takes a week to form a view. They want to see confident, reasoned decisions made under constraints — even if the answer is 'we do not have enough data, so I am testing the highest-risk flow first.'

// Question shapes to expect

These are question categories and formats — not leaked specific questions. Real questions vary by team and interviewer.

• 01

  Open-ended test planning without a spec: 'Here is our signup flow — tell me how you would test it.' No feature list given. You are expected to ask the right clarifying questions and generate coverage from first principles.

• 02

  Automation prioritisation: 'We have no automated tests. We have two weeks. Where do you start and why?' Tests risk thinking and prioritisation, not framework knowledge.

• 03

  War stories: 'Tell me about a time you caught a critical bug no one else found.' 'Walk me through a release that went wrong and what you did about it.' Startups value pattern recognition from hard experience.

• 04

  Fast-decision scenarios: 'We are shipping in 90 minutes and a payment bug just appeared. Walk me through what you do.' They are watching how you triage and communicate under pressure.

• 05

  Take-home defence: 'Why these test cases and not others?' 'What would change if we added guest checkout?' Expect the brief to be extended and the assumptions questioned.

// How to prepare

• ☐Treat take-home tasks seriously: read the brief carefully, cover edge cases beyond the spec, and always add a 'what I would do next and why' section.
• ☐Research the product before the screen — have three genuine questions about their biggest current quality risk and how QA fits the next six months of the roadmap.
• ☐Practise open-ended test planning without a spec — pick apps you use daily and generate coverage models from scratch, no documentation allowed.
• ☐Prepare two or three ownership war stories: catching a critical bug early, owning a bad release, improving a broken process solo with no budget.
• ☐Run the automation QA mock to pressure-test your take-home defence and live extension skills.

// Is this you?

Day-to-day reality of this role type — to help you self-select before investing in prep.

• Being the first or one of two QA engineers — building processes from scratch rather than inheriting an established one.

• Covering manual testing, writing automation, triaging production bugs, managing test environments, and contributing to release decisions — sometimes all in the same day.

• Working directly with founders and PMs where your opinion on ship/no-ship carries weight in the room.

• Shipping faster than you are comfortable with, and making peace with imperfect coverage because the cost of a slow release is higher than the cost of a minor bug.