Demonstrate motivation, feedback, and prioritization

Behavioral & Leadership STAR Prompts (Data Scientist — Technical Screen)

Context: You are preparing for a Data Scientist technical screen at Atlassian. Answer each prompt using the STAR method (Situation, Task, Action, Result) and include concrete metrics.

1. Why do you want to join Atlassian?

   • Tie your motivations to specific products, mission, and working practices.
   • Name two trade-offs you accept.

2. Describe a time you gave constructive feedback.

   • How did the person react, what did you do next, and what changed as a result?

3. How do you balance competing priorities?

   • Give a recent example, the explicit trade-offs you made, and what you learned.

4. Tell me about a time you went above and beyond for customers to drive a change but your effort failed.

   • What did you try, how did you measure impact, and what did you learn?

5. What was the most effective team you’ve been on?

   • What made it effective, what behaviors or rituals sustained it, and what qualities you personally contributed?

Solution

How to structure STAR answers with metrics

• Situation: Brief, factual context (who/what/when/where). 1–2 sentences.
• Task: Your specific goal or responsibility. 1 sentence.
• Action: What you did. Focus on decisions, frameworks, and collaboration. 3–5 bullets.
• Result: Quantified outcomes (absolute and relative), guardrails, and learning. 2–3 bullets.
• Tip: Use simple, auditable metrics (%, pp, hours saved, WAU/MAU, P95 latency, adoption rate, revenue impact). When experimentation is involved, mention MDE/power and guardrail metrics (e.g., error rate, latency).

1. Why join Atlassian (STAR with two trade-offs)

• Situation: I was choosing my next role after 3 years driving product analytics and ML for collaboration tools, prioritizing mission-aligned products with strong experimentation culture.
• Task: Identify a company where my impact on activation, collaboration workflows, and AI-assisted productivity would be maximized.
• Action:
  • Evaluated Atlassian’s products—Jira, Confluence, and Jira Service Management—focusing on onboarding funnels, search/ranking, and Atlassian Intelligence opportunities (e.g., summarization, issue routing).
  • Mapped my past outcomes to Atlassian’s mission to “unleash the potential of every team,” and to working practices like open-by-default docs, Team Anywhere, and blameless postmortems.
  • Spoke with 3 current Atlassians about their data-informed culture (weekly experiment reviews, RFCs, and decision logs).
• Result:
  • Concluded I can meaningfully move metrics that matter to Atlassian (e.g., new-team activation +2–4pp, WAU/MAU +3–5%, P95 search latency −10–20%).
  • Motivations tied to: (a) breadth and impact of Jira/Confluence in knowledge work, (b) scale for experimentation (10Ks of daily cohorts), and (c) principled openness/async rituals that suit my working style.
  • Trade-offs I accept:
    1. Distributed, async work can slow alignment by 1–2 days per decision; I’ll mitigate with crisp written RFCs, decision deadlines, and pre-reads.
    2. Strong privacy/compliance guardrails can lengthen data/ML cycles by ~10–20%; I’ll plan for privacy-by-design, synthetic data, and staged rollouts to keep velocity.

2. Constructive feedback (code and communication)

• Situation: A new analyst’s dashboard for executive QBRs had flaky metrics and slow queries, leading to 2 incident escalations in one month.
• Task: Provide feedback that improved reliability and helped the analyst level up without harming trust.
• Action:
  • Scheduled a 1:1 framed around shared goals; cited 3 concrete issues (missing time filters, inconsistent joins, unindexed filters) with examples.
  • The analyst initially reacted defensively, noting time pressure. I acknowledged constraints and proposed pairing on one critical chart.
  • Introduced a review checklist (freshness SLA, source-of-truth table, null handling, query plan check), created a dbt model to standardize joins, and ran a 45-min query tuning session (added 2 indexes, partition pruning, CTE rewrite).
  • Set up a pre-merge validation: unit tests for metrics definitions and a 30-min async peer review window.
• Result:
  • Reduced median dashboard load time by 62% (12.6s → 4.8s); eliminated incidents (0 in next 60 days); PR review cycle time fell 28% (2.5d → 1.8d).
  • Analyst’s engagement improved (took ownership of the checklist; led 2 brown-bags). Our team adopted the checklist as a standard, cutting BI incidents by 35% quarter-over-quarter.
  • Learning: Pairing + concrete examples defuse defensiveness; checklists and tests institutionalize feedback.

3. Balancing competing priorities (RICE and sequencing)

