I interviewed for Snap SDE ML infra in September. Posting my rejection story as a reference for whoever comes after.
Phone screen: an unusual problem, data stream processing. Every incoming data point can be stored into a stored cluster (you decide from the data itself whether it belongs to an existing cluster or is the first data point of a new cluster). You also have to implement a function that reads the max value of each cluster. The follow-up had quite a few read/write optimizations, and the last follow-up was verbal only: how would you find the median of each cluster. The interviewer was very nice, and I got the notice that I passed the same day.
Onsite:
Sys design: this is the round I especially want to complain about. After the phone screen I had a prep meeting with the recruiter, and the prep emails before that also stressed that this round would be an ML infra system design question (something like designing a multi-org shared distributed ML training platform, a data pipeline for feature extraction and a feature store, an ML infra platform, that kind of thing). I spent 80%+ of my time the week before the onsite learning ML stuff. What I got in the end was something like a CI/CD system with the control plane and data plane separated, which needed region-level host distribution. Since I hadn't practiced any traditional design questions that week at all, my answer was mediocre, though it probably counts as okay (I'm not very confident).
The first coding round was 1254. Thanks to the interviewer for going easy on me, but unfortunately, because of what happened in the previous round, I had barely grinded problems that week. This problem had a logic bug outside the core algorithm. The interviewer seemed to paste my code into some backend tool and have an AI review it, and then gave me two test cases that would fail. I wasn't in great shape that day and spent 20 minutes without figuring out what was wrong. I probably failed this one.
Second coding round: a radar overlap problem. You're given the coordinates and radius of each radar. The first part is to output, for each radar, which radars overlap with it. The second part: put all the radars inside a rectangular wall, and decide whether an object can get from the left wall to the right wall without being detected by any radar. The solution should be to use union find to merge the radars into clusters, then look at the range of y-coordinates each cluster covers, and if any cluster covers the whole y-range of the rectangle, nothing can get through. I didn't finish writing the code for this part, but I finished the main union-find and we talked through the little bit of remaining thinking.
AI coding: this round was also strange. Judging from the prep meeting/emails and other people's interview reports, I expected to write a small program from scratch, mainly testing some system design and a full-cycle software development way of working. But the interviewer said it was only his second time interviewing, and he had prepared a problem with an existing codebase. The codebase was in Go; I said I'd never written Go and couldn't read it, and that I preferred Python, though C++ and Java were also fine. He then found a "Python" problem on the spot, but it turned out the backend of that problem was Python while the frontend was JS. With AI helping me understand the whole architecture, I found that the feature to add only needed changes on the frontend, and then I just interacted with Claude Code to implement the feature and that was it.
Discussion
Loading comments…