Snowflake · Primly Community

Snowflake machine learning engineer interview: what they actually care about (hint: it's infrastructure)

ml_mike · 5 replies

just finished the Snowflake MLE loop. posting because there's almost nothing specific out there about what their ML engineering interview actually looks like. spoiler: it's more systems than models.

context: the role was on their Cortex team (Snowflake's ML platform product). not a research role, not a pure ML science role. they're building the infrastructure that lets customers run ML workloads inside Snowflake.

the loop (6 rounds total): recruiter + hiring manager screens ML system design coding round 1: distributed systems / concurrency coding round 2: ML-specific coding (in Python) ML depth round behavioral + values

ML system design: this is not "design an image classifier." they asked me to design a feature store that could handle streaming updates with low-latency reads for inference. they wanted to talk about consistency tradeoffs, cache invalidation, how you'd handle schema evolution. very much infrastructure-framed, not model-framed.

coding: the distributed systems round had a problem about implementing a simple task scheduler with dependencies (DAG-based). the ML coding round asked me to implement a custom batched prediction function with proper memory management and explain tradeoffs between batching strategies.

ML depth: they went deep on my resume here. asked about specific models i've built, how i handled class imbalance, how i'd evaluate a model deployed in production vs. offline eval. they also asked about Snowpark (their Python runtime), which i hadn't used but they were fine with me saying i'd learn it.

what mattered most: strong opinions on systems tradeoffs. they don't want ML engineers who only care about model metrics. if you can't talk about latency, throughput, fault tolerance in the context of ML serving, this loop will be rough.

what mattered less: cutting-edge research. nobody asked me about transformers or diffusion models. this is not an applied scientist role.

still in the debrief stage, don't have an offer yet. will update.

5 replies

content_cole

the feature store design is legitimately hard when you add streaming updates. did they want you to go deep on the storage layer or mostly the API/serving layer?

ml_mike

both, honestly. i started with the API and they kept probing the storage choices. eventually we ended up debating Redis vs. a custom columnar format for low-latency reads. felt like a real architecture debate, not a gotcha.

pivot_pat

the distinction between ML eng and applied scientist is real and important. i see a lot of DS candidates confuse the two. this post should help people self-select. if your passion is models and features, the ML eng role at infra-first companies will feel like a mismatch.

de_derek

the DAG-based scheduler problem is classic data engineering territory. feels like the Cortex team deliberately wants people who can straddle both worlds.

hardware_hugo

memory management in Python for ML batching is actually nontrivial. most people haven't had to care about it. good signal that they test it.