• Situation: In a quarter, I owned (A) shipping a next-best-action (NBA) model for upsell and (B) analyzing a high-visibility onboarding A/B test that could affect activation goals.
• Task: Make explicit trade-offs to maximize business impact while protecting data quality and team throughput.
• Action:
  • Sized both with RICE: RICE = (Reach × Impact × Confidence) / Effort.
    • NBA model: Reach 50k users/mo, Impact medium (1–2% revenue), Confidence 0.6, Effort 5 weeks ⇒ (50k×M×0.6)/5.
    • Onboarding test: Reach 200k new users/mo, Impact medium-high (2–4pp activation), Confidence 0.7, Effort 2 weeks ⇒ higher RICE.
  • Sequenced: prioritized the onboarding analysis first; time-boxed the NBA model to a rules-based baseline in week 3 to unblock experimentation.
  • Established guardrails: For the A/B test, pre-registered metrics (activation primary, support tickets and latency as guardrails), MDE 2pp with 80% power; for NBA, a shadow period to monitor precision/recall and customer support volume.
  • Communicated trade-offs to stakeholders with a one-page plan and weekly burn-down.
• Result:
  • Onboarding experiment shipped in week 2 with +3.2pp activation (p<0.05), no guardrail regressions; projected +4.5% WAU.
  • NBA baseline launched in week 5; drove +1.1% incremental revenue (A/B holdout), with <0.2pp increase in support contacts.
  • Learning: Explicit RICE scoring and time-boxed baselines de-risk sequencing; shadow modes protect customer experience.

4. Went above and beyond for customers; effort failed

• Situation: Enterprise admins reported SLA breaches going unnoticed in our ticketing workflow. I proposed a predictive SLA-breach alert feature to reduce MTTR.
• Task: Validate and drive adoption of the feature with measurable impact on MTTR and admin satisfaction.
• Action:
  • Built a quick logistic model on historical tickets (AUC 0.78), exposed as an alert in the admin view; set an adoption goal of 30% of eligible projects and MTTR −10%.
  • Ran a 6-week opt-in pilot with 40 customers; instrumented feature adoption, alert precision/recall, and MTTR as primary KPI; guardrails: alert fatigue (dismissals), false positives, and page load latency.
  • Overinvested in enablement: office hours, Loom walk-throughs, and templated playbooks.
• Result (failure):
  • Adoption reached only 8% (goal 30%); alert precision 0.61 led to alert fatigue (dismissals +35%); MTTR change was statistically insignificant (−1.3%, p=0.28).
  • Post-mortem interviews revealed setup complexity (permissions, notification routing) and misalignment: admins needed bulk triage, not just alerts.
  • Learning: 1) Solve for the workflow, not just the prediction—“decision + action” > “signal.” 2) Treat activation friction as a first-class problem (1-click default routing would have helped). 3) Increase bar for pilot readiness: require precision ≥0.75 or add tiered alert levels; dogfood internally first to refine UX.

5. Most effective team I’ve been on

• Situation: A cross-functional growth squad (PM, 5 engineers, DS, designer) responsible for team activation and collaboration features in a productivity product.
• Task: Improve activation, experiment velocity, and decision quality while maintaining reliability.
• Action (what made it effective):
  • Clear ownership: team-level north star (activated teams), with a compact metric tree (activation → WAU → retention) and 3 guardrails (latency, crash rate, support tickets).
  • Strong rituals: weekly experiment review (written pre-reads), bi-weekly metrics office hours, monthly pre-mortems for risky launches, and a living decision log.
  • High trust: blameless postmortems; PR templates for data/experiment quality.
  • My contributions: formalized experiment QA (power calc, CUPED for variance reduction), built a reusable metrics package and a dbt layer to standardize definitions, and created a “red/yellow/green” quality bar for experiments.
• Result:
  • Experiment throughput +40% (10 → 14/quarter), win rate from 27% → 36% via better hypothesis formation; analysis cycle time −33%.
  • Activation +3.8pp over two quarters; P95 latency held flat; support tickets −12%.
  • Team engagement rose (eNPS +15); onboarding new members’ time-to-first-PR −50% due to templates and docs.
  • Learning: Written culture and reusable analytics assets compound; guardrails preserve user experience while enabling speed.

Tips to adapt these to your story

• Swap in your product areas (e.g., search ranking, permissions, billing) and metrics you truly owned.
• Keep numbers conservative and verifiable; call out your direct actions and cross-functional partners.
• When you name trade-offs, state how you mitigated them (time-boxing, baselines, guardrails, RFCs).
• For experiments, mention basic statistical hygiene (power, MDE), guardrails, and what you’d monitor post-launch.