Found in a Response Header: How I Joined Automattic

I found Automattic through an HTTP response header.

In early 2026, I was debugging a visual update on a client's WPVIP site at Technogise when I noticed this in the response:

X-Hacker: If you're reading this, we should be friends.
          Interested in working at Automattic?
          https://automattic.com/work-with-us/

I opened the link. Read the page. Filled out the form.

I'd started my career in 2011 as a PHP freelancer: WordPress, WooCommerce, Drupal, vBulletin. Fifteen years later, after architecture and engineering-leadership roles at Perennial Systems, Engineering.com, and Technogise, WordPress had stayed in the picture throughout. Nearly every organisation I worked with used it for something. When I told my interviewer, Lance, that finding the job through a response header felt full-circle, he wrote back: "Full circle! Welcome back."

The timeline

Application to offer took three months. Trial completion to signed contract took three days.

The interview

It happened entirely on Slack. No calls, no algorithm puzzles. Lance wanted real debugging stories with named tools and measurable outcomes. A cross-organisation CI/CD setup where a vendor's Lambda called our repo's API with a PAT that expired unpredictably, and the cluster API stayed public just so the pipeline could deploy. I replaced it with FluxCD: the Lambda pushes an artefact instead of holding a credential, and the cluster never needs to be exposed. A Java Spring Boot suite that failed 40% of the time in CI, traced to a transaction race condition, a leaking @Async thread pool, and a stale Hibernate cache, fixed down to zero failures across 1,000+ runs. A case for deleting 200 near-duplicate UI tests and replacing them with three plus a contract test, cutting suite time from an hour to fifteen minutes.

Two days later, the trial invite arrived.

The trial

Automattic runs a paid trial instead of a conventional process. Ines called it a "close-to-real-world project," and Lance was specific about what that meant for a DevOps trial: improve a CI pipeline on a real repo, not a toy exercise. Real repositories, real problems, $25 an hour with no bearing on the eventual salary, no weekly hour requirement. Mine had two tracks: fix a broken Dependabot auto-merge setup on one repo, bootstrap the same automation on another. I went further on the second, building a reusable GitHub Action the whole org could reference instead of copy-pasting the workflow into every repo. It has since picked up outside contributors.

The real finding wasn't in either brief, though. A PR had merged despite failing CI. Tracing it back: the auto-merge aggregator was polling the legacy Commit Statuses API, while all the actual CI ran as GitHub Actions Check Runs, a separate API entirely. Finding nothing to wait for, it reported success immediately and let auto-merge fire regardless of what was failing. "Effectively," I wrote up, "our gate has had no gate for a while." The fix was swapping to an action that targets Check Runs directly, plus a git revert-on-failure rollback for anything that slips through. The bug is the invisible kind: no errors, no alerts, PRs merging and tests appearing to run. The only way to find it is to instrument the exact API calls in sequence and check which one the health check is actually querying.

The trial also surfaced two security findings in AI-generated code, from two different people, and the split matters. I caught an overly broad pull_request_target permission scope myself, in a workflow I'd generated with AI assistance. The output looked correct, but it grants fork-triggered runs the base repository's privileges, and I only caught it because I already knew the footgun. Lance caught the other one: a script-injection vulnerability in my reusable action that I'd missed entirely, and pointed me to actionlint for catching that class of issue going forward. Neither was flagged by the generation process itself. Structure every review to assume that gap. The output will always look finished.

I kept a running log of every AI interaction during the trial: prompt, tool, outcome, what I kept or threw away. It made one pattern obvious: AI was unreliable for diagnosis, reasoning from incomplete signals to a specific root cause, but useful for generation once I'd already done that reasoning myself. The Commit Statuses bug above is a diagnosis problem; the fix is a generation problem. Treating them as the same task is where the confident, plausible, wrong answers come from.

Around day ten, the trial lead sent a structured checkpoint: positive on technical competence, two areas to develop, an invitation to keep the conversation going asynchronously. No call to talk it through. Feedback here is a document, not a conversation. I answered in kind, with two more P2 posts.

The offer

Grace asked what stood out about the trial: a real repository with real problems, not the usual interview busywork. The salary offer, in Indian rupees, used a 180-day average exchange rate rather than the spot rate, which closed most of the gap from my stated expectation.

Takeaways

• The route in was an HTTP response header, noticed while debugging a client's WordPress site.
• Application to offer: three months. Trial to contract: three days.
• The interview wants real debugging stories with measurable outcomes, not algorithm puzzles.
• The trial pays $25 an hour, uses a real repository, and doesn't cap your ambition to the brief.
• CI gates that poll the wrong API fail silently. Verify what the health check is actually calling.
• AI-generated code needs a review pass that assumes the security gap; it won't flag itself.
• Automattic negotiates on process, not on standard contract language.
• P2 over Slack: writing that outlives the conversation is treated as the deliverable, not overhead.
• WordPress in 2011 to Staff DevOps Engineer at Automattic in 2026: fifteen years, not a straight line.