I applied for the Context Engineer role on PostHog's Wizard & Docs team. I built the whole application as a working presentation instead of a cover letter: a real PostHog implementation, Product Analytics, masked Session Replay, a custom survey, a feature flag, an AI chat panel a reviewer could actually talk to. I didn't get the role.
This is the honest version of what happened, what I'd do differently, and what I'm keeping from the process anyway.
The application
The idea was simple: instead of describing my skills, show them, on the exact product I was applying to work on. I built a nine-slide presentation at what's now /prehog, instrumented it with PostHog's own SDK, and wrote up every decision, what I implemented and why, what I deliberately left out, in a public repository a technical reviewer could actually read.
It worked as a demo. The mechanics held up: keyboard navigation, a no-JavaScript fallback, a reference mode for browsing instead of paging through slides, a live event log showing exactly what PostHog was and wasn't collecting in real time. I still think that part was the right call. If you're applying to build analytics tooling, shipping working analytics tooling says more than describing your approach to it.
What I got wrong
The writing is where I'd change course. I leaned on AI assistance to draft and refine the narrative slides, the "why PostHog" case, the culture-fit argument, more than I should have. The result read as polished in a way that worked against me: competent, thorough, and a little too smooth. A more focused piece, written in a plainer voice with fewer claims doing more specific work, would have landed better.
That's a strange thing to admit while applying to companies that build and rely on AI tooling. I don't think the answer is to avoid AI assistance. I think the answer is to use it for what it's actually good at, structure, research, catching gaps, and stay the one making the calls about what the piece actually says and how much of it needs saying. Somewhere in the drafting process I let the tool do too much of the thinking instead of the typing. The fix isn't less AI. It's a clearer line between assistance and authorship, and fewer, sharper examples of real work over more sentences describing it.
What stuck with me
Reading PostHog's own public handbook while I built the case for why I wanted the role turned into the more useful part of the process. Somewhere in there I picked up No Rules Rules, Reed Hastings and Erin Meyer's account of Netflix's culture, because PostHog's own spending-money handbook cites it directly as the influence behind their context-based expense policy. It's also listed on PostHog's company story page under "Things that influenced us." That's a company-level citation, well beyond the one HR policy.
The book's actual argument, give people context instead of control, and trust them to act on it, showed up independently across PostHog's culture, communication, and small-teams handbooks too. Fully remote across 20-plus countries. Two weekdays kept free of internal meetings by default. A stated bias toward "not asking for permission" if you're acting in the company's interest. Small teams with the final call on what ships and no external QA gate second-guessing them. None of that reads as marketing copy. It reads as a company that wrote down how it actually wants to operate and then built the systems to make that true.
I didn't get the role, but that pattern is worth more to me than one job outcome. It's the standard I'm holding the rest of my search to now: not "does this company say the right things," but "has this company written its own operating principles down somewhere I can check, and do the systems actually match."
The technical part: building a real PostHog implementation
The application itself is still worth walking through, because the analytics work turned out to matter beyond the one role it was built for.
I started with a short list of real questions instead of turning on blanket tracking: does anyone finish the presentation? Is the navigation discoverable on mobile? Do reviewers actually check the source code? Then I added exactly the events needed to answer each one, and nothing else. That question-first discipline is the part I'd defend most as good engineering in its own right.
A few pieces worth calling out specifically:
Consent-gated Session Replay, masked by default. Replay is scoped to one page, answers one question (is navigation discoverable on a phone), and masks every input plus the entire chat dialog as rendered text, extending coverage to the message bubbles the chat renders afterward, beyond the input field alone. PostHog's maskAllInputs only covers that second case on its own.
A real Survey, not PostHog's default popover. One rating question and one optional open-text field, custom-rendered in the page's own styling and shown once, after a visitor reaches the end. Restraint here felt more honest than a longer survey would have: one well-placed exchange beats a form nobody fills out.
A feature flag used for an actual rollout control, the genuine kind. I'd declined feature flags earlier in the build, since a flag with no real branch to test is just a fake experiment for résumé optics, then reversed the call once there was a genuine use for one: a self-referential live event-log panel worth being able to turn on for specific visitors without a redeploy.
An AI chat panel with a hard privacy line. Message text and model responses never reach PostHog at all; they route through a completely separate path (Firebase Functions to OpenRouter) with its own disclosure. The system prompt that drives it distinguishes explicitly between what's stated on the deck or independently verified and what's my own synthesis, and it's built to say plainly when it doesn't know something rather than guess.
A shared consent architecture that outlived the one page it started on. Building this properly for one presentation exposed what a real analytics setup actually needs: a consent layer applied consistently everywhere, checked before anything fires. That generalized into a small library now used across this site's main public pages, carrying the same discipline everywhere: specific, meaningful events, with visitor control designed in from the start.
None of that was wasted effort. It's still running, still instrumented, and still the clearest demonstration I have of how I actually build with PostHog's product rather than just talk about it.
Where it lives now
The original application stays exactly as it was, at benlive.tv/prehog, source at github.com/benmcnulty/prehog, in case a future PostHog-specific opportunity ever makes it relevant again. I'm not editing history to make it look like something it wasn't.
What's live going forward is benlive.tv/context-first: the same working implementation, generalized. The narrative shifted from "why hire me for this role" to why this way of working, context over control, decisions written down, small teams trusted with the final call, is what I'm actually looking for next, wherever that ends up.