Senior Data Engineer at Apple: Comprehensive Interview Preparation Guide

Direct answer. Even with a matching index available, a planner can rationally prefer a sequential scan for several reasons: the predicate isn't actually selective enough for the specific data distribution, the statistics are stale, the query is wrapped in a way that defeats the index (a function or type mismatch on the indexed column), the index simply doesn't cover this particular query shape, or the table is small enough that a scan is cheaper regardless.

Structured elaboration.

1. Low selectivity: if the predicate matches a large fraction of the table (say, more than 5-15%, depending on the engine's cost model), a scan that reads pages sequentially can beat an index scan that does many scattered lookups, even though the index scan visits fewer ROWS. Check this by running a plain COUNT(*) with the same predicate and comparing it to the table's total row count.
2. Stale statistics: if the optimizer's stored row-count estimate for the predicate is wrong (too high), it may believe the predicate is unselective even though it currently isn't. Check this by comparing EXPLAIN's estimated rows to EXPLAIN ANALYZE's actual rows for the same predicate.
3. A non-sargable predicate: wrapping the indexed column in a function, or comparing it to a value of a different type that forces an implicit cast, can make the index unusable for that specific query even though the index itself is fine. Check the WHERE clause literally for any function call or cast around the column.
4. The index doesn't match the query: if the index is on a different column, or a composite index whose leading column isn't part of this query's predicate, it can't help this query even though it looks superficially related. Check the exact columns and column order of the existing index against the query's actual predicate.
5. Table (or matching subset) is genuinely small: below some row-count threshold, the fixed overhead of an index lookup exceeds the cost of just reading everything, so a scan is the objectively correct choice and nothing is actually wrong.

Worked example. For a 50-million-row table where a predicate matches roughly 1% of rows (500,000 rows), that's usually still selective enough that a correctly-matching, non-wrapped index should win; if the planner is still choosing a scan in that situation, reasons 2, 3, or 4 above are the most likely explanations, and reason 1 (genuinely low selectivity) is the least likely at that match rate.

Trade-offs and pitfalls. It's tempting to treat "the planner chose a scan" as automatically wrong and reach immediately for a hint to force the index; check the five reasons above first, since forcing an index that the optimizer correctly avoided (because it truly is more expensive for this query) makes things worse, not better.

Direct answer

Integrate semi-structured or unstructured sources (JSON events, support tickets, web logs) into an analytics warehouse by landing them in their native shape first, then extracting a small, stable set of frequently-queried fields into real typed columns while keeping the full original payload accessible for anything not yet promoted, so both BI reporting and model-feature pipelines can rely on the same underlying data without either being blocked on a full upfront schema.

Structured elaboration

• Land raw, extract selectively: ingest the raw JSON/text payload into the warehouse largely as-is (a JSONB or VARIANT column, or a raw-text column for unstructured text), and only promote specific fields to their own typed, indexed columns once their query pattern is known and stable; this avoids blocking ingestion on a schema decision for every field a source might ever emit.
• Serving BI reporting: BI tools generally need typed, indexable columns for fast filtering and aggregation, so the promoted-fields layer (not the raw payload) is what most dashboards should query against; a view or a curated table exposes the promoted fields plus any commonly-needed derived fields (a sentiment score computed from support-ticket text, say) without every analyst needing to know how to query the raw JSON.
• Serving model features: ML feature pipelines often need BOTH the promoted structured fields AND access to the raw payload (to derive new features later that weren't anticipated at promotion time, such as extracting a new entity from raw ticket text), so keeping the raw payload retained and queryable, not discarded after extraction, matters specifically for this consumer.
• Unstructured text specifically (support tickets, free-text logs): typically needs an additional processing step beyond simple field extraction, such as NLP-derived structured fields (sentiment, extracted entities, a category classification) computed by a pipeline and stored as their own columns, since the raw text itself isn't directly filterable or aggregable the way a JSON field's value is.

Worked example

For web-log JSON events with a properties payload that varies by event type: a small set of near-universal fields (user_id, event_type, event_time) gets promoted to real columns immediately, since virtually every downstream consumer filters or groups by them; category-specific fields inside properties (say, a product_id present only on purchase-type events) stay in the JSON payload until a specific dashboard or feature pipeline demonstrates a stable, recurring need for it, at which point it's promoted too. This staged-promotion approach means the schema itself becomes a living record of which fields have proven valuable enough to warrant first-class treatment, rather than a guess made once at ingestion time.

Trade-offs and pitfalls

• The main risk of landing everything raw with no promotion discipline at all is that every BI query and every feature pipeline ends up independently parsing the same JSON paths with slightly different conventions (one query treats a missing field as NULL, another as an error), producing subtly inconsistent results across consumers for what should be the same underlying fact; promoting a field is what gives it one canonical, shared definition.
• The main risk of promoting too aggressively (extracting every field immediately) is reintroducing the schema-on-write rigidity this whole approach was meant to avoid, forcing a migration every time a new source or a new field shows up, which is exactly the friction semi-structured landing was chosen to prevent.
• Retaining the raw payload alongside the promoted fields has a real storage cost, but discarding it prematurely forecloses future feature engineering or debugging that needs to go back to the original, unprocessed data, which is usually the more expensive mistake of the two.

Direct answer

Model the many-to-many relationship with a bridge table between the fact and the promotion dimension: promotion_bridge(order_line_key, promotion_key, allocation_weight), letting one order line reference multiple promotions (and one promotion apply to many order lines). For overlapping promotions, define an explicit attribution rule (equal split, priority-based, or weighted) rather than letting the join silently double- or under-count revenue.

Structured elaboration

• Bridge table structure: rather than a single promotion_key column on the fact (which can't represent more than one promotion per line), introduce a bridge table with one row per (order line, promotion) pair, plus an allocation_weight column so revenue can be split fairly when multiple promotions apply.
• Attribution for overlapping promotions: a common approach is equal-weight split (two applicable promotions each get 50% of the attributed revenue), or priority-based (the highest-priority promotion gets 100%, others get 0%), chosen based on what the business actually wants to measure (marketing spend efficiency usually wants weighted attribution; simple "did this promotion drive a sale" reporting might prefer priority-based).
• Querying attributed revenue: SELECT b.promotion_key, SUM(f.line_amount * b.allocation_weight) FROM order_line_fact f JOIN promotion_bridge b ON f.order_line_key = b.order_line_key GROUP BY b.promotion_key, where the weight ensures the SUM across all promotions for one order line equals the line's actual revenue, not a multiple of it.

Worked example

promotion_bridge:
order_line_key | promotion_key | allocation_weight
101            | P1            | 0.5
101            | P2            | 0.5
102            | P1            | 1.0

Order line 101 has $100 revenue and two applicable promotions, each attributed $50 (100 * 0.5); order line 102 has $80 revenue and one promotion, attributed the full $80. Summing attributed revenue across ALL promotions for line 101 (50 + 50 = 100) correctly reconciles to the line's actual $100, confirming the weights sum to 1.0 per fact row, the key invariant that prevents double-counting.

Trade-offs and pitfalls

The most common bug with bridge tables is joining the fact to the bridge and then summing the RAW line_amount (instead of the weighted amount) grouped by promotion, which double- or triple-counts the line's revenue once per matching promotion; always multiply by the allocation weight, and validate that weights sum to 1.0 per fact row as a standing data-quality check.

Requirements & goals:

• Enable self-serve analytics with low friction
• Prevent data exfiltration and regulatory violations (PII, PCI, HIPAA)
• Provide auditable, enforceable controls without blocking developer velocity

Architecture & governance summary:

• Central metadata/catalog (Data Catalog + Policy Engine) stores dataset sensitivity labels, retention, allowed uses, and transformation lineage.
• Policy engine integrates with compute/data plane (query engines, data warehouse, object storage) and enforcement points (query rewrite, proxy, access gateway).

IAM patterns:

• Role-Based Access Control (RBAC) for coarse-grained permissions (who can read/write catalogs, manage pipelines, run jobs).
• Attribute-Based Access Control (ABAC) for fine-grained, dynamic decisions — evaluate user attributes (role, team, clearance), resource attributes (sensitivity, jurisdiction), and environment attributes (network, device posture).
• Combine RBAC+ABAC: RBAC grants baseline capabilities; ABAC enforces dataset-level rules (e.g., analysts in EU can access aggregated EU datasets only).
• Short-lived credentials & workload identities (OIDC, IAM roles for service accounts) to avoid long-lived keys.

Data protection: dynamic masking & tokenization

• Classification-driven masking policies in the policy engine. Enforce at query-time (dynamic masking) for interactive queries, returning redacted values unless elevated privileges present.
• Deterministic tokenization for joinable PII (replace SSN with reversible tokens stored in HSM/KMS-backed vault); irreversible hashing for analytics where re-identification isn't needed.
• Apply masking/tokenization plugins in query engines (Presto/Spark), and at ingestion (for ELT pipelines) where appropriate.

Runtime monitoring & anomaly detection

• Centralized logging of all data access events (who, what, when, dataset, query text, row counts, result size).
• Streaming SIEM integration + behavior baselines per user/service: typical query patterns, data volume, time-of-day.
• Anomaly detection rules: sudden high-volume exports, queries that select raw PII columns, cross-jurisdiction joins flagged by policy.
• Automated responses: throttle/kill suspicious jobs, require justification ticket, escalate to data stewards, revoke temporary tokens.
• Periodic attestation & sampling for policy effectiveness; audit-ready immutable logs (WORM).

Balancing productivity & security

• Self-serve flows: catalog search with automatic “actions” (request access, request tokenization, run on masked view). Provide sandboxed datasets with synthetic/anonymized data for dev work.
• Default-deny but provide low-friction exceptions: automated approvals for low-risk requests (time-limited), fast human-in-the-loop for borderline cases.
• Developer ergonomics: SDKs and templates that invoke policy engine transparently (e.g., auto-apply masking via JDBC/ODBC driver). Clear docs, examples, and SLAs for access requests.
• Measure: time-to-access, number of manual reviews, false positives in anomaly detection; iterate to reduce lead time while keeping risk metrics acceptable.

Operational considerations & trade-offs:

• Latency vs enforcement: query-time masking adds cost/latency; use pre-masked materialized views for high-performance paths.
• Complexity vs security: ABAC provides precision but needs reliable attribute sources (HR, SSO); invest in attribute hygiene.
• Key management: use cloud KMS/HSM, rotate keys, and strictly control token vault access.

This design gives analysts fast, auditable access while preventing exfiltration through layered IAM, runtime enforcement, dynamic data protection, and automated monitoring.

Situation: Last year our team needed to add a new enrichment step to a user-event pipeline that joins third-party vendor data. The domain (vendor schema and failure modes) was ambiguous and I had one junior data engineer available to own the work.

Task: I asked them to deliver a tested, deployable enrichment job in two sprints that preserved existing SLAs and allowed safe rollback if vendor data caused issues.

Action:

• Set clear expectations: defined acceptance criteria (no data loss, latency increase <10%, tests pass, documented runbook) and milestones for design review and staging run.
• Defined guard rails:
  • Unit + integration tests (pytest + local Spark) and data-contract checks using Great Expectations for schema and value ranges.
  • Monitoring: instrumented metrics (Airflow task duration, success rate, row-count deltas) sent to Prometheus/Grafana and alerts for anomalies.
  • Rollback plan: feature-flagged enrichment and a configuration switch to bypass vendor join; automated backfill script prepared.
• Empowered decision-making: gave them authority to choose implementation (Spark vs. dbt) and run the staging job; I reviewed designs and suggested trade-offs but didn’t mandate details.
• Balanced oversight: weekly checkpoints and a mid-sprint demo; I paired for the first staging run and let them run production cutover with me available on-call.

Result: The engineer delivered the job on time; initial production runs revealed a vendor schema edge case caught by GE tests and alerting — we flipped the feature flag and fixed parsing without customer impact. The engineer gained confidence and later led two more pipeline features.

This taught me structured delegation—clear criteria, safety nets, and lightweight checkpoints—enables autonomy in ambiguous domains while minimizing risk.

A backup is a point-in-time copy, taken on a schedule and stored separately from the live system, that you restore from after something goes wrong. Replication is a continuously (or near-continuously) updated copy of the current state, kept on standby to take over as the live system. The distinction that matters most in practice: replication faithfully copies whatever the primary does, including its mistakes, while a backup gives you a version of the data from before the mistake happened.

Comparing the two

When to rely on backup-based restore instead of replication

Reach for a backup restore when the failure is a logical one: someone ran a bad migration, a bug silently corrupted rows, or ransomware encrypted the data. Replication doesn't help here, and can actively hurt, because it will faithfully copy the corrupted or encrypted state to the replica just as reliably as it copies good writes. This is also why backups need to be immutable or air-gapped (physically or logically disconnected from any network the production environment can reach, so a compromised production system has no path to alter or delete them), not just "another copy": if a backup is reachable and mutable from the same compromised environment, it's not meaningfully protecting against the ransomware scenario it exists for.

Worked example: why backup-only can't meet a tight recovery target

Take a 500 GB primary database and a realistic restore throughput of 200 MB/s (both pinned as inputs to this estimate, not a measured benchmark of any specific system):

That's before accounting for the time to detect the failure and kick off the restore at all. If the recovery requirement is anywhere near a 5-10 minute RPO/RTO, backup-and-restore alone structurally cannot meet it at this data size and throughput, no matter how good the runbook is; the bottleneck is physical (bytes per second), not procedural. This is the concrete reason cross-region replication exists alongside backups rather than instead of them: replication gets the speed (a replica is already there, ready to promote), backups get the safety net (a clean point to roll back to when the live data itself, replicated or not, turns out to be wrong).

Trade-offs and pitfalls

The common mistake is treating replication as a backup substitute because it "keeps a copy of the data": it does, but that copy has zero lag on propagating mistakes, which is exactly the property a backup needs to not have. The pattern that actually works combines both: replication (in-region synchronous, cross-region async) for fast failover and a tight RPO on infrastructure failures, plus regular immutable, tested backups for the logical-error and ransomware case replication can't cover. "Tested" is doing real work in that sentence too: a backup nobody has restored from recently is a backup whose actual restore time and integrity are both unverified, and 42.7-minute math on paper is worthless if the real restore process has never been run end-to-end.

Direct answer

For 200 million monthly active users (MAU) and 10,000 writes/sec, a pure fan-out-on-write pushes every new post into every follower's feed at write time, buying very low read latency at the cost of massive write amplification and storage. Pure fan-out-on-read defers that work to feed-view time, keeping writes cheap but making every read do more work. A celebrity account with millions of followers breaks the pure push model outright, which is why the practical answer is a hybrid: push for ordinary accounts, pull (or a separate merge step) for very high-fan-out accounts.

Structured elaboration

The decision criterion is the read:write ratio implied by a given account's follower count, not a single global choice: an account followed by 200 people generates trivial fan-out and huge read-latency benefit from push; an account followed by millions generates enormous fan-out for a benefit (marginally faster reads for those followers) that pull-at-read can approximate at read time instead.

Worked example

At 10,000 writes/sec, assume (illustrative, pinned input) an average of 300 followers per post for non-celebrity accounts:
$\text{fan-out ops/s} = 10{,}000 \text{ writes/s} \times 300 \text{ avg followers} = 3{,}000{,}000 \text{ inbox writes/s}$
That is the write-amplification cost a pure push model pays continuously just for ordinary accounts.

Now take one celebrity post going to 5 million followers, and assume (illustrative) a fan-out cluster capable of sustaining 500,000 inbox writes/s:
$\text{time to fan out one celebrity post} = \frac{5{,}000{,}000 \text{ followers}}{500{,}000 \text{ writes/s cluster capacity}} = 10 \text{ s}$
A single celebrity post would take roughly 10 seconds to fully propagate through push fan-out, and that's before accounting for every other post competing for the same fan-out capacity at the same time. This is the concrete reason celebrity accounts change the answer: pushing their posts synchronously into millions of inboxes is not just expensive, it measurably delays delivery to everyone else sharing that fan-out capacity.

Trade-offs & pitfalls

• Treating fan-out-on-write and fan-out-on-read as a single global choice, rather than a per-account decision keyed on follower count, is the most common shallow answer.
• A hybrid design still needs a merge step at read time for celebrity posts, so pull-style merge logic doesn't disappear; it just gets scoped to a small fraction of accounts instead of all of them.
• Async, idempotent fan-out pipelines are required regardless of strategy, because retries and partial failures are certain at this scale; a synchronous fan-out-on-write implementation is a reliability risk independent of the storage trade-off.
• Caching the celebrity's own recent posts aggressively (rather than fanning them out) reduces the read-time merge cost without reintroducing full push fan-out.

Direct answer

Keeping PII (personally identifiable information) out of pipeline telemetry requires masking or redaction as close to the SOURCE of the sensitive data as practical, validated by an automated check that actively scans telemetry for leaked PII patterns rather than trusting that masking rules alone are sufficient, since a masking rule can have gaps that only an active check would catch.

Structured elaboration

• Enforcement point choice: masking at the CLIENT/producer (before the sensitive value ever leaves the originating service) is the strongest guarantee, since the sensitive data literally never enters the telemetry pipeline, but requires instrumenting every producer correctly, a gap in even one producer's masking logic leaks through completely undetected by any downstream control; masking at the COLLECTOR (a shared telemetry-ingestion layer that all producers pass through) is a good middle ground, centralizing the masking logic in one place that's easier to audit and update than every individual producer, at the cost of the sensitive value briefly existing in transit before the collector processes it; masking at STORAGE (redacting only once telemetry lands) is the weakest option, since the raw PII was already transmitted and potentially logged by intermediate systems before ever reaching the storage-layer mask.
• Masking technique: for values you never need to see again even in aggregate (a raw email address in a log line), simple deterministic redaction (replacing with a fixed placeholder) is sufficient; for values you need to correlate across events without exposing the actual value (tracking the same user across multiple log lines without exposing their identity), deterministic TOKENIZATION (a consistent, one-way mapping from the real value to a token) preserves correlate-ability while still hiding the underlying PII.
• Validating it's actually working: run an automated, regular scan of telemetry storage for known PII patterns (email regex, phone number patterns, credit-card-number patterns) as an ongoing, active control, not a one-time audit, since a NEW producer or a code change to an existing one can silently reintroduce a leak that a one-time review would never catch.
• Proving it to an auditor: maintain a record of the automated scan's results over time (showing zero PII-pattern matches, or documenting and remediating any that were caught), plus documentation of the masking architecture and enforcement point, which together demonstrate both the CONTROL (masking exists) and the ONGOING VERIFICATION (it's actually working, continuously, not just in theory).

Worked example

Concretely: a collector-layer masking service intercepts all telemetry before it's written to the storage backend, applying a regex-based detector for common PII patterns (email, phone, SSN-shaped numbers) and replacing any match with a deterministic token derived from a keyed hash of the original value, preserving the ability to correlate "this token appeared in 40 different log lines" without ever storing or exposing the real underlying value. A separate, independent nightly job scans a sample of stored telemetry for the SAME PII patterns as a verification check, distinct from the masking logic itself (so a bug in the masking service's own pattern-matching wouldn't also blind the verification check, since they're implemented separately), and alerts if any unmasked PII pattern is found, which happened once when a new producer service was onboarded without going through the standard collector path, caught within 24 hours by this nightly scan rather than persisting undetected indefinitely.

Trade-offs and pitfalls

Implementing the verification scan SEPARATELY from the masking logic itself (not sharing the same pattern-matching code) is a deliberate defense against the masking logic's own bugs blinding its own verification, if both used the identical regex, a bug in that regex would fail to mask AND fail to detect the failure to mask, a single point of failure this separation avoids. The pitfall in collector-layer masking is the brief window where the raw value exists in transit between producer and collector, if that transit path itself gets logged by some other, unrelated system (a network-level packet capture, an intermediate proxy's own access log), the PII could leak through a path the collector-level control never touches, which argues for defense in depth (masking as close to the source as feasible, not relying solely on the collector) rather than a single enforcement point.

