Airbnb Software Engineer (Mid-Level) Interview Preparation Guide

Direct answer. A shape-mismatch error tells you two tensors disagreed in dimension somewhere in the forward pass, but the traceback often points at the operation that FAILED, not the operation that introduced the wrong shape several layers earlier, so the debugging process is really about walking the shape forward from the input until it diverges from what you expect.

Step-by-step approach.

1. Print the input shape first, and compare it against what the first layer actually expects. A surprising number of shape bugs are simply "the input isn't shaped the way I assumed," not a bug in the model at all.
2. Use a model summary tool (or manually print .shape after each layer in a quick forward pass) to see the shape at every stage in one pass, rather than binary-searching by commenting out layers one at a time.
3. Add explicit shape assertions inside custom layers, at the point where a specific shape is assumed (assert x.shape[-1] == self.expected_dim, f"got {x.shape}"). This turns a downstream, confusing shape error into an immediate, precisely-located one the next time the bug is triggered, which pays for itself the first time someone else hits a variant of the same bug.
4. Write a small unit test with a known, fixed input shape that exercises just the suspect layer or block in isolation, rather than the whole model, so you can iterate on the fix without paying the cost of a full forward pass through everything else.

A concrete example of why step 1 matters. A very common real case: a model expects batch-first input (batch, seq_len, features) but receives (seq_len, batch, features) from a data loader or a different framework's convention. The shapes are individually valid tensors, nothing crashes until several layers in when a dimension that "coincidentally" matched for a while finally doesn't, at which point the error message points at a layer far from the true cause (the data loader).

The unit test that prevents recurrence. Something as small as:

def test_encoder_output_shape():
    x = torch.randn(4, 10, 32)  # (batch=4, seq_len=10, features=32), the CONTRACT this layer expects
    out = encoder(x)
    assert out.shape == (4, 10, 64), f"expected (4, 10, 64), got {out.shape}"

run in CI on every change to the layer or anything upstream of it, catches this class of bug the moment a shape contract is violated, rather than three deploys later when someone finally notices predictions look wrong.

Start by framing the problem: sorting files larger than RAM requires minimizing costly disk I/O. The standard solution is an external merge-sort augmented by parallelism, smart buffering, storage choice, and OS tuning.

External merge-sort strategy

• Phase 1 (run generation): Read chunks that fit in memory, sort in-memory, write sorted runs. Use multi-threaded in-memory sort (e.g., parallel quicksort) to utilize CPU while a single thread writes.
• Phase 2 (k-way merge): Merge multiple runs in a single pass using a k-way priority queue. Choose k so that input buffers for each run + output buffer fit in RAM to avoid extra I/O passes. If k is limited, do multi-pass merging.

Parallel I/O

• Overlap computation and I/O: use asynchronous I/O (AIO), prefetch reads while sorting previous chunk, and write runs in background threads.
• Striping across multiple disks (RAID0) or using multiple file descriptors can increase throughput; coordinate merges to read from different devices in parallel.
• For multi-core systems, dedicate threads for I/O vs CPU-bound work to avoid contention.

SSD vs HDD trade-offs

• SSD: much higher IOPS and lower latency, favors many small random reads during k-way merge and supports smaller buffer sizes. But watch for write amplification and endurance—use large sequential writes where possible.
• HDD: high sequential throughput but poor random IOPS. Favor larger, sequential reads/writes and reduce random seeks by increasing buffer sizes and merging runs to reduce passes.

Buffer sizing and layout

• Allocate per-run read buffers sized to amortize seek/latency: for HDDs prefer larger buffers (MBs); for SSDs smaller buffers (hundreds of KB) may be sufficient.
• Output buffer should be large enough to batch writes (tens of MB) to avoid small synchronous writes.
• Choose k = min(number_of_runs, floor((available_RAM - output_buf)/per_run_buf)). Larger k reduces merge passes but increases memory pressure and cache misses.

OS-level tuning

