The interviewer wants a concrete machine-level story, and "eventually consistent" without an example is a slogan. The concrete example: a Dynamo-style key-value store — the architecture behind Amazon's shopping cart — with three replicas of the same key.
The write path: the client writes the cart to the primary replica for that key. The primary updates its local copy and asynchronously propagates the update to the other two replicas — via gossip rounds in Dynamo's original design, or continuous replication streams in DynamoDB's managed version. There is no quorum handshake on the write path by default; the write is acknowledged as soon as the primary has it. Now the read path: the client reads from a different replica than the one that took the write — say replica 2, which hasn't received the update yet — and the read returns the stale value. That is what eventual consistency means operationally: reads can observe an older version of a key for some window.
Convergence is what "eventual" actually promises: given no new writes, all replicas converge to the same value within a bounded window — seconds in the same region, longer across regions, because propagation is bounded by gossip rounds or replication lag, not by wall-clock time. The mechanism that makes convergence well-defined is conflict resolution. When the write and read paths race, or two writers update the same key concurrently on different replicas, the system must pick a winner: last-write-wins using a timestamp, or version vectors that keep the conflict history so the application can merge. LWW is the cheap choice and the one that silently loses data when client timestamps are involved — which is exactly why the "don't compare timestamps across machines" failure mode matters here. Version vectors are correct but require application-level merging.
The part that shows depth: eventual consistency is a spectrum, not a mode. Strongly consistent reads (read quorums), read-your-writes for a single client session, monotonic reads, per-key consistency — DynamoDB gives you per-key strong consistency and read-your-writes as options that cost latency, because they require quorum reads or routing reads back to the replica that holds the latest write. Every step up the spectrum costs a round trip or a quorum; that's the trade you're buying with eventual consistency: the write acknowledged at primary speed, stale reads as the price.