Direct answer

At this scale the plan is not a single dependency list, it is a cross-team accountability map. Know who owns each piece and where the real critical-path dependencies sit between teams, sequence the whole program around that map rather than each team's own convenience, make accountability explicit enough that no piece has an ambiguous owner, and have a standing plan for what happens the moment any one team's piece is at risk.

Structured elaboration

Map ownership and real dependencies: list every team whose piece is required, infrastructure, data, legal, design, a partner engineering team, whatever applies, and for each, name specifically what they own and what depends on it. Distinguish a real hard dependency, nothing downstream can start without this, from a soft one, helpful but workable around, since treating everything as hard blocks the whole program on the slowest piece.

Sequence and set milestones: order the program by dependency structure, not by which team is easiest to schedule with. The piece with the longest lead time or the most downstream dependents starts first, even if it feels premature, because slack elsewhere in the schedule is far cheaper to spend than slack on the critical path.

Assign accountability across teams: a RACI structure, who is Responsible for doing the work, who is Accountable for the outcome, who must be Consulted before a decision, who is only Informed after, keeps this from collapsing into everyone assuming someone else had it. One name is Accountable for each milestone even when several teams are Responsible for pieces of it.

Keep it on schedule: review the cross-team milestone map on a fixed cadence with the Accountable owners present, not just your own team's standup, and track each team's piece as on track, at risk, or blocked, using a signal that is actually observable, a specific deliverable landing, not a vague sense of progress.