• I/O scheduler: on Linux use noop or deadline for SSDs to avoid unnecessary reordering; for HDDs deadline often helps; avoid cfq for high-throughput batch jobs.
• Read-ahead: increase readahead for HDDs to exploit sequential patterns; for SSDs reduce aggressive readahead to avoid wasting I/O.
• Filesystem: use ext4/xfs with large stripe and journal settings tuned for large files; consider direct I/O (O_DIRECT) to bypass page cache if you manage your own buffers to avoid double-caching.
• AIO and io_uring: prefer io_uring for high-performance async I/O on modern kernels.
• NUMA: pin threads and allocate buffers on local memory nodes to reduce cross-node latency.

Practical checklist

• Maximize sequential access when on HDD; exploit parallel random I/O on SSD.
• Overlap work and I/O with async pipelines.
• Size k and buffers to fit RAM and minimize passes.
• Test with realistic data sizes and use iostat, blktrace, perf, and fio to validate settings and identify hotspots.

This combination reduces disk waits, minimizes passes, and balances CPU, memory, and storage characteristics for efficient large-file sorting.

Direct answer

Five metrics give a fast, honest read on a two-week sprint's health: sprint velocity, burndown rate, escaped defects, cycle time, and blocked days. Each one answers a different question (are we planning realistically, are we on pace day to day, is quality holding up, where is work actually getting stuck, and how much of our slowness is genuinely outside our control), so tracking all five together catches problems that any single metric would miss on its own.

Structured elaboration

Worked example

A team has averaged 32 points over its last 3 sprints. Late in the current 2-week sprint, only 21 points show as done on the burndown, with 2 working days left, a pace that would land well under the historical average if it holds. Cross-checking against blocked days shows 6 person-days lost that sprint to a shared staging environment being down for two separate days, the largest single contributor to the shortfall, and consistent with the same environment appearing as a blocker source in the two prior sprints too, which is exactly the kind of repeating pattern the blocked-days metric is meant to surface as a standing risk rather than sprint-by-sprint bad luck.

Trade-offs and pitfalls

The most common mistake is reacting to a single sprint's velocity dip as if it were a crisis, when a 3-sprint rolling average would show it's within normal variation. A second mistake is tracking these metrics without ever looking at them together: a team can look fine on velocity while escaped defects are quietly climbing, which velocity alone would never reveal. Watch also for treating cycle time and blocked days as the same thing; cycle time includes time genuinely spent working, while blocked days isolates time lost specifically to things outside the team's control, and conflating them hides which lever actually needs pulling.

To merge k sorted arrays in O(n log k) we use a min-heap storing the current smallest candidate from each array (value, array_index, element_index). Repeatedly pop the smallest, append to result, and push the next element from that array.

import heapq

def merge_k_sorted(arrays):
    """
    Merge k sorted arrays into one sorted list.
    Time: O(n log k), n = total elements, Space: O(n + k)
    """
    heap = []
    result = []

    # Initialize heap with first element of each non-empty array
    for i, arr in enumerate(arrays):
        if arr:
            heapq.heappush(heap, (arr[0], i, 0))

    while heap:
        val, ai, idx = heapq.heappop(heap)
        result.append(val)
        # push next element from same array, if any
        if idx + 1 < len(arrays[ai]):
            heapq.heappush(heap, (arrays[ai][idx + 1], ai, idx + 1))

    return result

def merge_first_m(arrays, m):
    """
    Return first m smallest elements without merging fully.
    Time: O(m log k), Space: O(m + k)
    """
    heap = []
    result = []

    for i, arr in enumerate(arrays):
        if arr:
            heapq.heappush(heap, (arr[0], i, 0))

    while heap and len(result) < m:
        val, ai, idx = heapq.heappop(heap)
        result.append(val)
        if idx + 1 < len(arrays[ai]):
            heapq.heappush(heap, (arrays[ai][idx + 1], ai, idx + 1))

    return result

Key points:

• Heap size ≤ k, each push/pop is O(log k).
• Full merge: total n pops → O(n log k). First-m: only m pops → O(m log k).
  Edge cases: empty arrays, m = 0, m > n (returns all elements). Alternative: pairwise merge (O(n log k) too) but less memory-friendly and slower constants.

