PostHog SuperDay for Product Engineers: Prioritization, Pair Debugging, and Progress Reviews

PostHog SuperDay preparation starts with a useful distinction: you are building a product, but you are also showing how you choose work, investigate unfamiliar code, and respond to feedback. Finishing every requested feature is not the right target when the task is deliberately larger than the available time.

This guide covers the publicly documented Product Engineering SuperDay and adds original practice exercises. Official facts are linked to PostHog’s handbook. Candidate discussion is identified separately. The priority ledger, debugging fixture, and progress messages are editorial practice, not leaked tasks or a reconstruction of the assessment.

To rehearse the central decision, try Decide When to Simplify Scope and When to Prioritize a Bug Fix. Explain which user outcome you will protect before describing the code you want to write.

A product engineer chooses a correct daily count before optional export and theme features.

What the Product Engineering SuperDay includes

Official facts, checked September 9, 2026: PostHog describes SuperDay as a paid full day, currently compensated at $1,000 USD. It can be split across sessions when scheduling requires it. The task is intentionally too large to complete fully. Product Engineering includes a 45-minute pairing session; the general handbook says there is no advance task preparation required for it. Hiring process

The dedicated engineering preparation page distinguishes the main project from the debugging session: they use different codebases. It also lists a progress check-in and a short culture/motivation conversation. Tool rules differ: AI tools are allowed for the project if you understand the result; debugging permits basic autocomplete but not other AI assistance. Read your invitation for the instructions that apply to your session. Engineering SuperDay preparation

The practical implication is to prepare two modes of working. For the project, choose a familiar stack and get a useful path working. For pairing, practice forming a mental model of code you did not write. Do not spend your preparation time guessing a private repository or building a submission before receiving the brief.

PostHog’s engineering hiring page describes a buddy available through Slack, a review partway through the day, and a final submission with a summary. That makes visible decisions and usable handoffs relevant preparation targets. It does not establish a fixed hidden score for each message or feature. Engineering hiring

Prioritize an oversized task with a concrete user outcome

Here is an original practice brief: build a small event explorer that helps a support engineer answer, “How many events arrived on this UTC date, and which records explain that count?” The fictional request also asks for CSV export, custom date ranges, a theme switcher, saved views, and anomaly annotations.

The useful first slice is a correct daily count linked to the underlying records. A polished chart with an incorrect boundary would undermine the decision the product is supposed to support. Start by agreeing on event identity, timezone, and interval boundaries. Then implement a path that a reviewer can run and verify with a small dataset.

Work item	User value or risk	First decision	Evidence of completion
Daily count and matching rows	Core answer; wrong counts mislead support	Build first	Fixture count equals listed records
Empty and failed load states	Prevent “no data” from masking an error	Include in core path	Distinct visible states
CSV export	Useful sharing, but not needed to inspect three rows	Defer	Document expected format
Custom date builder	Broadens use, adds boundary decisions	Defer	State fixed UTC-day limitation
Theme switcher	Cosmetic in this exercise	Skip	No claim that it is complete
Anomaly annotations	Potential insight, but needs trustworthy counts	Reconsider after correctness	One defensible example, if time remains

This table is a decision record, not a universal ranking formula. If the user’s main job were exporting data to another tool, CSV could move into the first slice. Explain what evidence would change your order instead of defending an initial ranking as permanent.

A concise scope statement might be: “I will deliver one UTC-day view with matching count and rows, explicit empty/error states, and a reproducible boundary test. I am deferring export and arbitrary ranges until that path is trustworthy.” That tells the reviewer what they can assess and what they should not expect.

Set a stopping rule before adding polish

Define the smallest proof of a usable result. For this exercise, a reviewer should be able to start the app, select the fixture date, see two events, and inspect their IDs. The next date should contain the third event exactly once. A failed data request should display an error rather than a count of zero.

Once that path works, use the remaining time to remove the largest uncertainty. You might improve malformed-data handling, make the result easier to interpret, or document a deployment limitation. Do not automatically choose the next item because it is visually impressive or easy to demonstrate.

Keep a short “not yet” list alongside the working path. “Saved views are absent” is useful information. “Mostly done” is not, because it leaves the reviewer to discover which parts are real. A small, inspectable result gives the discussion a stronger foundation than several disconnected screens.

The stopping rule also protects time for verification. If a late feature would require new persistence, permissions, and migration behavior, its cost is larger than the visible button. Surface those dependencies before deciding to include it. Scope management is partly the ability to notice the work hidden behind a simple request.

Pair debugging: turn a suspicion into an observation

The following bug is original practice, unrelated to PostHog’s actual pairing tasks. Our event explorer claims that September 1 contains three events, although one belongs at midnight on September 2. All timestamps are already explicit UTC values.

Event ID	Timestamp	Expected UTC day
e1	2026-09-01 00:00:00Z	September 1
e2	2026-09-01 23:59:59Z	September 1
e3	2026-09-02 00:00:00Z	September 2

Before editing, identify where the count is produced and how date boundaries reach that function. Read the relevant entry point and trace the request to the predicate. You are trying to distinguish a timezone conversion, duplicate input, and an inclusive upper boundary.