The moment a team's piece is at risk: go to that team's Accountable owner directly, understand the real cause and the real new date, and decide immediately whether to absorb it into existing schedule slack, re-sequence something else to buy time, or escalate to whoever can resolve a resourcing or prioritization conflict, since a program-level dependency risk is rarely something the working team can solve alone.

Worked example

A cross-team analytics feature needed work from four teams: infrastructure (a new data pipeline), the core data team (a schema change), legal (a data-use review), and the product team (the feature itself).

The map: infrastructure's pipeline was a hard dependency for the data team's schema change, since there was nothing to migrate without it. Legal's review was a hard dependency for launch, but not for earlier development. Product's feature build was a soft dependency on the final schema, since it could build against a mocked schema and swap it in later.

Sequencing: infrastructure's pipeline ran weeks 1 through 3, the longest lead-time piece with the most downstream dependents. Legal's review was submitted in week 1 to run in parallel, since it was mostly wall-clock time and did not block anything except final launch, planned to complete by week 6. The schema change started week 4 once the pipeline was ready, planned for weeks 4 and 5. Product built against a mocked schema from week 1 and planned to swap to the real one in week 6. Launch itself was planned for week 7, one week after both the schema swap and the legal review were due, a deliberate one-week buffer reserved specifically to absorb a single slip.

