What is Dataflow and why does Google ask about it?

Dataflow is Google's managed Apache Beam service: unified batch and streaming programming model, the GCP-canonical answer for stream processing. In design rounds, Pub/Sub to Dataflow streaming to BigQuery is the standard streaming architecture. The interview checks whether you understand windowing (fixed, sliding, sessions), triggers (when to emit results), and watermarks (how Dataflow handles late-arriving events).

How does BigQuery pricing affect data engineer design discussions?

BigQuery prices on slot consumption (compute) and storage. The design rubric weights cost reasoning: partition pruning (querying only the relevant date partitions cuts cost N-fold), clustering (CLUSTER BY user_id makes lookups cheap on a 100TB table), materialized views (precomputed for repeated queries), and BI Engine (in-memory acceleration for dashboards). Mention slot reservations versus on-demand pricing for predictable workloads.

What does the system design round look like at Google?

GCP-native architecture, 45-60 minutes. Common scenarios: streaming clickstream (Pub/Sub to Dataflow to BigQuery plus Cloud Storage), batch warehouse with daily refresh (Cloud Storage to Dataproc Spark to BigQuery), ML feature store (Dataflow to Bigtable for online plus BigQuery for offline), or migration scenario (existing Spark cluster on EMR, move to GCP with Dataproc-then-Dataflow). Rubric weights streaming-vs-batch choice, exactly-once semantics, and cost reasoning.

Do Google data engineer candidates need to know algorithms beyond DSA basics?

Yes for the Python round, more than most data engineer loops. Beyond basic data structures (dict, set, list, generator), expect sliding-window aggregators, heap-based merging (heapq), graph traversal for lineage questions, and explicit time/space complexity for every approach. The bar is not LeetCode-hard, but the rubric weights complexity articulation.

Google Data Engineer Interview Questions (BigQuery)

Google Data Engineer Interview Questions

Google-tagged data engineer interview questions that run on submission and push back on the answer that only worked on the sample rows.

Google data engineer interview questions tagged based on reported interview shape. BigQuery-flavored SQL with ARRAY and STRUCT and QUALIFY. Large-scale Dataflow pipeline design. Algorithm-adjacent Python with explicit complexity reasoning that distinguishes Google from most data engineer loops. GCP-native architectures with cost reasoning in slot consumption.

Google's data engineer interview loop is 5-6 rounds with the GCP data stack as the assumed default. BigQuery is the warehouse (columnar, separated storage and compute, no DISTKEY/SORTKEY because partitioning and clustering replace them, ARRAY and STRUCT for semi-structured data). Dataflow runs Apache Beam pipelines (unified batch and streaming, the Google-canonical stream-processing answer). Pub/Sub is event ingestion (at-least-once with deduplication via message_id). Dataproc is Spark on GCP for migration scenarios. Cloud Storage with BigLake provides data lake with BigQuery query federation.

The Google data engineer SQL bar is BigQuery-flavored. Window functions, CTEs, and aggregation are standard. BigQuery-specific syntax that comes up: QUALIFY (native in BigQuery, filters window results without a wrapping CTE), ARRAY_AGG and UNNEST for semi-structured data, STRUCT for nested records, date partitioning (PARTITION BY DATE(timestamp)), clustering (CLUSTER BY user_id for high-cardinality lookup). Practice in Postgres here is portable for ~85 percent of patterns; BigQuery-specific syntax is tagged on the problems where it applies.

What makes Google distinct from other data engineer loops is the algorithm-adjacent thread in the Python round. Google's overall engineering culture comes through in the bar. Candidates report standard pipeline questions (parse, dedup, sessionize) but also Big-O-aware questions: implement a sliding-window aggregator in O(n) with a deque, explain the time complexity of your dedup approach, identify when a generator-based stream beats a list-based accumulator, defend why your data structure is O(1) lookup versus O(n) scan. It is not LeetCode-hard, but it is harder on complexity reasoning than Amazon or Stripe. Prepare to articulate Big-O for every data structure choice.