Direct answer: An Employee Resource Group (ERG) is a voluntary, employee-led group organized around a shared identity or affinity (for example, a Women in Engineering group, a Black employee network, a Parents/Caregivers group, or an LGBTQ+ employee group), providing community, mentorship, and often a channel for feedback to leadership on issues affecting that group; an individual contributor can support one technically (building or maintaining a small internal tool the group needs, like an event sign-up or resource directory) and non-technically (mentoring within the group, showing up to events, or acting as an ally who amplifies the group's asks in spaces the group itself isn't in).

Structured elaboration:

1. What an ERG is and isn't. It's a voluntary community and support structure, not an official decision-making body with authority over HR policy, though healthy organizations do give ERGs a real feedback channel to leadership; it's not a substitute for the company's own accountability on representation and inclusion, and treating it as such (outsourcing DEI work to unpaid volunteer labor) is a common organizational failure mode.
2. Technical support example. Build or maintain a small internal tool the ERG actually needs: an event RSVP page, a searchable mentor-matching directory, or automating a manual process (like tracking event attendance) the group's volunteer organizers were doing by hand. This is real engineering work with a clear, appreciative user base, and a good way for a technical IC to contribute meaningfully without needing to be the group's public face.
3. Non-technical support example. Show up consistently to events (attendance itself signals allyship and gives the group visibility), volunteer as a mentor within the ERG's mentorship track if one exists, or use your own standing to amplify the group's asks in rooms the group's members aren't in (sponsorship: advocacy on someone's behalf, in their absence).
4. Measurable outcome. A concrete signal an IC could track for their own contribution: whether the tool they built is actually used (event sign-ups via the tool versus the old manual process, adoption rate); for mentorship, a simple before/after check-in with the mentee on whether the relationship felt useful, since ERG mentorship impact is best measured qualitatively at the individual level rather than with an invented aggregate statistic an individual contributor wouldn't actually have access to.

Worked example: An engineer notices their company's ERG for parents/caregivers manually tracks event RSVPs via a shared spreadsheet that frequently gets out of sync, causing confusion about headcount for catered events. They build a small internal form-and-dashboard tool over a couple of evenings, cutting RSVP-tracking overhead for the volunteer organizers from roughly an hour per event to a few minutes, and separately volunteer as a mentor for a newer parent navigating return-to-work logistics, checking in with them after two months on whether the mentoring relationship has been useful.

Trade-offs and pitfalls: Be careful not to frame ERG support as a substitute for the company's own investment (budget, paid organizer time, leadership sponsorship); an ERG that runs entirely on unpaid volunteer labor, however well-intentioned the individual contributions, is not a sustainable or fully credible signal of organizational commitment, which connects to the broader question of institutionalizing that work. Also avoid treating ERG participation as something only members of the group's identity should do; ally participation (attending, amplifying, technical support) matters and shouldn't require group membership.

Direct answer

Decide by comparing the investment's expected payoff against its real cost, which is time and attention pulled from delivery, not just money, then bring your manager a specific, time-boxed ask paired with a coverage plan rather than an open-ended request.

Structured elaboration

• Name the investment type explicitly, since the shape of the ask differs: a certification (weigh its actual return on investment, or ROI, against the time and fee cost), a formal advanced degree (a far larger, multi-year time and money commitment for a credential), an internal on-the-job rotation (trades delivery time on your current team for exposure elsewhere), or simply protecting a fixed number of weekly hours split across growth domains.
• Compute the real cost honestly. If the ask is a fixed weekly-hours budget, name explicitly what shrinks to make room for it; a request that doesn't name its own trade-off reads as costless and gets challenged later.
• The negotiation lever that works is a bounded pilot: a defined number of weeks, a specific hours-per-week figure, a defined coverage plan for what you'd otherwise be doing, and a checkpoint partway through to reassess, rather than an open-ended protected-time request.
• If the ask involves protecting time against on-call or delivery pressure specifically, address it directly: name how coverage continues (pairing, documentation, swapping on-call windows) rather than letting the ask sound like a straight subtraction from the team's capacity.

Worked example

I wanted to protect a few hours a week for a structured certification relevant to where I wanted to grow, but I didn't just ask for the time. I brought my manager a specific ask: this many hours a week, for this many months, here's exactly what shrinks to make room for it, and here's how on-call coverage stays intact while I'm doing it. I framed it as a pilot with a checkpoint partway through: if my delivery velocity dropped noticeably, we'd pause and reassess rather than quietly abandoning either the study time or the delivery commitments. That framing made it an easy yes, because the cost was explicit and bounded instead of open-ended.

Trade-offs & pitfalls

• Asking for time without naming what shrinks to make room for it is the single biggest reason these requests get pushback.
• Treating a degree, a certification, an on-the-job rotation, and simply protected weekly hours as interchangeable asks misses that they carry very different costs and need different negotiations.
• Framing the investment purely as personal benefit rather than tying it to team or delivery value makes it harder to defend when priorities tighten.
• No checkpoint means no graceful way to pause if delivery genuinely suffers; always build in a reassessment point.

Direct answer

Waiting stops being the right call once the delay is on your critical path (the chain of work that directly determines your deadline) with no updated ETA, or once the cost of continuing to wait (rework, workarounds, compounding risk) is clearly larger than the cost of escalating. Decide the trigger in advance, not in the moment, and escalate by framing it around the shared deadline and offering to help unblock, not by assigning blame, so the relationship survives the conversation.

Structured elaboration

1. Set the trigger before you need it. At the point you first take on a dependency, agree on what "stalled" means and when you'll escalate if there's no movement, for example, "if there's no updated ETA by [date], I'll raise it." Deciding this ahead of time keeps the eventual call from being an emotionally loaded, in-the-moment judgment.
2. Watch for the signals that waiting has become the wrong call, even without a pre-set trigger: no visible progress or updated estimate, the delay has moved onto your own critical path, you're already absorbing compounding cost (rework, a growing workaround), or the nature of their blocker changed without anyone telling you.
3. Escalate at the right altitude, in order. Start with a direct conversation with the owner (not their manager first, which reads as going around them), then their lead if that doesn't move things, then a cross-functional or executive conversation only if the first two steps don't resolve it. Skipping straight to the top burns trust even when you're right to escalate.
4. Frame the escalation around the shared goal. Bring what you've tried and the concrete impact of the delay, and lead with an offer to help (extra hands, a clearer spec, a joint troubleshooting session) rather than a demand for status. This keeps the conversation collaborative instead of adversarial.
5. When the dependency is an external vendor rather than an internal team, the escalation lever is fundamentally different. There's no peer relationship conversation to have in the same sense: the path runs through contract renegotiation (invoking SLA, or service level agreement, terms, escalating through the vendor's account team) and executive/customer communication about timeline impact, because a vendor delay usually has stakeholders beyond your own working team (customers waiting on the date, your own leadership needing to manage expectations upward). The internal escalation ladder in step 3 assumes a peer relationship you can repair with tone and framing; the vendor case assumes a commercial relationship you manage with contract terms and proactive, honest communication about the schedule impact instead.