Accountability: infrastructure's engineering manager was Accountable for the pipeline milestone, the data team lead for the schema milestone, legal's own reviewer for the sign-off, and the program lead for the overall launch date, with all four teams Responsible for their own piece and the program lead Consulted before any team changed its own sequencing.

In week 3, infrastructure signaled their pipeline would slip by one week, finishing in week 4 instead of week 3. The program lead went directly to infrastructure's engineering manager that same day, confirmed the new date, and decided to shift the schema change to weeks 5 and 6 and the product swap to week 7, consuming the buffer that had been reserved for exactly this. Legal's review still completed on its original week 6 schedule, unaffected. The week 7 launch date itself did not move, because the plan had reserved slack for precisely one slip like this, though it now had no further buffer left to absorb a second one.

Trade-offs and pitfalls

The most common failure is treating every dependency as equally hard, which blocks the whole program on whichever team is slowest even when much of the work could run in parallel. A second is accountability spread across a team rather than pinned to one name, so a slip gets discussed in three different meetings before anyone actually owns fixing it. A third is discovering a team's risk only at the scheduled milestone review instead of the moment that team itself first sensed trouble, losing the early warning that would have made the response cheap instead of expensive.

Direct answer

The two-pointer technique replaces a nested loop (checking every pair, which costs $O(n^2)$) with two indices moving through the data in one linear pass. There are two common shapes: pointers starting at opposite ends and moving toward each other, useful when you are looking for a pair with some combined property on sorted data, and pointers moving in the same direction at different speeds, useful when you are compacting or scanning data in place. Both work because sorted order (or some other structural guarantee) lets you rule out a whole range of possibilities with a single comparison, instead of checking each pair individually.

