Data Science vs Data Engineering vs ML Engineering vs Analytics

"Build and maintain ETL pipelines"

"Own our weekly business reporting"

"Design and validate A/B tests"

"Deploy models to production, own uptime/SLAs"

"Strong SQL, dashboarding tools (Looker/Tableau)"

"Statistics, experimentation, causal inference"

"Airflow, Spark, warehouse architecture"

"MLflow, model monitoring, feature stores"

A Data Analyst is like someone who reads a company's existing, well-organized filing cabinet and answers questions about what is already in it — "how many customers did we get last month?" A Data Scientist is more like someone who first has to sort through a messy pile of unfiled papers, figure out what is trustworthy, and then sometimes builds a system that predicts what will happen next based on the patterns found.

The practical difference is in the starting point and the ceiling of the work: analysts typically start from clean, already-modeled data and their output is usually a report or dashboard. Data scientists more often start from messier, less-processed data, apply statistical rigor to validate what they find, and occasionally go all the way to building a predictive model — something an analyst role typically does not require.

In practice at many companies, especially smaller ones, one person does both jobs under one title — which is exactly why this distinction matters more for understanding a specific job posting's actual day-to-day than for judging whose job is "better."

I would treat it as useful information rather than a betrayal — many companies use "Data Scientist" loosely, and the actual day-to-day work is the ground truth, not the title on the offer letter. My first step would be a direct conversation with my manager about the mismatch, framed around what I want to grow into rather than a complaint about what I am currently doing.

I would look for openings to introduce more analysis-heavy or modeling work incrementally — for example, adding a simple statistical significance check to an existing dashboard metric, or proposing a small predictive project adjacent to my current dashboard work — to demonstrate the additional value without requesting a full role change upfront.

If after a genuine attempt the role's scope does not evolve and it matters to my career goals, I would treat that as useful signal about whether this company's structure fits where I want to grow, and factor it into future job search decisions rather than staying frustrated indefinitely.

An ML Engineer needs strong software engineering fundamentals that go well beyond what most data scientist roles require: writing production-grade code with proper testing, designing APIs, understanding latency and throughput trade-offs, containerization (Docker/Kubernetes), and CI/CD pipelines for deploying model updates safely.

They also need monitoring and observability skills specific to ML systems — detecting model drift (when real-world data starts to differ from training data), setting up alerting for degraded prediction accuracy, and building automated retraining pipelines. These are systems engineering concerns that a data scientist focused on proving a model works in a notebook typically has not needed to master.

Conversely, a Data Scientist typically needs deeper statistical theory, experimental design, and domain-specific feature engineering judgment than most ML Engineers develop — the two roles are complementary specializations rather than one being a strictly harder version of the other.

The signal is whether the project needs data infrastructure to exist or scale, rather than just an ad hoc pull for one analysis. If a question can be answered with a one-time query against existing warehouse tables, no data engineering involvement is needed. If the project requires a new, recurring, reliable data pipeline — for example, a nightly feed of a new event type that does not yet exist in the warehouse — that is squarely data engineering work.

A useful test: would this data need to exist and refresh correctly even if I, the data scientist, were on vacation next month? If yes, it needs to be a proper, engineered pipeline rather than a personal script running on my own laptop.

In practice, I loop in a data engineer as early as the framing stage of a project if I already suspect the answer will require new or restructured data infrastructure, rather than building a fragile personal workaround and discovering the need for a real pipeline only after the analysis is already trusted and in use.

A common blurry case: a data scientist builds a churn model that works well in a notebook, and the team is small enough that there is no dedicated ML Engineer. The data scientist is then asked to also deploy it — stepping into ML Engineer territory. The ambiguity is real: how much production engineering rigor is reasonable to expect from someone whose core strength is statistics and modeling, not systems design?

I would handle this by being explicit about scope and risk rather than silently absorbing the extra work: propose the simplest reliable deployment path (for example, a scheduled batch job rather than a low-latency live API, if the use case allows it), be honest about what monitoring and testing I can realistically build alone, and flag clearly if the production reliability bar genuinely requires bringing in engineering support before it ships to real users.

The principle that generalizes: role boundaries blur constantly in practice, especially at smaller companies, and the professional response is transparent communication about what you can competently own — not silently pretending the ambiguity does not exist.

Reality: At companies that clearly separate the roles, the compensation difference reflects a real difference in required skill depth — statistics, experimentation design, and sometimes machine learning — not just title inflation. At companies that use the titles loosely, the two roles genuinely may be near-identical, and the pay gap (if any) reflects company-specific leveling, not a universal rule.

What to do instead: Before assuming a pay gap is fair or unfair, look at the actual job posting bullet points using the decoder table in Part 07, not the title alone.

Reality: Most industry data science roles — as opposed to research scientist roles at a handful of AI labs — are dominated by cleaning, statistics, and communication, not cutting-edge machine learning. This entire course is built around exactly that reality: Sections 1–9 (cleaning through statistics) matter more day to day than Section 10 (modeling) at most companies.

What to do instead: Focus portfolio and interview preparation on demonstrating clean end-to-end analysis and sound statistical reasoning first — modeling skill is necessary for some roles, but rarely sufficient on its own without the foundation this course builds first.

Reality: Every insight a data scientist or analyst produces is only as trustworthy as the pipeline that delivered the underlying data. A broken or poorly designed pipeline silently corrupts every downstream analysis without anyone noticing until a stakeholder catches an obviously wrong number.

What to do instead: Treat data engineers as the team whose work determines whether your entire analysis is even valid — build a real working relationship with them rather than treating pipeline requests as an afterthought.

Reality: A model that works once in a notebook is a proof of concept, not a finished deliverable. Getting it validated, deployed reliably, and monitored over time typically requires as much additional work — often from an ML Engineer — as building it did in the first place.

What to do instead: When scoping a modeling project, explicitly ask and plan for what happens after the model works: who deploys it, who monitors it, and what happens when the underlying data eventually shifts and the model's accuracy quietly degrades.

StreamPulse's leadership asks: 'Which plan should we push harder in marketing — the one with the most total subscribers, or the one with the best retention?' Write pandas code (merging subscriptions and users if needed) that shows both total subscriber count AND cancellation rate per plan, side by side, so leadership can see both answers is not the same thing an analyst-only view (raw counts) would show.