Dataford
Interview QuestionsInterview GuidesExperiencesCoaching
New
Pricing
Get started
Dataford
Popular roles
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Browse
Browse All RolesEvery role hub, from analyst to MLBrowse All CompaniesCompany-specific interview loopsAll Interview GuidesThe full guide library
Top questions by role
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Top questions by skill
SQLPythonStatisticsMachine LearningA/B TestingSystem DesignGenerative AIProduct SenseMetricsBehavioral
Browse all questions →Try a mock interview
Experiences
Practice
Mock InterviewsTimed interview simulations with feedbackCoaching1:1 coaching with people at your target companiesSuccess PathYour 6-week structured planModulesCurated lessons by topicWebinarsTalks from ex-Big Tech data leadsPlaygroundA free-form scratch editor
Learn
BlogInterview strategy and career adviceTech Job Market ReportHiring trends across data and AI rolesFor UniversitiesDataford for career centersAbout DatafordWho we are and how we build
Pricing
Build my plan

Backfill Historical Reporting Data

MediumPipelines00:00
Practice interviewer
In session
5 left
00:00

Your question is Backfill Historical Reporting Data. Take a moment with it on the right.

Talk me through your thinking if you like. When you're confident, submit your answer and I'll grade it like a real screen (7/10 or better passes).

You need to log in / sign up to chat or submit.

Problem

Context

FinSight, a B2B SaaS analytics company, discovered a reporting bug in its revenue pipeline: refunds were excluded from net revenue for 14 months due to an incorrect transformation in a dbt model. The current stack uses Kafka for event ingestion, Airflow for orchestration, Spark on Databricks for batch processing, and Snowflake for serving BI dashboards. Leadership needs corrected historical reports without breaking downstream consumers or double-counting data.

Scale Requirements

  • Historical window: 14 months of data
  • Volume: 3.2B transaction events, ~28 TB raw Parquet in S3
  • Daily ingest: 8M new events/day continues during backfill
  • Latency target: corrected tables available within 48 hours
  • Serving SLA: dashboard freshness for current-day data must remain < 30 minutes
  • Retention: raw immutable data stored for 2 years

Requirements

  1. Design a backfill strategy that recomputes historical aggregates after the bug fix while keeping daily production loads running.
  2. Ensure idempotent reprocessing so reruns do not create duplicates or inconsistent metrics.
  3. Define how to isolate corrected data before cutover, validate it against current production, and promote it safely.
  4. Handle partitioned reprocessing by event_date/account_id to reduce blast radius and enable parallel execution.
  5. Include data quality checks for row-count reconciliation, refund-rate validation, and aggregate diffs versus source-of-truth finance exports.
  6. Describe orchestration, checkpointing, retry behavior, and rollback if the backfill introduces regressions.
  7. Explain how downstream BI models and consumers will be notified of metric restatements.

Constraints

  • AWS-based infrastructure must be reused; no major platform migration.
  • Incremental cloud spend for the backfill should stay under $15K.
  • Finance requires an auditable record of what changed, when, and why.
  • PII cannot be copied into ad hoc environments; all processing must remain in approved S3/Snowflake accounts.
  • The team has 3 data engineers, so the solution should minimize operational complexity.