The data analyst

The week

Monday, a message: “revenue looks off in the north region, can you check”. Tuesday, you find the region field changed meaning in March when the sales team reorganised, and half the comparison is nonsense. Wednesday, you rebuild the comparison on a stable definition and it turns out revenue is fine but one large customer moved their billing date. Thursday, you write four paragraphs and a chart. Friday, somebody asks the same question about the south region.

That is the job. Not the chart. The chart takes twenty minutes. The three days before it are the work, and they are almost entirely about establishing what a word means.

What you produce

An answer somebody acts on, in writing, with the caveats attached. Secondarily, dashboards, which are answers to questions asked repeatedly, frozen so nobody has to ask you again.

The unit of value is a decision changed. An analyst who produces forty dashboards nobody opens is less valuable than one who produced three memos that stopped a bad launch. This is the hardest thing to believe early, because the dashboards are visible and the memos are not.

The stack

• SQL. Non-negotiable, and it is most of the job. Everything else is optional.
• A BI tool: Tableau, Power BI, Looker in industry. Free equivalents that teach the same concepts: Metabase, Apache Superset, Google Looker Studio, or plain matplotlib in Python. A hiring manager cares whether you can build a chart that answers a question, not which licence you held.
• A spreadsheet. Excel or Google Sheets. Do not sneer at this; see the spreadsheet lesson in the evidence module.
• Python or R, at the level of loading a table, cleaning it and plotting it. Pandas is enough for years. R with the tidyverse is entirely respectable and still dominant in pharmaceuticals, biostatistics and parts of academia.
• Statistics at the level of proportions, distributions, sampling error and what a confidence interval means.

Two routes in

From inside a company. The most common entry in the world. You are in operations, finance, support, marketing or logistics; you already know the domain; you learn SQL and take over the reporting nobody wants to do. Domain knowledge is the expensive half and you already have it. This route is invisible on job boards, which is why people underestimate how many analysts arrived by it.

From outside, with public data. Pick a dataset with a genuine question attached (your city’s transport authority, a national statistics office, a public health registry) and publish three analyses that end in a recommendation. The bar is not sophistication. It is whether a reader can tell what you would do differently on Monday.

The failure that ends the first year

Answering the question you were asked. A stakeholder says “how many users churned last month”. You produce the number. Then they say “but that includes trial accounts”, and you produce it again, and then “that counts anyone who did not log in, but our contract runs annually”, and you produce it a third time.

Three days gone because nobody wrote down what “churn” means. The senior version of you opens with a sentence: ”Before I run this: churn meaning contract not renewed, or meaning no activity for thirty days? They will give different answers and I want the one you will act on.”

Owning definitions is what separates an analyst who is trusted from one who is a query service. Write them down where others can find them. A one-page document listing the ten metrics your team argues about, each with a definition and the SQL that computes it, will do more for your standing than any dashboard.

The limitation

Analyst work is the most exposed part of this field to automation, and for a specific mechanical reason: much of it is text-to-SQL over a schema, and models are competent at that. What they are not competent at is knowing that the region field changed meaning in March, that the finance team’s definition of revenue differs from the sales team’s, or that the person asking will act on the answer in a board meeting where being confidently wrong is expensive.

The defence is not faster querying. It is being the person who owns the definitions and is accountable for the number. That part is not going anywhere, and it is a completely different daily practice from writing more queries.

How to tell a good version of this job from a bad one

Ask what proportion of requests arrive with a decision attached, and ask to see the team’s metric definitions. If definitions live in one place and are argued about openly, the job is analysis. If they live in people’s heads and each team has its own, you are joining an archaeology project, which can be excellent early-career work, but only if you know that is what you signed up for.