The Job Title Is the Least Reliable Column

Here are four job adverts. We wrote them ourselves, from the ingredients every data advert seems to share, so no recruiter was harmed in the making of this paragraph.

• Data Analyst. SQL, Python, dashboards, stakeholder communication, a passion for turning data into insight.
• Analytics Engineer. SQL, Python, data modelling, stakeholder communication, a passion for trusted data.
• Data Engineer. SQL, Python, pipelines, stakeholder communication, a passion for data at scale.
• Data Scientist. SQL, Python, statistics, stakeholder communication, a passion for insight.

Swap the titles round and see whether anyone notices. We’d bet against it. Which is awkward if you’re the person trying to choose between them, because the advert is usually the first place you look.

So if the adverts can’t tell the four jobs apart, what can?

Even the official version blurs

We went looking for something firmer than an advert. The U.S. Bureau of Labor Statistics keeps a page on data scientists in its Occupational Outlook Handbook, and projects their employment to grow 35 per cent from 2025 to 2035, much faster than the average for all occupations. It’s a good sentence to quote. It’s an even better page to keep reading.

Because the duty list is where it gets interesting. Alongside “Create, validate, test, and update algorithms and models”, it lists “Use data visualization software to present findings” and “Make business recommendations to stakeholders based on data analysis”. Which is also a fair description of a great many analysts’ weeks.

Then there’s dbt Labs, which makes the dbt transformation tool and has written about these roles. Its version is tidier: data analysts “answer questions using data analysis methods”, analytics engineers focus on “cleaning, transforming, testing, deploying, and documenting data”, and data engineers “build systems to collect and process data”. Clear enough. And still the sort of definition that sounds obvious right up until you’re the one applying.

So the definitions overlap at the edges, and the skills lists overlap almost completely. Whatever separates these jobs, it isn’t on the list of tools.

Follow one broken number

Here’s a better test. It’s 09:02 on a Monday, and the revenue chart everyone opens with their first coffee has dropped by a third overnight. Nothing in the business explains it. (We made this Monday up. Anyone who has worked near a dashboard will recognise it anyway.)

Now watch who reaches for what.

The analyst’s first thought is about people: who has already seen this, and what are they about to decide because of it? The analytics engineer’s is about the shared table underneath: which model fed this number, and why didn’t a test catch it? The data engineer’s is about plumbing: did last night’s load arrive half-empty, and why didn’t anything alert? And the data scientist’s is about doubt: is this a real drop, or a Monday that happens to look like one?

All four are right, and all four will end up helping. But that first reach is a much better clue to the job than the title on the door.

The four jobs, by who they work for

Lay the four along the route data takes through a company and the overlap starts to make sense. They aren’t four rungs of one ladder. They’re four positions along one flow.

• Data engineers get data in: from apps, tills, forms and other companies’ files into somewhere it can be queried, on time and every time. A good week is one where nothing happens. A bad one starts with an alert.
• Analytics engineers turn raw tables into trusted ones, cleaned, named, tested and documented, so two dashboards asking the same question get the same answer. Their customer is often another data person.
• Data analysts take questions from people and turn them into answers someone can act on. A surprising share of the job is finding out what the question actually is.
• Data scientists work on what the data can predict or prove: forecasts, models, experiments, and an honest estimate of how unsure each of those is.

What the list leaves out matters as much. It doesn’t say who uses SQL (all four), who uses Python (most) or who talks to stakeholders (everyone, eventually). The skills overlap. Who you work for, and what a good day looks like, don’t.

How to tell which way you’re drifting

Now turn it round to you. Very few people pick one of these jobs from a standing start. They drift. A learner who set out to be an analyst finds the cleaning more satisfying than the chart. An analyst who keeps quietly fixing other people’s tables wakes up one day as an analytics engineer in everything but name.

So here’s a slower, more honest test than any personality quiz. For the next two weeks of practice, keep a one-line diary: what you worked on, and whether you started it early or left it until Friday.

That last question matters most, and it’s the one people skip. Because every one of these jobs has a dull part, and adverts are written to keep it out of sight.

For the analyst, it’s the fifth conversation about what “active customer” means. For the analytics engineer, naming columns and writing tests nobody will ever thank them for. For the data engineer, rerunning the load that failed at 3am. For the data scientist, cleaning the data the model would otherwise choke on, and then explaining, kindly, why the model isn’t magic.

The exciting part of any of these jobs is the part everybody wants. The dull part is the part you’ll actually do, most weeks, for years. Which means the useful question was never “which job sounds best?”

Choose the Tuesday,
not the title.

The title is the least reliable column in the whole table. Companies rename it, merge it and split it, and the same Tuesday can be called “analyst” in one building and “analytics engineer” across the road. The Tuesday is what travels with you.

Where LucidPlexus fits, honestly

A word about our own shop, since you were going to ask. The Academy’s two learning paths are both analyst paths: Data Analyst with SQL and Data Analyst with Python. There is no analytics-engineering track and no data-engineering one, and dressing either analyst path up as one would be a disservice to you.

What the courses do give you is the Tuesdays, in miniature. Follow the Money is the analyst’s week: a vague question from finance, four tables and an answer someone has to act on. Can I Trust This Data? is built around finding what’s wrong in a dataset and cleaning it in views without touching the originals, which is the analytics engineer’s habit in its purest form; if you enjoy that more than the analysis, write it in the diary. Worth Backing? leans on distributions, fair comparisons and cohorts, where analysis starts shading into data science. And in the Library, Table Stakes is the build side of SQL: keys, constraints, transactions. If that’s the book you can’t put down, you’re drifting toward engineering.

The Tuesday that has no name

One more thing the diary might tell you, and it’s the awkward one. Some people’s favourite Tuesday doesn’t fit any of the four boxes: half analyst, half engineer, with a little statistics on a Thursday.

If that’s you, which title goes at the top of your CV: the one that describes your Tuesday, or the one that gets searched for?