Worked example

Two weeks into waiting on an internal platform team's API, with no updated ETA since the first week and the launch date now two weeks out, the trigger from step 1 (no ETA update within a week) has already been crossed. The escalation opens with the owner directly: "This is now going to affect our launch date. What's actually blocking it, and is there anything I can do to help, pair on it, provide test data, take a piece of the work?" Only if that doesn't produce movement within a short, stated window does it go to their lead, framed the same way: shared deadline, concrete impact, an offer to help.

If instead the dependency were owned by an external vendor who'd gone quiet for two weeks on a contracted deliverable, the move isn't a peer conversation with an individual, it's raising the delay through the account relationship against the SLA in the contract, while separately and proactively telling internal leadership (and, if relevant, the customer waiting on the date) what the timeline impact now looks like, rather than continuing to absorb the delay silently and hoping the vendor resolves it before anyone notices.

Trade-offs & pitfalls

• Pitfall: escalating without a pre-agreed trigger, so the decision looks reactive or, worse, personal, when it happens.
• Pitfall: skipping escalation levels internally (going straight to a director) when a direct conversation with the owner hadn't been tried yet, damaging a relationship you'll need again.
• Pitfall: treating a vendor delay like an internal one, i.e., waiting patiently and being "collaborative" with a counterparty who has no equivalent incentive to preserve the relationship the way an internal peer does.
• Senior differentiator: pre-negotiating the escalation threshold when the dependency is first created, not two weeks into silence, and recognizing early which kind of dependency (peer relationship vs. commercial contract) you're actually managing, since that changes which lever you reach for.

