PostHog engineering interviews: the SuperDay, AI rules, and practice examples

When you can use AI at PostHog

PostHog’s engineering handbook says AI is expected in the SuperDay project, but prohibited in the debugging session. The SuperDay is a paid full day of work; candidates must be able to explain the project they produce. This is a specific stage policy, not permission to use AI throughout the entire hiring process. PostHog’s engineering hiring handbook.

The candidate guide describes a role-specific project, a progress check-in, and a separate 45-minute debugging session in another codebase. The project is deliberately broad enough to require prioritization. Confirm your invitation’s schedule, tools, and instructions with your recruiting contact. Preparing for the engineering SuperDay.

The example questions PostHog shares

Before the SuperDay, PostHog describes a 60-minute architecture discussion. Its preparation guide gives examples involving large-scale notification delivery and protecting production from a bad deployment. The company explicitly says these examples are not the questions it will discuss in the interview. They illustrate the kind of reasoning to prepare. PostHog’s technical screen guide.

For the notification example, start with what users need: how quickly a message must arrive, what can be delayed, and what happens when the receiving service slows down. Then discuss queues, retries, and limits as answers to those requirements. Fix the Multi-Tenant Rate Limiter is a useful smaller exercise in controlling traffic while keeping client quotas separate. It practices one part of that design discussion, not the complete system.

For deployment safety, walk through a change you have actually shipped. Explain how you found a problem, stopped its spread, and decided whether to roll back. A specific story about an unexpected failure gives you more to discuss than a memorized list of infrastructure tools. Keep the distinction between your own experience and a design you are proposing.

Prepare with AI and without it

Build one preparation session around assisted implementation and another around independent investigation. During the first, use your usual assistant to plan and code, but inspect each change before accepting it. During the second, disable generation and automatic AI suggestions before opening an unfamiliar project. Practice tracing a failure with the debugger, logs, and targeted tests.

Make sure you know how to turn off automatic suggestions before a session that prohibits them. In either mode, keep a short note of the problem you are investigating and the command you last ran. That makes it easier to return after a conversation or interruption. At the end of practice, explain the important code without asking the assistant to summarize it for you.

Build a small project around a useful question

For practice, build an application that helps a developer compare error rates across two releases. Use synthetic events with an event ID, release, timestamp, and outcome. This is an original nrml exercise. The user wants to know whether the newer release has a higher observed error rate and how much data supports the comparison.

Set a narrow initial scope. Load a local fixture, validate it, compute a count and error rate for each release, and render a table with the selected time window. Skip live ingestion, authentication, and elaborate dashboards. A correct comparison with an understandable denominator serves the user better than several charts whose numbers cannot be explained.

Agree on what each number means

For this exercise, each unique valid event counts once; its outcome is either success or error. An error rate is error events divided by all valid events in that release and time window. Treat the start timestamp as inclusive and the end as exclusive. Require timestamps with an explicit offset, compare instants consistently, and report invalid records separately rather than silently dropping them.

Decide what to do when the same event ID has conflicting contents. For this exercise, exclude that ID from the comparison and report it as a data-quality issue. Identical duplicates count once. Write a small example of each case before generating code. Without those examples, you and the assistant may agree on the word “duplicate” while expecting different behavior.

Review this synthetic release-event fixture before editing code.
Identify invalid timestamps, duplicate IDs, and conflicting records.
Use [start, end) for the time window and count unique valid events.
Propose a pure aggregation function and independent test cases.
Keep rejected-record counts visible. List any ambiguous requirement.

Finish the basic comparison before adding features

Implement the aggregation function first, then connect it to a basic table. A user should be able to choose two releases and see their counts, rates, and time window. Keep the empty state explicit: no valid events means an unavailable rate, not zero percent. That distinction prevents a quiet release from looking perfectly reliable.

Once that works, decide what the user needs next. Showing sample size beside the rate may help more than a line chart. Letting someone inspect rejected records may matter more than animation. Write down why you chose the next feature. That gives you a useful answer when someone asks why you spent time on one part of the application and left another unfinished.

If you add an event list, practice Make Activity Pagination Stable. Its tied timestamps, tenant boundaries, and end-of-feed behavior are good reminders that a correct chart is only one part of a data product. Someone investigating a result also needs to be able to browse the underlying records reliably.

Check the result with data you can count by hand

Create a tiny dataset whose result you can calculate by hand: release A has eight successes and two errors; release B has two successes and one error. Add an identical duplicate, an invalid timestamp, and an event exactly at the end boundary. Keep the expected valid counts unchanged by those extra records. Now you have a concrete way to challenge a plausible but incorrect chart.

Check the display as well as the calculation. A rate of one third should appear as a percentage, while the error count should remain one. An empty result should not show NaN. Change the selected time window and watch every metric update. A unit test can pass while the interface still shows stale values from an earlier request.

Explain your choices at the project check-in

Halfway through practice, stop coding and explain the project to another person. Show the comparison, describe how you count events, and point out one awkward record. Say what you plan to build next and why. You should be able to do this while the application is still incomplete. Waiting until everything looks polished misses a useful chance to find a mistaken assumption early.

Ask a practice partner for one change, such as separating client and server errors. Translate the suggestion into a specific contract before prompting again. Can the supplied data support that distinction? If not, explain the missing field and keep the current output honest. Treat feedback as information to evaluate; a suggestion can reveal a useful future feature without justifying invented data today.

Practice debugging without AI

Use a different application for debugging practice so you have to read unfamiliar code. Repair the Expiring LRU Cache is a useful choice: expiration, recency, and cached null values give you several kinds of behavior to untangle. Turn off AI, reproduce a failure, and follow the relevant calls before editing. Explain what you expect to observe if your diagnosis is right.

For example, in a reporting application you might say, “The count changes only after sorting, so I suspect the shared array is being mutated.” Check the arguments and callers, then make a small repair. Rerun the original failure and an adjacent case. If the evidence disproves your idea, say what changed your mind. Recovering from a wrong diagnosis is part of debugging, and it is worth practicing aloud.

Make the project easy to run and review

Before finishing your practice project, try its setup instructions in a clean shell. Check that the sample data loads and the test command works. Write a short README explaining the metric, duplicate policy, and unfinished work. Commit as you complete useful pieces so you can inspect or undo a particular change. Follow the actual invitation for what to submit and where.

Your handoff can say: “The table compares unique valid events in the selected interval. Identical duplicates collapse; conflicting IDs are reported and excluded. I checked the boundary fixture and empty results. This is descriptive data, not evidence that the release caused the difference.” The final sentence prevents a useful visualization from claiming more than it can establish.

Choose your next practice session

Repeat the project with a new dataset and preserve time for a final check. On the next attempt, change the product question to latency or repeat usage and write a new metric contract before reusing code. Notice which assumptions survive and which need revision. Repetition should strengthen reasoning rather than memorize an interface.

After each session, note what slowed you down. Perhaps you accepted a generated query without checking its denominator, or spent too long searching before running a small reproduction. Give the next session one goal that addresses that problem. You do not need to rebuild the entire application every time; a focused hour on the part you could not explain is often more useful.