Atlassian · Primly Community

Atlassian data scientist interview (SQL + case + stats): what the loop looks like

ds_dmitri · 4 replies

went through the Atlassian DS interview loop about two months ago. targeting a mid-senior DS role on the product analytics team. want to document this because the DS loop at Atlassian is genuinely different from the SWE loop and i couldn't find good info specific to it.

the loop structure (4 rounds): recruiter screen (30 min, standard) SQL + analytics round (60 min) product sense / case round (60 min) stats / methodology round (45 min) behavioral round (45 min)

yeah, that's 5 rounds not 4, they recounted after the fact.

SQL round: this was the most technical. window functions, CTEs, complex group-bys. one question was: given a table of Jira issue events, calculate the average time-in-status for each issue type across projects. you need to think about state transitions, not just raw aggregates. if you've never written lag/lead window functions to compute state durations, practice that specifically. the interviewer was happy to see me write it incrementally rather than trying to get it perfect in one shot.

product sense / case: they gave me a scenario: "engagement on Confluence pages has dropped 15% month-over-month in a specific user cohort. walk me through how you'd investigate." pure data investigation framework. i used a structured breakdown: segment by page type, user type, traffic source, feature usage. they wanted to see systematic hypothesis generation, not a single guess.

stats / methodology: A/B testing was central. when would you use a t-test vs. Mann-Whitney, how do you handle novelty effects in a product test, what's your approach to early stopping. also one question on selection bias in product metrics that i thought was well-crafted.

overall difficulty: moderate to hard. harder than most mid-level DS roles i've interviewed for. the SQL is genuinely complex, not just "write a join." worth prepping specifically.

4 replies

analyst_ana

the time-in-status SQL question is exactly the kind of thing i always mess up under pressure. do you have a clean pattern for that? is it basically: lag(eventtime) over (partition by issueid order by event_time)?

ds_dmitri

basically yes. lag to get the previous event time, then currenttime - lagtime = timeinstatus for that transition. the trick is handling the first event (no lag) and filtering to only the status you care about. they wanted me to handle nulls explicitly which caught me for a second.

de_derek

curious whether the SQL round was live coding in a shared editor or whiteboard style. i always prep differently depending on format.

ds_dmitri

shared editor, not whiteboard. CoderPad i think. you could actually run the queries against a mock dataset which helped a lot.