Found in a Response Header: How I Joined Automattic
An HTTP response carried an `X-Hacker` header pointing at a job page. Three months, a paid trial on a real repository, and a silent CI gate later, I signed as a Staff DevOps Engineer at the company that started my career.

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.
| Date | Event |
|---|---|
| 13 March 2026 | Application submitted |
| 20 April 2026 | First response |
| 12 May 2026 | Interview with Lance |
| 18 May – 1 June 2026 | Paid trial |
| 4 June 2026 | Contract signed |
| 15 June 2026 | Start date |
The interview
It happened entirely on Slack. No calls, no algorithm puzzles. Lance wanted real debugging stories with named tools and measurable outcomes. A fragile cross-organisation CI/CD setup: a long-lived credential for authentication, and a control-plane surface left exposed just so a vendor's automation could reach it. I replaced it with FluxCD, removing both the credential and the exposure. 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 watching the wrong signal entirely, one that had quietly stopped reflecting what CI actually reported. Finding nothing to wait for, it reported success immediately and let auto-merge fire regardless of what was failing. The fix was pointing it at the right signal, plus a rollback for anything that slipped 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 calls in sequence and check what 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 one myself, in a workflow I'd generated with AI assistance: the output looked correct, but it quietly widened a trust boundary it shouldn't have, and I only caught it because I already knew the footgun. Lance caught the other, a different class of vulnerability I'd missed entirely in my reusable action, and pointed me to a linter for catching it 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 CI gate 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 watch the wrong signal 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.