The Google data engineer design round expects a GCP-native architecture. For a streaming clickstream: Pub/Sub for ingest (with shard-equivalent sizing in subscriber count), Dataflow streaming job for windowed aggregation and dedup, BigQuery for serving plus Cloud Storage for raw archive. For a batch warehouse: Cloud Storage to Dataproc Spark for heavy joins to BigQuery for serving. For ML feature store: Dataflow streaming to Bigtable for online plus BigQuery for offline. The design rubric weights the streaming-versus-batch decision (when does Dataflow streaming make sense versus batch loading to BigQuery every 15 minutes), exactly-once semantics in Pub/Sub plus Dataflow (the at-least-once plus dedup pattern), and cost reasoning at scale (BigQuery slot consumption, Dataflow worker hours, Cloud Storage storage class trade-offs).

Google levels its data engineers L3 (entry, rare for DE), L4 (mid), L5 (senior, most common hire for experienced data engineers), L6 (staff), L7 (senior staff). L5 typically targets 5+ years experience. Rubric depth scales: L5 expects trade-off articulation and ownership of pipelines, L6 expects org-level design influence.

The behavioral round at Google is "Googleyness and Leadership", less rigid than Amazon's LP framing but with consistent themes: ownership, collaboration, ambiguity tolerance, and growth mindset. STAR format works. Specific numbers matter. The interviewer is also assessing communication clarity and the ability to make a point concisely; Google interviewers are often impatient with rambling answers.

Full data engineer interview catalog - 1,400+ problems across all 5 rounds.
SQL interview questions (BigQuery-portable) - 930 problems; Postgres dialect ports to BigQuery for ~85 percent of patterns.
Python interview problems (algorithm-adjacent at Google) - Big-O-aware pipeline questions, streaming aggregators, complexity reasoning.
Window functions with QUALIFY - BigQuery-native QUALIFY clause for filtering window results.
System design with GCP architectures - Pub/Sub + Dataflow + BigQuery patterns for Google data engineer prep.
Streaming system design with Dataflow - Exactly-once via at-least-once + dedup; Dataflow windowing.
Google data engineer company page - Loop structure, team-by-team variation, leveling guide.
Google data engineer mock interview - AI mock with Google-calibrated rubric.
FAANG data engineer interview questions - Google + Meta + Amazon + Netflix + Apple per-company rubrics.

What SQL dialect does Google use in data engineer interviews?: BigQuery Standard SQL. Window functions, CTEs, and aggregation are standard. BigQuery-specific syntax to know: QUALIFY (native, filters window results without a wrapping CTE), ARRAY_AGG and UNNEST (for semi-structured data), STRUCT (for nested records), date partitioning (PARTITION BY DATE(timestamp)), clustering (CLUSTER BY user_id for high-cardinality lookup). Practice in Postgres ports for ~85 percent of patterns.
Why is the Python round 'algorithm-adjacent' at Google?: Google's broader engineering culture weights Big-O reasoning more than most companies. Data engineer Python rounds at Google include standard pipeline questions (parse, dedup, sessionize) plus complexity-aware questions: implement a sliding-window aggregator in O(n) with a deque, explain why your dedup is O(n) versus the sort-then-iterate O(n log n) alternative, identify when a generator beats a list. Not LeetCode hard, but candidates report being asked complexity for every data structure choice.
What is Dataflow and why does Google ask about it?: Dataflow is Google's managed Apache Beam service: unified batch and streaming programming model, the GCP-canonical answer for stream processing. In design rounds, Pub/Sub to Dataflow streaming to BigQuery is the standard streaming architecture. The interview checks whether you understand windowing (fixed, sliding, sessions), triggers (when to emit results), and watermarks (how Dataflow handles late-arriving events).
How does BigQuery pricing affect data engineer design discussions?: BigQuery prices on slot consumption (compute) and storage. The design rubric weights cost reasoning: partition pruning (querying only the relevant date partitions cuts cost N-fold), clustering (CLUSTER BY user_id makes lookups cheap on a 100TB table), materialized views (precomputed for repeated queries), and BI Engine (in-memory acceleration for dashboards). Mention slot reservations versus on-demand pricing for predictable workloads.
What does the system design round look like at Google?: GCP-native architecture, 45-60 minutes. Common scenarios: streaming clickstream (Pub/Sub to Dataflow to BigQuery plus Cloud Storage), batch warehouse with daily refresh (Cloud Storage to Dataproc Spark to BigQuery), ML feature store (Dataflow to Bigtable for online plus BigQuery for offline), or migration scenario (existing Spark cluster on EMR, move to GCP with Dataproc-then-Dataflow). Rubric weights streaming-vs-batch choice, exactly-once semantics, and cost reasoning.
Do Google data engineer candidates need to know algorithms beyond DSA basics?: Yes for the Python round, more than most data engineer loops. Beyond basic data structures (dict, set, list, generator), expect sliding-window aggregators, heap-based merging (heapq), graph traversal for lineage questions, and explicit time/space complexity for every approach. The bar is not LeetCode-hard, but the rubric weights complexity articulation.
How does Google handle the behavioral round for data engineers?: Google's behavioral round is 'Googleyness and Leadership' theme, less rigid than Amazon's LP framing but with consistent themes: ownership, collaboration, ambiguity tolerance, and growth mindset. STAR format works. Specific numbers matter. The interviewer is also assessing communication clarity and the ability to make a point concisely; Google interviewers are often impatient with rambling answers.
What levels does Google hire data engineers at?: L3 (entry, rare for DE), L4 (mid), L5 (senior, most common hire for experienced data engineers), L6 (staff), L7 (senior staff). L5 typically targets 5+ years experience. Rubric depth scales: L5 expects trade-off articulation and ownership of pipelines, L6 expects org-level design influence.

