Meta data engineer interview preparation: Product Analytics
Practise defining a product question, designing the right rows and writing a query that keeps missing users in view. The worked case follows first-week participation in a fictional interest-group product. It is deliberately different from a warehouse orders pipeline.
Meta's official Data Engineer, Product Analytics preparation guide names Product Sense, Data Modeling, ETL with SQL and Python, and Ownership. Its PDF contains conflicting technical-interview counts, so this guide does not promise a round count or duration. Confirm your own schedule and tools with your recruiter. The participation case, SQL and exercises here are original Prepti practice.
Try three original practice questions
Original Prepti practice, not real or reported Meta questions. Optional 90-second timing is a study aid, not an employer time limit. The result describes these three questions only, not hiring readiness. No account needed; answers stay in this page and are not submitted to a server.
Original Prepti practice, not employer questions. Timing is optional; no answer is submitted automatically.
What the official Product Analytics guide supports
Meta’s linked guide connects product awareness with data modeling and production ETL. It describes designing analytical data marts, calculating metrics, writing SQL and using Python data structures. Ownership preparation concerns initiative, collaboration, communication and evidence from your past work. These are the consistent themes used here.
The same PDF’s overview describes three technical interviews, while another paragraph says two. We do not turn that contradiction into an exact loop claim. It is also specifically a Data Engineer, Product Analytics guide, not a specification for every infrastructure or platform data role. Ask which interview and tool guidance applies to you, including permitted assistance. A familiar employer name is not permission to use outside AI during a live round.
Worked product-data case: who participates in the first week?
Original fictional brief: a product team wants new group members to make a useful contribution. It asks for the proportion who create at least one valid post during their first seven days. A large number of posts from a few members should not make the participation metric look healthy.
Cohort
Eligible new members whose full seven-day window has completed.
Outcome
At least one valid post in the member’s first seven days.
Guardrail
Track unwanted content separately; a post count is not proof of usefulness.
Define whether a member joining several groups enters once per member or once per membership. Both can be valid metrics, but they answer different questions. In this exercise, choose one row per eligible member for the product-level rate. A group-specific analysis needs a member-group key instead. Do not mix these grains in one denominator.
State the time window precisely. A signup at noon should not receive a different exposure period merely because a calendar-day boundary is convenient for the query. Decide how timezone, deleted posts, blocked accounts and late events affect the metric. Those are product and data-contract choices, not implementation details to hide in SQL.
Model the entities before choosing a join
Keep a member table with member_id and joined_at, and a post-event table with event_id, member_id, occurred_at, received_at and validity/version fields. A membership table can represent group membership separately. Do not make one wide table repeat signup attributes for every delivered event unless you also make the grain clear.
For a small SQL exercise, use integer day offsets after joining. The eligible cohort contains A, B, C and D. A has posts on days 0 and 2; B has a post on day 8; C has none; D has a post on day 6. First-week means offsets 0 through 6. Two of four members participate, so the rate is 50%.
SELECT c.member_id,
MAX(CASE WHEN p.member_id IS NOT NULL
THEN 1 ELSE 0 END) AS participated
FROM cohort c
LEFT JOIN posts p
ON p.member_id = c.member_id
AND p.day_offset >= 0
AND p.day_offset < 7
GROUP BY c.member_id;Aggregate the four member-level flags to get 2/4. Counting joined rows instead would overweight A. Putting p.day_offset < 7 in a final WHERE clause removes C’s unmatched row and can remove B as well. The query may still run and return an impressive number; it would answer a different question.
Test replay, lateness and an honest product explanation
Separate event time from receipt time. A valid day-six post received on day eight belongs in the first-week outcome if the reporting policy accepts that lateness. Decide whether yesterday’s report is provisional, when it becomes final, and how a corrected event changes history. Keep the rule visible to readers of the metric.
A small Python transform can use a dictionary keyed by event_id to select a canonical version. That is only a start: specify how versions are ordered, what happens on conflicting payloads with the same version, and whether a deletion tombstone must override an earlier valid post. A set of member IDs can calculate participation from already-canonical events, but cannot by itself express corrections.
“I would start with a completed new-member cohort and attach first-week valid activity at member grain. In the small fixture the rate is 50%, not a post-volume ratio. I’d test a member with no activity, an out-of-window post, a repeated delivery and a late correction. Before calling this product success, I’d confirm whether posting represents useful participation and examine quality guardrails.”
For Ownership, use a real example where a metric definition or data-quality issue changed a decision. Explain what you owned, who helped settle the definition and how you communicated a correction. Do not claim this fictional product or query as your own employment experience.
Practise a connected answer, not five disconnected topics
- Define one product outcome and the user action it represents.
- Draw entities and label the grain of every table.
- Write a query against a four-member fixture and predict its output first.
- Add a duplicate delivery, late event and deleted post; explain which output should change.
- Tell one truthful Ownership example and ask your recruiter about your actual round.
After practising, a partner should be able to trace the metric from product definition to source event to final row. If the chain breaks, another memorized SQL pattern will not repair it. Keep the data model and business definition together while explaining the trade-offs.
Questions about this guide
Is every Meta data engineering role a Product Analytics role?
No. This guide uses the official Product Analytics preparation document. Platform and infrastructure roles can require different preparation.
How many technical interviews will I have?
Confirm your schedule with your recruiter. The linked official PDF contains different counts in different sections, so we do not promise one here.
Is the SQL case a Meta question?
No. The cohort and participation exercise is original Prepti teaching with fictional data.
Choose your next practice step
Sources and scope
Employer statements are limited to the named source scopes. Role descriptions illustrate work, not a universal interview format, exact question list or current vacancy guarantee. Cases, questions, code, calculations and plans are original Prepti teaching. Use truthful experience and follow the actual assessment rules on tools and outside help.