Structured elaboration

Converging pointers (opposite ends, moving inward): on a sorted array, if you are looking for two elements that sum to a target, start left at index 0 and right at the last index. If the current sum is too small, left must move right, since every element left of it is even smaller; if the sum is too large, right must move left, for the mirror reason. Every step rules out one candidate for good, so the whole array is covered in $O(n)$ steps instead of $O(n^2)$ pairs.

Same-direction pointers, different speeds: here both pointers move forward, but one (call it slow) only advances when it finds a genuinely new value to keep, while the other (fast) scans ahead over everything. This shape shows up when compacting a sorted array to remove duplicates in place, or in cycle detection on a linked list, where a slow pointer advances one node at a time and a fast pointer advances two, so the fast pointer laps the slow one if and only if there is a cycle.

Worked example

Converging pointers, sorted-array two-sum:

def two_sum_sorted(arr: list[int], target: int) -> tuple[int, int]:
    left, right = 0, len(arr) - 1
    while left < right:
        s = arr[left] + arr[right]
        if s == target:
            return left, right
        if s < target:
            left += 1
        else:
            right -= 1
    return -1, -1

nums = [2, 7, 11, 15]
print(two_sum_sorted(nums, 9))

Running this prints:

(0, 1)

arr[0] + arr[1] = 2 + 7 = 9, found on the very first comparison.