Direct answer
Polyglot persistence means each bounded context picks the storage technology that fits its own access pattern (a graph database for a recommendations service, a document store for a catalog service, a relational database for a transactional payments service), while single-database-technology-per-bounded-context still gives each service its own schema and its own database instance, but standardizes on one storage technology (usually relational) across all of them. Polyglot persistence is justified when a service's access pattern is genuinely a poor fit for the standard choice, not merely because a newer technology looks appealing.

Structured elaboration
The case for polyglot persistence: a service whose core operation is graph traversal (like finding connections between entities several hops apart) performs and scales dramatically better on a graph database than forcing that traversal into relational joins; a service that's fundamentally a high-write-throughput time series (metrics, events) is a much better fit for a time-series-optimized store than a general relational database. The case against defaulting to it everywhere: every additional storage technology in production is a new thing to operate (backup strategy, failover strategy, monitoring, and staff who actually know how to run it well), and a team spread across five different database technologies has a much smaller bench of people who can debug any one of them under pressure than a team standardized on one or two.

The trade-offs concretely: operational overhead scales roughly with the number of distinct storage technologies in production, not the number of service instances, so ten services all using the same relational database technology (even in separate schemas) is operationally simpler than three services each using a different specialized store. Developer autonomy goes the other way: a team that owns its own service and its own storage choice can move faster on its own roadmap without waiting for a shared database team's priorities, but that autonomy is exactly what makes a later data-migration or recovery effort harder, since there's no common tooling or shared expertise across a genuinely polyglot fleet. Backup, restore, and recovery complexity multiplies with each distinct technology, since a well-tested disaster-recovery runbook for a relational database usually doesn't transfer to a graph database or a time-series store.

Worked example
A pragmatic middle ground: standardize on one or two default storage technologies (say, a relational database for anything with clear transactional needs, and a document store for anything schema-flexible) that cover the vast majority of services, and reserve a genuinely specialized technology (graph, time-series, search index) for the specific services whose access pattern would be actively painful on the default, requiring an explicit justification and sign-off rather than letting every team pick whatever's currently popular.

Trade-offs and pitfalls
The failure mode on the polyglot side is technology sprawl: a dozen services each independently choosing whatever database is trendy, with no shared operational playbook, so an incident in any one of them requires expertise the rest of the org doesn't have. The failure mode on the standardization side is forcing an access pattern that's fundamentally a poor fit (heavy graph traversal, for example) into a relational model, producing queries that are slow, hard to maintain, and eventually get worked around with ad hoc caching layers that recreate the complexity a purpose-built store would have handled natively.

Direct answer

A grid is just a graph in disguise: each open cell is a node, and each cell is connected by an edge to its up-to-four open neighbors (up, down, left, right). Once that reframing is made, "shortest path on a grid" is the exact same problem as breadth-first search (BFS) shortest path on any unweighted graph, using the grid's implicit adjacency rule instead of an explicit adjacency list. Run BFS from start, and the moment goal is dequeued (or discovered), its recorded distance is the answer; return -1 if the queue empties first.

Structured elaboration

The only real design choices are how to represent "distance so far" and how to avoid materializing an explicit adjacency list (which would waste memory when the neighbor rule is a fixed, four-direction offset computable on the fly). The implementation below carries the running distance alongside each queued cell and validates bounds, blockage, and same-cell/blocked-goal cases up front.

Worked example

from collections import deque
from typing import List, Tuple

