Forward deployed round
Connector Record Reconciliation Coding Problem
Written and reviewed by Sahil Srivastav
What this interview round tests
A sync connector has to answer a deceptively hard question every run: given the local state and the remote state, what changed? Get the diff wrong and the job either deletes records it should have kept, misses updates, or re-creates things that already exist. In a two-way integration, a bad reconciliation destroys real data.
Interviewers ask this because reconciliation is the heart of every connector, and its edge cases are unforgiving. A diff that keys incorrectly deletes valid records; one that compares carelessly misses genuine updates. The sync looks like it ran fine and the two systems have quietly drifted apart.
The scenario
You are given a reconciliation function that compares a set of local records against a set of remote records and produces the upserts and deletes needed to bring them in line. It deletes records that should be kept and fails to update records that changed.
The tests provide paired local/remote snapshots with additions, updates, deletions, and unchanged records. Your job is to fix the diff so the job upserts and deletes exactly the right records — no more, no less.
What you’ll practice
- Set-style reconciliation: computing adds, updates, and deletes
- Keying records correctly so identity is stable across sources
- Detecting real changes without false updates
- Never deleting a record that should be retained
- Verifying a sync converges both sides to the same state
How to approach it
Think of it as a diff between two sets of records, and be precise about identity: what key decides that a local and a remote record are the same one? Most reconciliation bugs trace back to either an unstable identity or a comparison that fails to detect a real change — watch which of the two the paired snapshots expose.
Let the paired snapshots be the specification: after applying your upserts and deletes, local must equal remote exactly — any extra deletion or missed update shows up immediately.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
FAQ
Why is deleting the dangerous operation here?
Because a wrong delete destroys data that may not be recoverable, while a missed add or update is usually caught on the next run. A safe reconciler is conservative about deletes and precise about identity.
What makes the record key so important?
Identity is what lets you say "these two rows are the same record." An unstable or wrong key makes the diff treat an update as a delete of the old plus an insert of the new — which is exactly how sync jobs lose data.