102 practice problems matching this filter. Domains: SQL (68), Python (34). Difficulty: medium (47), easy (37), hard (18).

SQL (68)

10 Lowest Uptime Services - medium - Ten services at the bottom of the reliability chart.
Active Users With April Transactions - easy - Active accounts that also opened their wallets. How many?
Average Review Comments by Author - medium - Some authors get more feedback than others.
Average Session Duration by Device - easy - Session length, device by device.
Average Sessions Per User - hard - How often do users come back?
Between the Spaces - medium - Every pause between words is a vote for length. Count them.
Between Two Extremes - medium - Ignore the loudest and the quietest. The truth lives in the middle.
Build Success vs Failure by Repo - medium - Green versus red, repo by repo.
Campaign Revenue Totals - easy - Every campaign has a price tag. Total them up.
Competing Standards - hard - Every framework has a star model.
Cost Share Within Category - medium - Each entry's slice of the category total.
Creatures of Habit - hard - Every big team has one service it can't quit.
Custom Message Type Counts - medium - Not all messages are created equal.
Days with More Edited Than Unedited Messages - medium - Some days, more messages get edited than sent.
Distinct Product Categories - easy - A quick category inventory.
Double Take - medium - Passed QA twice. That's the problem.
Feature Name Intersection - hard - Training names versus serving names. The overlap.
Find Deploy Authors - easy - Same person. Many different spellings.
First Migration Record - easy - The very first migration. Where it all began.
Gone to Ground - medium - The control group held steady. Some of them slipped away. Find the ones who stopped answering.
Health Checks per Service - easy - Some services get checked constantly.
High Price Products - easy - Everything above 100.
Infant Mortality - hard - The youngest ones break first.
iOS Sessions by Device Type - medium - iOS engagement, device by device.
Last Migration Record - easy - The most recent migration. Is it the last?
Mentorship User Pairs - medium - Pair them up. Mentor and mentee.
Messages Containing Keyword - easy - Flagged terms in the messages.
Multi-Host Regions by Node Type - medium - Some regions are quietly building empires.
Mutual Channel Connections - medium - Two users. What channels do they share?
Never-Ordered Products - easy - In the catalog. Never purchased.
Nodes by Region and Type - medium - Broken down by region. Broken down by type.
Noisiest Tables by DQ Failures - medium - The tables that fail the most checks.
Non-Draft Content - easy - Everything except drafts.
Open Wounds - hard - Every service has one alarm that was never silenced. Find the one that has been screaming the longest.
Parallel Traces - medium - Same experiment. Different variants. Who overlaps?
Past the Threshold - medium - Somewhere after the third visit, a habit quietly forms. Find the ones who crossed over.
Prime Real Estate - easy - Not every screen earns the build. Find the ones that do.
Return on Patience - medium - The best answers cost the least time. Find the ones that pay off.
Reviewer Performance Metrics - medium - Some reviewers are thorough. Others are fast.
Reviews Per Reviewer - easy - The workload split across reviewers.
Rooms in Common - hard - Two people, one channel, a connection you never counted.
Search Terms Starting With G - easy - Queries starting with 'g'.
Services at Median Uptime - medium - Exactly at the median. Not above, not below.
Session Page View Distance - hard - Page view distance per session.
Sessions Per Device Type - easy - Sessions, device by device.
Symmetric Reply Network - medium - Every reply is an edge. Draw it both ways.
The A/B Verdict - medium - Variant A or Variant B. The conversion numbers pick the winner.
The Apprentices Still in the Forge - easy - A model is not a model until it stops learning and starts earning.
The Blast Radius - medium - A reliability scoreboard for deploy teams.
The Floor Price - medium - Before the negotiation, find what each provider really charges at its cheapest.
The Gap Between Neighbors - hard - Same region, and still they disagree.
The Legacy Hunt - easy - Old data. Still matters.
The Long Tail - medium - Averages hide the pain. The tail is where SLOs live.
The Merit Circle - medium - Ten seats at the top, and the ratings decide who sits.
Then and Now - hard - Accuracy used to be higher.
The Notification Lifecycle - medium - Sent, opened, ignored. What happened after the alert went out?
The Ones Worth Paging - hard - Three levels wake someone up at night. Tally each one.
The Podium Finish - medium - Top two products per category.
The Relentless Searchers - medium - Most users look once and leave. A few never stop looking.
The Standing Fleet - easy - Some hosts wear many hats. Count the machines, not the mentions.
The Tag Order - hard - Tags arrived in chaos. The system needs them in line.
The Token Census - easy - How many tokens are out there?
The Upgrade Divide - medium - The install numbers don't match the hype.
The Weight of the Cloud - medium - Not every dollar counts the same. Close the quarter.
Top Percentile API Tokens - hard - The most suspicious tokens.
Unclicked Searches by Campaign - medium - Searched but never clicked.
Unique Reporters per Content - medium - How many people flagged each item?
Where the Year Leans - medium - Some teams file early, some file late. See which way each one tips.