Same-direction, different speeds, removing duplicates from a sorted array in place:

def dedupe_sorted_in_place(arr: list[int]) -> int:
    if not arr:
        return 0
    slow = 0
    for fast in range(1, len(arr)):
        if arr[fast] != arr[slow]:
            slow += 1
            arr[slow] = arr[fast]
    return slow + 1

data = [1, 1, 2, 2, 2, 3, 4, 4]
new_len = dedupe_sorted_in_place(data)
print(new_len, data[:new_len])

Running this prints:

4 [1, 2, 3, 4]

slow only advances (and writes) when fast finds a value different from what slow last kept, so the array is compacted to its four distinct values in one forward pass.

Trade-offs & pitfalls

Two-pointer techniques generally require the input to already have exploitable structure, most often sorted order; on an unsorted array, you either sort first ($O(n \log n)$ time, then two pointers in $O(n)$, for $O(n \log n)$ total) or use a hash set to find complements in one pass ($O(n)$ time, $O(n)$ extra space), trading the sort's time cost for the hash set's memory cost. A common mistake with the converging pattern is moving the wrong pointer, for example moving right when the sum is too small; since arr[right] is already the largest remaining candidate, only advancing left can plausibly increase the sum. The same-direction pattern generalizes into the sliding window (a window defined by two same-direction pointers that expands and contracts to maintain some invariant, such as "at most k distinct values"), which is worth naming as a related but distinct technique: the window's two edges are still two pointers moving the same direction, but both may move independently rather than one always chasing the other.

Edge cases

• Empty array: two_sum_sorted([], target) sets left=0, right=-1, so left < right is already false and the loop body never runs, returning (-1, -1); dedupe_sorted_in_place([]) hits its explicit if not arr: return 0 guard.
• Single element: two_sum_sorted([x], target) sets left=right=0, so left < right is false immediately, correctly returning (-1, -1) since one element cannot pair with itself; dedupe_sorted_in_place([x]) has range(1, 1) empty, so the loop never runs and it returns 1 (the single element is already deduplicated).
• No match: when no pair sums to target, left and right keep converging (one moves per step) until left == right, at which point the loop exits and (-1, -1) is returned, without ever needing a separate "not found" check.