Proof of work: portfolio, public suites, writing

A hiring manager scanning fifty applications for a QA role cannot verify a certificate in thirty seconds, but they can open a GitHub link and see whether the tests actually run. That shift, from claimed skill to shown skill, has been building for years and the arrival of AI-assisted coding has made it sharper. Proof of work is the collection of things you can point to that a stranger can inspect without asking you a single question first.

Why credentials carry less weight each year

Certification bodies test whether you memorized a syllabus, not whether you can debug a flaky test at eleven at night. That gap was always there, but it mattered less when nobody had a better signal to compare against. Now a public repository is a better signal, and it costs the reviewer nothing to check it.

This hits hardest in the newest specialities. Nobody hands out a certificate for testing a RAG pipeline or writing evals for an agent, because the field is a year or two old. The people getting hired into those roles are the ones who published something. Reading evals: the new test suite and then actually building one is worth more than any badge.

What counts as proof, concretely

Four things reliably move the needle, roughly in order of how much work they take to fake:

• A public repository with real commits. Not a tutorial clone. A test suite you wrote against a real API, a scraper you had to make resilient, a tool you built because an existing one annoyed you.
• An eval or test suite someone else can run. Clone it, run one command, get a result. If a reviewer has to configure four environment variables and guess a database schema, most will give up before finishing.
• A written breakdown of something you found. A postmortem-style writeup of a bug, a flaky-test root cause, or a security finding. Writing forces you to be precise about what you actually did, which a resume bullet never does.
• Contributions to something that already has users. A pull request merged into an open-source test framework carries more weight than a solo project, because someone else's review already vouched for it.

Consider a mid-level tester named Priya who wanted to move toward AI quality work. She had no production experience testing LLM features. Instead of waiting for a job to teach her, she built a small golden dataset for a public chatbot demo and wrote an LLM-as-judge scorer against it. She published the repo with a three-paragraph readme explaining what the scorer missed. It was not polished, and it took a weekend. It became the first thing she pointed to in interviews, and two hiring managers said it was why they called her back over candidates with more years but nothing to show.

Building the habit, not the one-off

The mistake is treating proof of work as a single project to finish before a job search starts. It works better as a habit. Ship something small every few weeks, write two paragraphs about what you learned, and keep the bar for "done" low enough that you actually finish. A quality engineer who writes up one bug investigation a month for a year has a body of work most portfolios never reach, because most people quit after the first unfinished attempt.

This connects directly to how hiring actually works now. A team hiring for an SDET role increasingly asks for a sample of automation code before a phone screen. A team hiring for AI quality work asks for anything showing you have touched a model's output critically.

Neither wants a list of tools you have used. They want evidence you used them on something real, and flakiness writeups are a common example of that.

Writing matters as much as code here. A bug report or an eval writeup that a non-technical reader can follow is itself a demonstrated skill, not a nice-to-have. If your writing reads like a changelog, rewrite it as a short story: what you suspected, what you tried, what actually broke, and what you would test differently next time.

None of this requires permission from an employer. A public repo, a suite that runs, and a clearly written finding are available to anyone with a weekend and the discipline to publish something unfinished rather than something perfect.

FAQ