Data science careers split by daily task, not job title

A data science job title tells you almost nothing about how the week is spent. Two people with the same label can do entirely different work: one reconciles tables behind a dashboard, one tests whether a difference is real, one trains and evaluates a classifier. Pick the branch whose ordinary tasks you can stand, then build evidence for that branch rather than for the label.
The material I am relaying separates data analysis, statistical analysis, machine learning, data engineering, business intelligence, data visualization, and natural language processing, and notes that these areas overlap inside a single project. That overlap is the useful part. The choice is about which task you want to own, not which department you enter for good.

Which branch fits the work you would actually do?

Match on tasks, not prestige.

• Data analysis: You receive a question, inspect a dataset, and calculate comparisons. The example given is a university comparing average exam scores across departments. If that sounds satisfying, practice framing the question and writing the finding in plain language.
• Statistical analysis: You care whether a difference is distinguishable from noise. This is where hypothesis tests and uncertainty live, and it is a different job from producing a chart that looks convincing.
• Machine learning: You want prediction or classification and accept that evaluation is most of the work. The spam-filter example is the source's own.
• Data engineering: You prefer reliable delivery to the final chart: collecting, storing, transforming, and serving data that others can trust.
• Business intelligence: You want recurring reports and dashboards tied to decisions, not one-off analysis.
• Data visualization: You want the comparison to become obvious at a glance.
• Natural language processing: You want to work with text, including classification and sentiment.

If two branches appeal equally, choose the one whose failures you can tolerate. A data engineer's bad day is a broken pipeline. An analyst's bad day is a conclusion that does not survive a second look at the data.

Where does the machine learning shortcut break?

It breaks at the first responsibility, not at the model. The sequence given is: define the problem, collect data, clean and prepare it, explore it, apply statistical methods or machine learning where appropriate, evaluate the result, then present findings. A beginner who starts at method selection has no defined question to evaluate against, so the project ends as a notebook with a score attached and no decision behind it.
The same material says plainly that not every project requires machine learning, and that some focus on statistical analysis, patterns, or communication. Ignoring that line is expensive. You end up competing for model-building work with a portfolio that shows no judgment about when a model was unnecessary. Cleaning comes before modeling for a reason: if you cannot explain what you dropped, merged, or filled in, you cannot defend the output later.

What should a portfolio show for each branch?

Mirror the responsibility list instead of collecting model demos.
For analysis, business intelligence, or visualization, show the question, where the data came from, the cleaning decisions, the comparison, and the chart that carries it. For statistical work, show the hypothesis, how uncertainty was handled, and the caveat you refused to hide. For machine learning, show a baseline, the evaluation choice, and a case where the model fails. For data engineering, show that data arrives reliably and in a usable shape.
One project per branch is enough to test the fit. A notebook with only a final accuracy figure is weak evidence for all of them, because it hides the steps where the actual job happens. No branch guarantees employment; titles and requirements vary by employer, so treat the portfolio as evidence of tasks you can perform, not as a promise of an offer.

How should you read an artificial intelligence jobs posting?

Read the task list, not the title. Most postings will describe a mix, so ask which of the responsibilities fills the week. If it is collection, cleaning, and delivery, the role sits closer to data engineering. If it is dashboards and recurring reporting, it is closer to business intelligence. If it is model evaluation and iteration, it is machine learning.
Then check the mismatch out loud in the interview: ask what a typical project looks like from problem definition to presentation. The answer usually reveals whether the branch on the posting matches the branch you prepared for.