Square (Block) Data Engineer Interview Guide

From hundreds of mock interviews we've coached, the pattern is clear: candidates prep for Block's data engineer loop like it's an analytics role and get blindsided by how much it resembles a backend SWE screen. Block weights software engineering and pipeline reliability at roughly 45% of the evaluation, so if your prep plan is "brush up on SQL and skim some Spark docs," you're underprepared.

Square (Block) Data Engineer Role

Success after year one means you own the reliability of pipelines tied to real money movement. Think: the Spark jobs materializing daily seller transaction tables that feed Square's merchant dashboards, or the data quality checks that catch schema drift before it breaks downstream financial reporting. "Ownership" here includes your name on the on-call rotation and your freshness SLAs holding up when the analytics and ML teams build products on your tables.

A Typical Week

The thing that catches people off guard isn't the coding. It's how much of your week goes to operational work that never shows up in a job description: SLA triage on Monday morning, backfilling dimension tables after a schema migration on Wednesday, handing off the on-call pager on Friday with runbook updates you wrote during the week. Meetings stay surprisingly low for a cross-functional role, but the ones you do attend (negotiating feature store contracts with Square's ML team, pairing with analytics engineers on data model questions) require real-time technical decisions, not status updates.

Projects & Impact Areas

Square's seller ecosystem drives the most visible pipeline work, where transaction data flows from a card tap on a Square Terminal through authorization and settlement into warehouse tables powering merchant analytics and the AI-powered inventory management product. Cash App layers on a different set of problems: P2P payments, direct deposits, and Bitcoin-related flows each carry distinct schema shapes, latency expectations, and privacy requirements that likely demand careful access controls and audit-friendly design. Stitching both product surfaces together is the connective tissue work (data quality validations, lineage tracking, freshness contracts) that keeps compliance and analytics teams self-serve instead of filing tickets.

Skills & What's Expected

Software engineering ability is the most underrated differentiator for this role. Candidates over-index on SQL and distributed compute knowledge while underestimating that Block expects production-quality Python or Java with unit tests, CI/CD integration, and proper error handling. Stats and ML knowledge barely matter here. You won't build models, but you need enough payments domain fluency to design schemas that serve the teams who do, and enough infrastructure comfort to reason about orchestration and monitoring without leaning on a platform team for every deploy.

Levels & Career Growth

The promotion blocker from L4 to L5 is almost always the same: shifting from "I build what's scoped for me" to "I own end-to-end reliability for an entire product area's data." L5 to L6 requires cross-team architectural influence, like defining Block's approach to real-time versus batch for a new product line. Block's flat IC culture (a Jack Dorsey holdover) means Staff and Principal engineers stay hands-on. Nobody's hiding behind a team of reports.

Work Culture

Block's office policy is a moving target. Some teams operate fully remote, while others expect three or even four-plus days per week in the SF office, so ask your recruiter for the specific team's norm before assuming anything. The open-source ethos runs deep (Square Connect APIs, Bitcoin development contributions via Spiral), and the pace leans toward sustainable craftsmanship rather than startup-frantic sprints. On-call rotations carry real consequences when payments data has hard SLAs tied to money movement, but from what candidates report, the culture rewards careful engineering over heroic firefighting.

Square (Block) Data Engineer Compensation

Block calculates your RSU share count by dividing a target dollar value by the trailing ~30 trading-day average closing price around your vesting commencement date. That commencement date snaps to either the 1st/16th or the 20th of the month after your start date, depending on offer letter language, so a few days' difference in your start date can shift when the clock begins. Refresher grants are performance-based, not guaranteed repeats of your initial package. Blind discussions peg them at roughly 20–30% of the initial equity annually for solid performers, but others describe disappointing numbers. Treat your signing grant as the comp you're actually accepting.

The negotiation lever with the most surface area is equity grant size, since Block's offer negotiation notes explicitly frame RSU value and leveling as the primary levers rather than base or bonus percentage. If you're borderline between levels (L4/L5 is the common boundary for external hires), pushing for the higher level moves your entire band in a way no within-band adjustment can match. Ask your recruiter to share the level, band boundaries, grant-date price methodology, and refresh policy in writing so you're comparing real numbers across any competing offers you hold.

Square (Block) Data Engineer Interview Process

The full loop runs about 4 to 6 weeks from recruiter call to written offer, with six weeks being common once you factor in scheduling. The top rejection reason, based on candidate reports, is flawed SQL thinking: wrong grain assumptions, broken window function logic, or queries that ignore how downstream analysts and fraud detection systems actually consume the data.

Block uses pooled interviewers, so the engineers grading you probably aren't on the team you'd join. Keep your examples rooted in payments-scale concerns (reliability, PCI sensitivity, reconciliation) rather than one team's niche tooling. After the technical rounds, your packet goes through a bar review step before team matching even begins. That sequencing matters: a thin System Design answer that skips failure recovery or backfill strategy is a common reason otherwise-strong candidates stall at the review stage, because operational depth is a recurring evaluation theme for fintech pipeline roles.

Square (Block) Data Engineer Interview Questions

1WITH ranked AS (
2  SELECT
3    p.payment_id,
4    p.merchant_id,
5    CAST(p.created_at AS DATE) AS payment_date,
6    p.amount_cents,
7    p.currency,
8    p.status, -- e.g., 'CAPTURED', 'REFUNDED', 'CHARGEBACK'
9    p.updated_at,
10    ROW_NUMBER() OVER (
11      PARTITION BY p.payment_id
12      ORDER BY p.updated_at DESC
13    ) AS rn
14  FROM payments p
15  WHERE p.created_at >= CURRENT_DATE - INTERVAL '30' DAY
16), latest AS (
17  SELECT
18    payment_id,
19    merchant_id,
20    payment_date,
21    amount_cents,
22    currency,
23    status
24  FROM ranked
25  WHERE rn = 1
26)
27SELECT
28  merchant_id,
29  payment_date,
30  currency,
31  -- GPV: captured amount only.
32  SUM(CASE WHEN status = 'CAPTURED' THEN amount_cents ELSE 0 END) AS gpv_cents,
33  -- Net GPV: captured minus refunds and chargebacks.
34  SUM(
35    CASE
36      WHEN status = 'CAPTURED' THEN amount_cents
37      WHEN status IN ('REFUNDED', 'CHARGEBACK') THEN -amount_cents
38      ELSE 0
39    END
40  ) AS net_gpv_cents
41FROM latest
42GROUP BY merchant_id, payment_date, currency
43ORDER BY payment_date DESC, merchant_id;

1/*
2Assumptions:
3- Source table: payments (payment_id, merchant_id, created_at, amount_cents, currency, status, updated_at)
4- Target table: merchant_daily_balance (merchant_id, business_date, currency, gpv_cents, net_gpv_cents, last_recomputed_at)
5- Control table: etl_watermarks (pipeline_name, last_successful_updated_at)
6
7This pattern recomputes only impacted (merchant_id, business_date, currency) partitions since the watermark,
8handles late updates by keying off updated_at, and dedupes payment versions by payment_id.
9*/
10
11WITH params AS (
12  SELECT
13    COALESCE(
14      (SELECT last_successful_updated_at
15       FROM etl_watermarks
16       WHERE pipeline_name = 'merchant_daily_balance'),
17      TIMESTAMP '1970-01-01 00:00:00'
18    ) AS last_watermark,
19    CURRENT_TIMESTAMP AS this_run_ts
20), changed_partitions AS (
21  -- Identify impacted partitions by looking at any payment rows updated since last watermark.
22  SELECT DISTINCT
23    p.merchant_id,
24    CAST(p.created_at AS DATE) AS business_date,
25    p.currency
26  FROM payments p
27  CROSS JOIN params
28  WHERE p.updated_at > params.last_watermark
29), ranked AS (
30  -- Pull all payment rows for impacted partitions and keep only latest per payment_id.
31  SELECT
32    p.payment_id,
33    p.merchant_id,
34    CAST(p.created_at AS DATE) AS business_date,
35    p.currency,
36    p.amount_cents,
37    p.status,
38    p.updated_at,
39    ROW_NUMBER() OVER (
40      PARTITION BY p.payment_id
41      ORDER BY p.updated_at DESC
42    ) AS rn
43  FROM payments p
44  JOIN changed_partitions cp
45    ON p.merchant_id = cp.merchant_id
46   AND CAST(p.created_at AS DATE) = cp.business_date
47   AND p.currency = cp.currency
48), latest AS (
49  SELECT
50    payment_id,
51    merchant_id,
52    business_date,
53    currency,
54    amount_cents,
55    status
56  FROM ranked
57  WHERE rn = 1
58), recomputed AS (
59  SELECT
60    merchant_id,
61    business_date,
62    currency,
63    SUM(CASE WHEN status = 'CAPTURED' THEN amount_cents ELSE 0 END) AS gpv_cents,
64    SUM(
65      CASE
66        WHEN status = 'CAPTURED' THEN amount_cents
67        WHEN status IN ('REFUNDED', 'CHARGEBACK') THEN -amount_cents
68        ELSE 0
69      END
70    ) AS net_gpv_cents
71  FROM latest
72  GROUP BY merchant_id, business_date, currency
73)
74MERGE INTO merchant_daily_balance t
75USING (
76  SELECT
77    r.*,
78    (SELECT this_run_ts FROM params) AS last_recomputed_at
79  FROM recomputed r
80) s
81ON t.merchant_id = s.merchant_id
82AND t.business_date = s.business_date
83AND t.currency = s.currency
84WHEN MATCHED THEN UPDATE SET
85  gpv_cents = s.gpv_cents,
86  net_gpv_cents = s.net_gpv_cents,
87  last_recomputed_at = s.last_recomputed_at
88WHEN NOT MATCHED THEN INSERT (
89  merchant_id,
90  business_date,
91  currency,
92  gpv_cents,
93  net_gpv_cents,
94  last_recomputed_at
95) VALUES (
96  s.merchant_id,
97  s.business_date,
98  s.currency,
99  s.gpv_cents,
100  s.net_gpv_cents,
101  s.last_recomputed_at
102);

1from __future__ import annotations
2
3import json
4from collections import defaultdict
5from typing import DefaultDict, Dict, Iterable, Set
6
7
8def net_amount_by_merchant(json_lines: Iterable[str]) -> Dict[str, int]:
9    """Compute net processed amount per merchant in cents from JSONL events.
10
11    Event schema (per line):
12      - id: str (unique event id)
13      - merchant_id: str
14      - type: one of {"AUTH", "CAPTURE", "REFUND", "CHARGEBACK"}
15      - amount_cents: int (non-negative)
16      - related_id: optional str (not required for this aggregation)
17
18    Rules:
19      - Ignore duplicate events by the same event id.
20      - Net effect per event type:
21          AUTH: +amount (treated as processed for this simplified metric)
22          CAPTURE: +amount
23          REFUND: -amount
24          CHARGEBACK: -amount
25
26    Returns:
27      Dict mapping merchant_id to net cents (can be negative).
28    """
29
30    seen_event_ids: Set[str] = set()
31    net_by_merchant: DefaultDict[str, int] = defaultdict(int)
32
33    for line in json_lines:
34        line = line.strip()
35        if not line:
36            continue
37
38        event = json.loads(line)
39
40        event_id = event.get("id")
41        if not event_id or event_id in seen_event_ids:
42            continue
43        seen_event_ids.add(event_id)
44
45        merchant_id = event.get("merchant_id")
46        event_type = event.get("type")
47        amount = event.get("amount_cents")
48
49        if merchant_id is None or event_type is None or amount is None:
50            # Skip malformed records rather than failing the whole batch.
51            continue
52        if not isinstance(amount, int):
53            # Defensive, some sources may encode numbers as strings.
54            try:
55                amount = int(amount)
56            except (TypeError, ValueError):
57                continue
58
59        if event_type in ("AUTH", "CAPTURE"):
60            delta = amount
61        elif event_type in ("REFUND", "CHARGEBACK"):
62            delta = -amount
63        else:
64            # Unknown event type, ignore.
65            continue
66
67        net_by_merchant[str(merchant_id)] += delta
68
69    return dict(net_by_merchant)
70
71
72if __name__ == "__main__":
73    sample = [
74        '{"id":"e1","merchant_id":"m1","type":"AUTH","amount_cents":1000}',
75        '{"id":"e2","merchant_id":"m1","type":"CAPTURE","amount_cents":1000,"related_id":"p1"}',
76        '{"id":"e3","merchant_id":"m1","type":"REFUND","amount_cents":200,"related_id":"p1"}',
77        '{"id":"e2","merchant_id":"m1","type":"CAPTURE","amount_cents":1000,"related_id":"p1"}',
78        '{"id":"e4","merchant_id":"m2","type":"CHARGEBACK","amount_cents":500,"related_id":"p9"}'
79    ]
80    print(net_amount_by_merchant(sample))
81

What stands out here isn't any single area but how pipeline reliability and production coding questions bleed into each other. A question about deduplicating Square payment events from a Kafka topic requires you to reason about at-least-once delivery and write working Python that handles late refunds and chargebacks correctly. Candidates who prep SQL and data modeling in isolation, treating coding as a separate skill, miss that Block's payments-specific questions demand both simultaneously. The distribution also quietly rewards anyone who understands the merchant payment lifecycle (authorization through settlement through dispute) because that domain context shows up across nearly every area, from schema grain decisions to PCI-aware column restrictions.

Sharpen your skills on payments-oriented SQL, pipeline, and coding scenarios at datainterview.com/questions.

How to Prepare for Square (Block) Data Engineer Interviews

Block's Bitcoin payments rollout for sellers and its AI voice ordering and inventory tools are reshaping what data engineers actually build day to day. You're not just maintaining batch pipelines for card settlements anymore. Crypto payment rails, AI feature stores for voice ordering, and traditional merchant analytics all coexist, and the teams shipping them are getting leaner, which means each DE owns more surface area than they did two years ago.

The "why Block?" answer that falls flat is any variation of "I'm passionate about fintech and crypto." What separates candidates, from what interviewers on Blind report, is connecting to a specific product moment: how Square Terminal's settlement pipeline directly affects whether a seller can cover next-day payroll, or how Cash App's direct deposit infrastructure serves people who've been shut out of traditional banking. Ground your answer in Block's stated mission of economic empowerment, then tie it to a pipeline you'd actually want to build.

Try a Real Interview Question

1WITH paid_payments AS (
2  SELECT
3    p.payment_id,
4    p.merchant_id,
5    CAST(p.created_at AS DATE) AS txn_date,
6    p.amount_cents
7  FROM payments p
8  JOIN merchants m
9    ON m.merchant_id = p.merchant_id
10   AND m.currency = p.currency
11  WHERE p.status = 'PAID'
12),
13refunds_succeeded AS (
14  SELECT
15    r.payment_id,
16    SUM(CAST(r.refund_amount_cents AS BIGINT)) AS refunded_cents
17  FROM refunds r
18  WHERE r.status = 'SUCCEEDED'
19  GROUP BY r.payment_id
20)
21SELECT
22  pp.merchant_id,
23  pp.txn_date,
24  COUNT(*) AS payment_count,
25  SUM(CAST(pp.amount_cents AS BIGINT)) - SUM(COALESCE(rs.refunded_cents, 0)) AS net_gmv_cents
26FROM paid_payments pp
27LEFT JOIN refunds_succeeded rs
28  ON rs.payment_id = pp.payment_id
29GROUP BY
30  pp.merchant_id,
31  pp.txn_date
32ORDER BY
33  pp.txn_date,
34  pp.merchant_id;

Block's loop asks you to produce working, tested code in Python or Java, not pseudocode sketches. The problems tend to involve data processing logic (deduplication, aggregation over streaming-like inputs) where edge cases around null values and out-of-order records matter more than exotic algorithms. Sharpen that muscle with timed problems at datainterview.com/coding.

Test Your Readiness

If any of those questions tripped you up, work through the payments-domain and pipeline scenario questions at datainterview.com/questions before your loop.