// Interview Prep/Resume & Portfolio
Interview Prep → Resume & Portfolio
Resume & portfolio.
Get past the screen and prove you can test. A QA-specific resume guide, role-by-role examples, impact bullet patterns, a portfolio playbook built around real repos, plus cover-letter and LinkedIn checklists.
// Resume guide
Lead with tools and outcomes, not duties. Every bullet should name a tool and a result. 'Responsible for testing' is a duty. 'Automated 300 regression tests in Playwright, cutting CI time by 70%' is an outcome. Hiring managers spend 30 seconds on a QA resume — make the outcomes visible immediately.
Build a real skills block. List your testing tools by category: automation frameworks (Playwright, Cypress, Selenium), languages (TypeScript, Java, Python), CI tools (GitHub Actions, Jenkins, CircleCI), bug tracking (Jira). Skip soft skills and MS Office — every candidate lists those.
Quantify everything you can. Test count, time saved, defect catch rate, coverage percentage, flakiness rate before and after — any number beats no number. If you can't quantify directly, use scope: 'across a 5-team product', 'covering the end-to-end payment flow'.
Keep to one page until five-plus years of experience. Two pages signal you can't edit. Ruthlessly cut earlier roles to three bullets each. If a job is over ten years old and not relevant, drop it entirely.
Put the strongest content at the top of each role. Don't bury your automation work under 'attended standups' and 'wrote test plans'. Lead with the technical outcome that signals depth.
// Resume by role
Manual QA
- Lead with test design: equivalence classes, boundary analysis, exploratory charters.
- Name the domains you've tested (payments, onboarding, mobile) — domain knowledge transfers.
- Show defect metrics if you have them (P1/P2 bugs caught before release).
- List the tools: Jira, TestRail/Zephyr, Postman for basic API checks.
Automation QA
- Name the framework + language stack prominently: Playwright + TypeScript, Selenium + Java.
- Quantify the test suite: number of tests, coverage area, CI pipeline it runs on.
- Call out flakiness reduction, maintenance improvements, or speed gains.
- Show CI integration: GitHub Actions, Jenkins, CircleCI — a badge in your GitHub repo proves it.
SDET
- Lead with framework authorship: designed, built, and maintained — not just used.
- Show coding depth: code review, design patterns (POM, Factory, Strategy), SDK-level contributions.
- Infrastructure ownership: containerised test runners, Kubernetes, Selenium Grid at scale.
- Team impact: how many engineers adopted your framework, what onboarding looked like.
API Tester
- Lead with the tools: Postman + Newman, REST Assured, Karate — name the stack.
- Show coverage depth: REST and GraphQL, auth flows (OAuth 2.0, API keys), contract testing.
- Call out negative test coverage and schema validation — these are the differentiators.
- CI integration: automated API suites running on every PR, not just manual Postman runs.
// Impact bullet examples
Adapt these to your own numbers and tools. The pattern: action + tool + outcome.
Automated 300 regression tests in Playwright + TypeScript, cutting the regression cycle from 4 hours to 22 minutes in CI.
Built a Selenium + Java POM framework adopted by four teams, reducing new test authorship time by 60%.
Identified 23 P1/P2 defects in exploratory sessions on a payments feature before go-live.
Reduced test suite flakiness from 35% to under 4% by switching to explicit waits and API-based test data setup.
Designed API contract tests with Pact that caught three breaking schema changes before they reached production.
Authored the team's QA strategy and risk-based regression scope, cutting test cycle time by 45% with zero coverage loss.
// Common resume mistakes
These patterns appear on most QA resumes that don't get interviews.
Writing duties instead of outcomes — 'Responsible for testing the application' says nothing. Name the tool, name the result.
Listing every tool shallowly with no depth signal — a wall of logos looks like a guess, not experience.
No quantification. Every bullet should have a number: tests count, time saved, defects caught, coverage percentage.
Soft skills in the skills block — 'attention to detail' is expected; list testing frameworks and CI tools instead.
Two pages with under three years of experience — one page forces you to edit down to what actually matters.
No skills section, or a skills section with 'MS Office, Excel, Jira' but no testing tools, languages, or CI stack.
// Portfolio guide
A framework repo beats a test file. Hiring managers want to see how you structure projects, not just that you can write a test. A repo with a /pages layer, /fixtures, CI config, and a README is worth ten scattered spec files.
Show one thing done well rather than five things done shallowly. One complete Playwright framework with POM, fixtures, CI, and a full README signals more competence than five half-finished repos in different tools.
Prove it runs in CI. A green CI badge in your README is the strongest portfolio signal. It means your tests work outside your machine, in a controlled environment, with pinned dependencies.
Include a bug report or exploratory charter. Manual QAs: a well-written bug report with steps, environment, severity, and a screen recording shows test thinking that automated tests alone can't convey.
// LEARN FROM REAL REPOS
These qa.codes project samples are built to interview standards — annotated architecture, CI configured, and a clean README. Study one before building your own.
// GitHub portfolio checklist
Run this against every repo you link on a job application.
- README explains what the project tests, how to install dependencies, and the exact command to run the suite.
- CI badge in README shows green — confirms the suite runs and passes outside your machine.
- Folder structure is self-explanatory: /tests (or /specs), /pages (or /support), /fixtures — no hunting required.
- No committed secrets, credentials, .env files, or tokens. .gitignore covers them.
- Commit messages are meaningful ('add checkout flow tests' not 'stuff' or 'WIP').
- Dependencies are pinned to a specific version — not wildcard latest — so the build is reproducible.
- At least one passing CI run visible in the Actions or Pipelines tab.
// Cover letters
Most QA cover letters are three generic paragraphs that could apply to any company. The three-paragraph structure below forces specificity.
Why them — specific, not flattering.
Reference something concrete: the tech stack they use, a product challenge they've published about, or the team they're building. 'I'm excited to join a fast-growing startup' means nothing. 'I've been using your Playwright-based testing setup as a reference for our own CI pipeline' means something.
Proof you can do the work.
One outcome-driven example — the same as your best resume bullet, expanded to two or three sentences. What the problem was, what you did, and what changed. This is the paragraph hiring managers actually read.
The ask — direct, not deferential.
State that you'd like to talk and give your availability. 'I'd welcome a 20-minute call to discuss how I could contribute to [team/product]' is better than 'I hope to hear from you at your earliest convenience.'
Example — paragraph 2
In my current role I automated 280 regression tests in Playwright TypeScript, cutting the nightly regression cycle from four hours to under 20 minutes. I also introduced API-based test data setup that reduced flakiness from 32% to under 3%. I would bring that same structured approach to your team's test infrastructure from day one.
// LinkedIn checklist
Recruiters source from LinkedIn before they read your CV. Make the profile do the work.
- Headline includes role title + primary stack (e.g. 'QA Automation Engineer | Playwright · Cypress · TypeScript').
- About section opens with an outcome — not a job description. One sentence that answers what you help teams do.
- Skills section lists specific testing tools (Playwright, Selenium, Postman, Karate) — not just 'Testing' or 'QA'.
- Featured section has at least one GitHub repo link, a project page, or a published article.
- Open to Work is configured if you are actively job-seeking — don't rely on recruiters finding you organically.
- Recent activity (likes, comments, posts) shows you engage with the QA community — passive profiles rank lower.