def shortest_grid_path(grid: List[List[int]], start: Tuple[int, int], goal: Tuple[int, int]) -> int:
    # 4-direction BFS shortest path length on a binary grid (0 = open, 1 =
    # blocked). Returns the number of steps (edges), or -1 if unreachable
    # or if start/goal is itself blocked.
    if not grid or not grid[0]:
        return -1
    R, C = len(grid), len(grid[0])
    sr, sc = start
    gr, gc = goal
    if not (0 <= sr < R and 0 <= sc < C and 0 <= gr < R and 0 <= gc < C):
        return -1
    if grid[sr][sc] == 1 or grid[gr][gc] == 1:
        return -1
    if start == goal:
        return 0

    visited = [[False] * C for _ in range(R)]
    visited[sr][sc] = True
    q = deque([(sr, sc, 0)])
    while q:
        r, c, d = q.popleft()
        for dr, dc in ((1, 0), (-1, 0), (0, 1), (0, -1)):
            nr, nc = r + dr, c + dc
            if 0 <= nr < R and 0 <= nc < C and not visited[nr][nc] and grid[nr][nc] == 0:
                if (nr, nc) == (gr, gc):
                    return d + 1
                visited[nr][nc] = True
                q.append((nr, nc, d + 1))
    return -1

if __name__ == "__main__":
    grid = [
        [0, 0, 0, 0],
        [1, 1, 0, 1],
        [0, 0, 0, 0],
        [0, 1, 1, 0],
    ]
    print("start=(0,0) goal=(3,3):", shortest_grid_path(grid, (0, 0), (3, 3)))
    print("start=(0,0) goal=(1,0) [blocked goal]:", shortest_grid_path(grid, (0, 0), (1, 0)))
    print("start=(0,0) goal=(0,0) [same cell]:", shortest_grid_path(grid, (0, 0), (0, 0)))

    fully_blocked = [[0, 1], [1, 0]]
    print("no path around a wall:", shortest_grid_path(fully_blocked, (0, 0), (1, 1)))

    def full_bfs_dist(grid, start):
        R, C = len(grid), len(grid[0])
        dist = {start: 0}
        q = deque([start])
        while q:
            r, c = q.popleft()
            for dr, dc in ((1,0),(-1,0),(0,1),(0,-1)):
                nr, nc = r+dr, c+dc
                if 0<=nr<R and 0<=nc<C and grid[nr][nc]==0 and (nr,nc) not in dist:
                    dist[(nr,nc)] = dist[(r,c)] + 1
                    q.append((nr,nc))
        return dist

    ref = full_bfs_dist(grid, (0,0))
    print("Matches independent full-BFS distance map:", ref.get((3,3)) == shortest_grid_path(grid, (0,0), (3,3)))

Output (actually executed with python3):

start=(0,0) goal=(3,3): 6
start=(0,0) goal=(1,0) [blocked goal]: -1
start=(0,0) goal=(0,0) [same cell]: 0
no path around a wall: -1
Matches independent full-BFS distance map: True

The full_bfs_dist helper independently computes the distance to every reachable open cell (not just the goal) and is cross-checked against the goal-seeking function's result for (3, 3), confirming both agree on the answer of 6 steps for that grid.

Complexity

Time $O(R \times C)$: each of the grid's cells is enqueued and dequeued at most once, and each dequeue does 4 constant-time neighbor checks. Space $O(R \times C)$ for the visited matrix and, in the worst case, the queue.

Edge cases

• Empty grid or empty row: not grid or not grid[0] catches both and returns -1 rather than raising on len(grid[0]).
• Start or goal out of bounds: validated explicitly before any traversal begins.
• Start or goal itself blocked: validated explicitly (a blocked cell cannot be a valid position to start or end at), rather than letting the BFS silently never enqueue it and return -1 for the wrong reason.
• start == goal: returns 0 directly, since this is a zero-edge path and would otherwise never get "discovered" by the neighbor-expansion loop (which only looks outward from the current cell, never re-examines the cell itself).

Trade-offs and pitfalls

