Meta Data Engineer Interview Prep: A Warehouse Practice Case

Prepare for a Meta data engineering interview by confirming the current role and format with the recruiter, then practicing the skills the assessment actually names. This is an independent preparation guide, not Meta’s official process or a current salary survey. The historical Jake case study is preserved separately with its reported questions and worked Python solutions.

Confirm the assessment before choosing tools

Ask about coding languages, SQL dialect, runtime, permitted documentation, interview duration, and whether the role emphasizes analytics engineering, batch pipelines, streaming, or modeling. Do not assume every team uses the same stack or round sequence. A company’s use of a technology does not prove it is required for this opening.

Map each confirmed skill to evidence you can produce: a checked query, a transformation with explicit missing-value behavior, a schema with a stated grain, or a recovery plan. Treat company-specific salary graphics and historical offer anecdotes as insufficient evidence for a current offer comparison.

Work a small ridesharing warehouse case

Question: report completed trips and gross fares by pickup city and date. Define one trip fact row per trip_id. A trip can have many raw events, but those events are not interchangeable with trips. The fixture below treats pickup_day as an already-derived date in a documented reporting timezone and fare as a valid amount in one currency. Taxes, refunds, tips, currency conversion, and accounting recognition are outside its contract.

WITH cities(city_id, city_name) AS (
  VALUES (1, 'North'), (2, 'South')
), trips(trip_id, city_id, pickup_day, status, fare) AS (
  VALUES (101, 1, DATE '2026-01-01', 'completed', 12::numeric),
         (102, 1, DATE '2026-01-01', 'completed', 18::numeric),
         (103, 2, DATE '2026-01-01', 'cancelled', 0::numeric),
         (104, 2, DATE '2026-01-02', 'completed', 20::numeric)
)
SELECT c.city_name, t.pickup_day, COUNT(*) AS completed_trips,
       SUM(t.fare) AS gross_fare
FROM trips AS t
JOIN cities AS c USING (city_id)
WHERE t.status = 'completed'
GROUP BY c.city_name, t.pickup_day
ORDER BY t.pickup_day, c.city_name;

The results are North, January 1: two trips and fare 30; South, January 2: one trip and fare 20. There is no South row on January 1. If the report needs zero-activity city-days, build the required city-date grid and left join these aggregates. An absent aggregate becomes zero only when the source feed is known to be complete.

Explain the model and its contracts

If attributes must be historically accurate, explain the effective-time relationship instead of joining every fact to today’s dimension value. Do not store a changing city label in every raw event merely to avoid defining the relationship. A star schema is one useful analytical design, not a universal employer requirement.

Design reruns and late-data handling

Specify what happens when an event is delivered twice, a trip is corrected, or a late completion arrives after the daily job. A rerun should replace or upsert the intended grain deterministically, not append another copy of every aggregate. Use source version or ordering rules to resolve conflicting updates; ingestion time alone may not establish business-event order.

Define a lateness policy and which partitions can be recomputed. Record input boundaries, transformation version, output counts, and reconciliation checks. Reject or quarantine invalid events with an observable reason. A watermark is a processing policy, not proof that no later event can arrive.

Explain when streaming is justified

A daily finance-style report and a near-real-time dispatch view have different freshness and correctness needs. Start with the required decision latency. Streaming adds state, event-time windows, retries, backpressure, and correction semantics. “Exactly once” must be qualified by the system boundary and sink behavior; it does not eliminate duplicate business events by itself.

For either mode, explain failure recovery and access controls. Test duplicate events, conflicting trip updates, missing dimension keys, a late arrival, a timezone boundary, and a rerun. A diagram without those contracts is incomplete.

Use a focused practice loop

1. Write and reconcile the query on the fixture.
2. Change one requirement, such as including zero-activity days.
3. Describe how raw events produce one valid trip fact.
4. Explain a failure and recovery path.
5. Give a real collaboration example with your own contribution and observed outcome.

Use SQLPad’s Facebook-labeled practice collection as additional practice, not as a guarantee of current employer questions. The useful outcome is an answer you can defend when the data or requirements change.