A useful pairing explanation is: “The displayed count includes the event at the next midnight. I will inspect the range predicate before changing formatting, because the timestamps already carry UTC offsets.” That is a testable hypothesis with a reason, not a declaration that the bug is solved.

Hypothesis	Observation to collect	Result in our fixture	Next action
Duplicate events inflate the count	Compare total rows and unique IDs	Three rows, three IDs	Do not add deduplication
Local timezone shifts midnight	Inspect parsed offsets and requested bounds	Inputs and bounds are UTC	Inspect comparison operators
End boundary includes the next day	Evaluate the midnight row against the predicate	Upper comparison accepts equality	Change to a half-open interval

The faulty condition is start <= timestamp <= end. The proposed correction is start <= timestamp < end. The upper boundary is the start of the following day, so equality belongs to the next interval.

We executed this small predicate fixture locally in Python. The broken first-day result was [e1, e2, e3]; the corrected result was [e1, e2]; the next day returned [e3]. We also checked that the two corrected sets did not overlap. This verifies the exercise, not a PostHog implementation or a full production date-handling system.

A debugging record separates hypothesis, observation, and the next discriminating check.

Explain what the fix proves and what it does not

After changing the predicate, run the original reproducer and an adjacent-day check. A test that only checks “the count decreased” is too weak: removing the wrong row would also satisfy it. Assert the exact IDs and explain why midnight belongs to one interval only.

Then identify remaining boundaries. The fixture uses UTC days, not local calendar days with daylight-saving changes. It assumes valid timestamps and unique event IDs. Those assumptions are acceptable for the practice task when stated explicitly; they become defects if the product promises more.

If your first hypothesis is wrong, update the record rather than hiding the detour. “Unique IDs ruled out duplicate input, so I moved to the interval comparison” shows how evidence changed the investigation. It also helps a pairing partner contribute without repeating the same checks.

Ask for help with a narrow question when the unfamiliar system blocks you: “Which function owns the requested timezone?” is easier to answer than “How does this app work?” Read the answer back as a revised model, then test it. The aim is collaborative diagnosis, not uninterrupted narration of every keystroke.

Bring a decision and a question to the progress review

A progress review should make the project assessable before it is finished. Show the working path, name the largest remaining risk, and explain what you intend to do next. Include one question that could change the plan.

Here is a fictional midpoint update for the exercise:

The UTC-day view now returns the same IDs as its count. I found an inclusive end-boundary bug and verified the fix with midnight events on adjacent dates. Empty data and failed requests have separate states. Export and saved views are not implemented. My next choice is between malformed-timestamp handling and a custom-range UI; I would prioritize data handling because an invalid record could currently interrupt the entire view. Does that match the support workflow you want to evaluate?

This update connects completed work to evidence, and the question exposes a real tradeoff. It does not use a percentage-complete estimate whose denominator is an intentionally oversized task list.

Suppose the buddy says support users often paste malformed records and need to identify them. A useful response is to change the next slice: retain valid records, report rejected rows, and document the validation rule. Do not add the suggestion as an unchecked bullet while continuing your original cosmetic plan.

A later update can show the revision: “I replaced the custom-range work with an invalid-row summary after our discussion. The fixture now distinguishes valid events from rejected timestamps. The current scope remains UTC daily inspection.” This is an illustrative communication pattern, not a claim that we built that extended feature here.

What to confirm before your session

Confirm the schedule, how split sessions work if needed, the expected submission format, and who handles environment problems. Separate logistical preparation from learning the private task. A working editor, familiar development tools, and an understanding of the permitted assistance rules are more useful than speculative preparation around a rumored stack.

The general handbook’s “nothing to prepare” wording for pairing and the dedicated page’s suggestions to practice unfamiliar-code reading are compatible: no advance knowledge of the actual task is required. General debugging familiarity is optional preparation, not a new eligibility requirement. The dedicated page also asks candidates to understand and explain AI-assisted project work. Engineering SuperDay preparation

Candidate-discussion boundary: a March 2025 Hacker News participant described deciding not to proceed with SuperDay. That discussion illustrates concerns about time commitment and role fit; it is not a report of completing the day. We did not establish two independent same-cycle completion reports, so this guide does not invent pass rates, exact private tasks, or a guaranteed outcome timeline. Hacker News discussion

Practice the decisions you will need to explain

These verified PracHub questions are transferable preparation, not predictions of PostHog’s assessment. Use them to rehearse a visible decision, an observation, and the next check.

PracHub question	Practice focus
Decide When to Simplify Scope and When to Prioritize a Bug Fix	Protect the user outcome when the task exceeds the time.
Debug and Extend Cursor Queries	Trace boundary behavior before changing code.
Prioritize Critical Findings in a High-Load Batch Processor Review	Rank correctness risks using concrete evidence.
Explain Collaboration, Ambiguity, and Prioritization	Turn uncertainty into a useful question.
How would you prioritize and test features?	Connect feature order to a verification plan.

Finish with Decide When to Simplify Scope and When to Prioritize a Bug Fix. State one core outcome, one deliberate omission, and the evidence that would make you revise the plan. Those are decisions a reviewer can discuss.