• Common mistake: allowing 8-direction movement (including diagonals) when the problem specifies 4-direction, or vice versa; the neighbor offsets ((1,0),(-1,0),(0,1),(0,-1)) are the entire contract here, and getting this wrong silently produces a plausible-looking but incorrect shortest distance rather than an error.
• Common mistake: mutating the input grid in place to mark visited cells (for example, setting visited cells to 1) instead of using a separate visited matrix. This works for a single call but corrupts the caller's grid for any subsequent use, and fails outright if the caller expects to run multiple queries against the same grid.
• Optimization for very large grids: bidirectional BFS (searching outward from both start and goal simultaneously, stopping when the two frontiers meet) can substantially reduce the number of cells visited for grids where the shortest path is long relative to the grid's size, since two smaller expanding regions cover less total area than one large one before meeting. A commonly asked variant frames this as an m x n grid going corner to corner, which is simply the special case start=(0,0), goal=(R-1,C-1); nothing else about the algorithm changes.
• A as a further optimization:* for very large grids where most exploration is wasted moving away from the goal, A* with an admissible heuristic (Manhattan distance on a 4-direction grid) can prune the search space substantially versus plain BFS, at the cost of needing a priority queue and a heuristic function; this only pays off when the grid is large enough that the pruning outweighs the heap's constant-factor overhead.

Direct answer

Below is a script that reads git diff --numstat from STDIN (standard input, the default input stream a program reads from when data is piped into it) and emits one JSON object with total additions, total deletions, files changed, and any files whose additions exceed 200. Wiring it into continuous integration (CI, the automated build/test pipeline that runs on every push) means piping the pull request (PR)'s diff into the script and using its output to apply a label through the CI platform's API.

Structured elaboration

Approach

• git diff --numstat emits one tab-separated line per changed file: <added>\t<deleted>\t<filename>
• Binary files report - for added and deleted instead of a number, this must be handled explicitly rather than crashing the parser
• Parse each line, accumulate totals, and separately collect filenames whose additions exceed the 200-line threshold

Code

import sys
import json


def parse_numstat(lines):
    total_additions = 0
    total_deletions = 0
    files_changed = 0
    large_files = []
    for line in lines:
        line = line.rstrip("\n")
        if not line.strip():
            continue
        parts = line.split("\t")
        if len(parts) != 3:
            continue
        added_str, deleted_str, filename = parts
        files_changed += 1
        # binary files report '-' for added/deleted; treat as 0 rather than crash
        added = int(added_str) if added_str != "-" else 0
        deleted = int(deleted_str) if deleted_str != "-" else 0
        total_additions += added
        total_deletions += deleted
        if added > 200:
            large_files.append(filename)
    return {
        "total_additions": total_additions,
        "total_deletions": total_deletions,
        "files_changed": files_changed,
        "large_files": large_files,
    }


def main():
    lines = sys.stdin.readlines()
    result = parse_numstat(lines)
    print(json.dumps(result))


if __name__ == "__main__":
    main()

CI integration

• In CI, compute the numstat against the PR's actual merge base (for example git diff --numstat origin/main...HEAD, or the CI platform's own base-comparison ref) and pipe it into the script
• Parse the JSON output and use a non-empty large_files list, or total_additions crossing a team-chosen threshold, to apply a "large-pr" label through the CI platform's API (for example the GitHub CLI's gh pr edit --add-label, or a direct REST call)
• Run this as an early, cheap CI step, before slower checks, so the label is visible to reviewers as soon as the PR opens

Worked example

I ran this exact script against the following sample git diff --numstat input:

5	2	src/app.py
0	0	README.md
250	10	src/big_module.py
-	-	assets/logo.png

Piped through the script (... | python3 diffstats.py), the actual output was:

{"total_additions": 255, "total_deletions": 12, "files_changed": 4, "large_files": ["src/big_module.py"]}

That matches the arithmetic by hand: additions 5 + 0 + 250 + 0(binary) = 255, deletions 2 + 0 + 10 + 0(binary) = 12, four lines means four files changed, and only src/big_module.py has additions (250) over the 200 threshold.

Trade-offs and pitfalls

• numstat reports - for binary files; treating that as 0 additions is a deliberate choice so the parser doesn't crash, but it means a genuinely large binary change (a big generated asset) won't trip the large-file flag
• A pure line-count threshold doesn't capture every sense of "large": 250 lines of an auto-generated config file is not the same risk as 250 lines of hand-written logic; use this as a first-pass signal, not the only one
• Commits within the PR don't matter to this script, since it's comparing the merge base to the tip, which is usually what you want for a PR-level label
• If the base ref is stale (a local branch that hasn't been rebased), the numbers will be wrong; make sure CI diffs against the PR's true merge base, not a stale local reference