Interview Experience | Backend / Data Platform | π₯π₯π₯ | Snowflake
2026 (Sep) Software Engineer @ Snowflake US β Virtual Interview | π Neutral | Medium-Hard | Pending
Three rounds: coding, system design, then a data and system deep dive.
Round 1 β Coding
The question was a task executor with two operations:
addTask(taskId, priority, timestamp)
executeTask()
executeTask returns the task with the highest priority. If two tasks have the same priority, the timestamp decides.
The part that made it awkward is that the same taskId can be added more than once. Once a taskId has executed successfully, the other records with that id still sitting in the heap have to be skipped.
Follow-up: does completedTaskIds keep growing forever.
That turned into a discussion about cleaning up the history. If a taskId can always come back later, you cannot just delete from that set. If the system defines a task lifecycle or a retention window, then cleanup can follow the retention.
Then he added cancelTask(taskId). A cancelled task does not have to be removed from the heap right away. executeTask just skips it.
Round 2 β System Design
Design a job scheduler.
Users submit jobs with jobId, tenantId, priority, resource requirement, and scheduled time. The scheduler assigns jobs to workers.
We started with the basic submit / queue / dispatch.
What if a worker takes a job and then dies.
I used a lease. When a worker takes a job, it records a lease expiration. If the heartbeat stops, the job becomes runnable again.
Then: the worker actually finished, but the completion message was lost. What happens.
That goes into retry and duplicate execution.
He also asked about multi-tenant. One tenant submitting a large number of jobs at once must not starve the others.
Last was scheduler failover. Job state, leases, and retry counts cannot live only in process memory. A new scheduler taking over has to know which jobs are pending, which are running, which leases have already expired, and which are completed.
Round 3 β Data / System Deep Dive
The prompt here was: two databases, both at PB scale, how do you sync them.
Then the follow-ups:
- what if the target side processes changes more slowly than the source produces them
- schema change
- one partition fails to sync while the other partitions have already moved far ahead
The last few minutes were project questions. Had I worked on data consistency or migration problems before. How would I verify that the source and the target agree. If the dataset is too large to compare row by row, what then. How do I know a migration is ready to cut over.
The behavioral question was: tell me about a project where the original plan had to change.