Python (34)

Against the Grain - medium - Turn the grid on its side and let every column stand up as a row.
All Told - easy - Every shift leaves a number behind. Total the fleet.
Batch Records - medium - Too many at once. Break them into groups.
Carrying Forward - medium - The total grows with every row.
Column Range - easy - From minimum to maximum. What is the spread?
Corner to Corner - medium - A grid pressed flat still remembers its corners.
Downstream - hard - Nothing runs until what it needs has run.
Down the Line - medium - Load has to keep moving. Pass it down the line.
Even Filter - easy - Only the even ones survive.
Every Trace - medium - It is in there somewhere. Where exactly?
Explode List - easy - One row holds many values. Unpack it.
High Water - easy - Every reading remembers the highest that came before.
High Water Mark - easy - Even below zero, one reading still stands above the rest.
Moving Day - hard - Old schema in, new schema out.
Null Counter - easy - How many holes in the data?
Out of Nowhere - hard - Every stream has a rhythm. Find the readings that break it.
Quality Gate - easy - Not everything passes inspection.
Single File - easy - However deep the nesting, every voice arrives in its own turn.
Sort Descending - easy - Biggest first. No exceptions.
The Dependency Resolver - medium - Everything depends on everything.
The Email Ranker - medium - Some inboxes see more action.
The Firehose - medium - A stream arrives out of order. Roll it up, one time window at a time.
The First of Their Kind - easy - When the same record arrives twice, only the first one survives.
The Last Known Good - medium - When a column goes quiet, its last reading keeps standing.
The Log Pulse - easy - Some lines repeat themselves.
The Running Total - easy - Each position holds the sum of everything before it.
The Streak Breaker - easy - It has a problem with repetition.
The Stream Joiner - hard - Events don't wait for each other. This does.
The Throttle Ceiling - medium - Too many requests in too short a timeframe. Throttle it.
The Throttle Wall - hard - Stop the abusers. Let the rest through.
Transform Column - easy - Same data, new shape.
Value Count - easy - How many of each? Count them.
What Changed Overnight - medium - Schema from yesterday vs today. Something changed.
Where the Line Breaks - easy - Every batch has a last piece. Mark it right.