ServiceNow · Primly Community

ServiceNow data scientist interview, SQL case and stats rounds explained

ds_dmitri · 4 replies

Went through the ServiceNow DS interview process last quarter for a mid-senior data scientist role on their product analytics team. Sharing because I found almost nothing specific about this loop online before going in.

Process overview: Recruiter screen, technical phone screen (DS focused), take-home case, onsite (4 rounds)

Technical phone screen (45 min): Felt like half SQL quiz, half product sense warmup. The SQL questions were not trick questions but they tested real skill: Window functions: running totals, rank within partition, lag/lead for retention cohorts A join problem with a gap-fills scenario (finding users with no activity in a 30-day window) One question about query performance: given two ways to write the same filter, which is faster and why (index usage, subquery vs. CTE, that kind of thing)

No Python in this round.

Take-home case: They gave me a fake dataset of ServiceNow platform events and user actions. Questions asked: describe adoption curve, identify leading indicators of customer churn, propose an A/B test design for a feature change. I had 5 days, submitted a Jupyter notebook with commentary.

I spent about 8 hours on it. The analysis was not supposed to be complex, they want to see how you frame a business question, do the analysis, and communicate the so-what. Avoid building a giant model when descriptive stats and a good chart tell the story.

Onsite DS rounds: SQL deep dive, 45 min, harder than the screen. One multi-table join with aggregation and a tricky condition, one windowing problem on event sequences. Stats / probability, 30 min. Bayesian reasoning, A/B test power calculation, one question about Simpson's paradox and when it shows up. ML / modeling discussion, 45 min. No coding. Walk me through a model you built end-to-end. How did you handle class imbalance? How do you explain the model to a non-technical stakeholder? What would you do differently? Cross-functional partner round: a mock conversation where I'm the DS and they play a product manager asking me to build something that isn't well defined. How do I scope it, what data do I need, how do I push back?

Stats gotcha: The Simpson's paradox question tripped me up at first. Know it cold. They clearly care about statistical rigor and whether you can catch misleading aggregations before they go into a dashboard.

Overall: solid loop, felt like they actually wanted a real data scientist not a SQL monkey or a pure ML engineer. The cross-functional round was the differentiator.

4 replies

analyst_ana

The cross-functional partner round sounds like exactly what I need more practice on. Do you have a sense of what a strong answer looks like when the PM's request is underspecified? Like what did they actually want to see from you?

alex_design

They wanted to see you ask clarifying questions before scoping. The PM in my mock was asking me to 'analyze why feature X is underperforming' with no baseline, no definition of underperforming, no segment info. Strong answer: I asked what metric they're watching, what the comparison point is (prior period? competitor benchmark? goal?), and what decision this will inform. Weak answer: jumping straight to 'I'll pull usage logs and run a regression.' They want structured problem definition before analysis.

ml_mike

The class imbalance question is such a shibboleth. Did they want oversampling/undersampling, threshold adjustment, or were they looking for the 'it depends on the business cost of FP vs FN' answer?

brand_ben

Exactly the 'it depends' answer, but grounded. I said I'd start by understanding the cost ratio (false negative churn miss vs. false positive wasted CSM time), then decide between threshold tuning and class weights before reaching for SMOTE or similar. They asked me to walk through what I'd do if the minority class was still performing poorly after class weighting. That got into precision-recall trade-off territory. It was a good conversation, not a quiz.