Most of the job is deciding which question is worth answering. The modeling gets the attention, but you'll spend more hours cleaning tables, arguing about definitions and explaining results than you will tuning anything. Here's how the path works, level by level, and what people judge you on at each step.
You'll get a request like "why did signups drop last week" on a Monday, and by Wednesday you'll learn that the signup event was renamed, half the traffic comes from a bot, and marketing counts a signup differently than product does. That's the job. The query takes an hour. Getting everyone to agree on what the number means takes the rest of the week.
The second surprise is how often a model never ships. You can build a churn model that looks great in a notebook and watch it sit untouched because nobody owned the retention campaign it was meant to feed. Good data scientists ask who will act on the answer before they write a line of code. That habit saves more of your time than any library does.
And you'll be wrong in public. A stakeholder will push back on a finding in a review meeting, and sometimes they'll be right. The people who last in this job treat that as useful, not as an attack, and they write down their assumptions so the next argument is shorter.
You write SQL all day, build dashboards in Tableau or Looker, and answer questions someone else framed. You're judged on whether your numbers are right and whether you catch your own mistakes before a manager does. A clean, well-commented query that you can explain line by line beats a clever one you can't.
You own a problem area, like pricing, fraud or retention, and you're expected to turn a vague ask into a question you can test. You'll run A/B tests, build forecasting or classification models in Python with pandas and scikit-learn, and present results to product managers who want a yes or a no. People judge you on whether your work changed a decision, not on how fancy the model was.
You pick the problems now. You spot that the experiment platform is miscounting users, or that the team keeps rebuilding the same feature table, and you fix it without being asked. You review other people's analyses, mentor juniors in code review, and push back when a stakeholder wants a model where a simple rule would do. Your judgment is what you're paid for.
This is where the path splits. On the staff track you set technical direction across several teams, write the design docs others follow, and get pulled into the hardest problems. On the manager track you hire, run one-on-ones, fight for headcount and roadmap space, and mostly stop writing production code. Neither is a promotion over the other, so pick the one whose bad days you can live with.
These come up in the screen, the take-home or the live exercise, so expect to show them, not just list them.
The fastest move is almost always internal. If you're an analyst, find a question your team keeps answering by hand and build something that answers it better, like a forecast that replaces a spreadsheet someone updates every Friday. Show the before and after. That one project does more for a promotion case than a certificate does.
If you're coming from outside, a portfolio helps only when it looks like real work. Skip the Titanic and iris datasets. Pick messy public data, write up what you'd tell a manager, and say what you'd do differently. Hiring managers read the write-up more closely than the code.
A graduate degree in statistics, economics, computer science or a lab science still opens doors, especially at research-heavy teams. It isn't required everywhere. Plenty of strong data scientists got there from analyst roles, engineering or finance, and they tend to be better at the business side because they've already sat in those meetings.
Ad hoc requests. Some weeks you'll get a stream of "quick pulls" from sales and leadership that eat every hour you'd planned for real work. You'll need to learn to say "I can do that next week" without sounding like you're dodging.
The other grind is data you don't control. When an upstream table breaks, your dashboard is the one that looks wrong, and you're the one who gets the message. If you want clean inputs and quiet focus, this job will frustrate you. If you like detective work and don't mind explaining the same caveat for the fifth time, you'll probably enjoy it.
12% of openings are fully remote.
$94,950 – $160,000
Typical range in the 46 of the newest 60 postings that list pay.
No. Research teams and some machine learning groups still prefer one, but most product and business data science roles hire people with a bachelor's or master's and solid experience. What they check is whether you can frame a question, write clean SQL and Python, and explain what your result means for the business.
An analyst mostly answers questions about what happened, using SQL and dashboards. A data scientist is expected to answer why and what's likely next, using experiments and models, and to decide which question is worth asking in the first place. The line is blurry, and some companies use the titles for almost the same work, so read the posting's actual duties.
The tools write boilerplate code faster, and that's changed the day-to-day. They don't know that your signup event was renamed or that two teams define revenue differently. The parts that are hardest to automate are framing the question, checking the data and convincing people to act, and those are the parts that decide promotions anyway.
Pick based on which problems you'd rather have. Managers spend their days on hiring, feedback and planning, and they measure success through their team. Staff data scientists stay hands-on with hard technical problems and influence through design docs and reviews. If you're unsure, a tech lead stint on a small project gives you a taste of both.