Job ads for data analysts list a lot of tools: SQL, Python, a BI tool, statistics, sometimes machine learning. Then you start, and your first week looks nothing like the ad. You spend most of it working out what the numbers you already have actually mean.
That is not a slow start. It is the job. Here is a realistic first week for a new junior analyst on Tomás's team at Mangrove Market, the grocery chain we use in every course, and what each day asks of you.
Monday: access, and a map of who asks what
You get a laptop, read-only access to the data warehouse, a login for the BI tool, and a seat next to Tomás. Nobody expects a query from you today.
The most useful hour of the day is the one where Tomás walks you through the five dashboards people actually open, who owns each one, and which numbers get quoted in the weekly meeting. Write it down. By Friday you will be asked about at least one of them.
Skill used: listening and note-taking. Not glamorous, but every later day depends on it.
Tuesday: learning the tables
You open the warehouse and find the core tables: orders, order_items, customers, stores, products. You write small queries to get a feel for them. How many orders yesterday? How many per store? What values can status take?
That last one matters more than it looks. Here is the same check on the retail sample database in our SQL Lab, which has the same shape as Mangrove's tables:
SELECT status, count(*) AS orders
FROM orders
GROUP BY status
ORDER BY orders DESC;
status | orders
-----------+-------
delivered | 19215
cancelled | 487
refunded | 201
pending | 97
Now the obvious question: when someone says "orders", do they include cancelled ones? Refunded ones? Orders that are still pending? Each answer gives a different number, and all of them are "correct". Your query and the dashboard can disagree without either being broken.
Skill used: SQL basics (GROUP BY, careful WHERE filters) and, more important, suspicion. SQL you'll actually use covers the queries; the suspicion comes with practice.
Wednesday: the first real question
Imran, the product manager for the Partner app, stops by. About 62% of partner shop orders are placed in the Partner app today; the rest come by phone to sales reps. Last month the team launched a "reorder last week's list" button. Imran asks: "Is the reorder button moving more partner orders into the app?"
The beginner move is to open the editor and start typing. The analyst move is to rewrite the question first:
- What counts as a partner order? Only delivered ones? What about an order a sales rep enters into the app for a shop over the phone?
- Compared with what? The four weeks before the launch against the four weeks after? Festival weeks would distort that.
- What decision does it feed? If the answer is yes, Imran wants to promote the button to every shop. If it is no, he wants to know why before spending more.
Fifteen minutes on these questions saves a day of answering the wrong one. Asking a question data can answer is a whole lesson on this step, and it is the one most self-taught analysts skip.
Skill used: turning a vague question into a precise one, out loud, with the person who asked it.
Thursday: the number doesn't match
You run the analysis and get 66% of partner orders in the app after the launch, up from about 62%. You show Tomás. He opens the sales team's spreadsheet, which says 71%.
You spend most of the day finding out why. It turns out the sales team counts an order as "in the app" if it ever passed through the app, including orders a rep keyed in on a shop's behalf. Your query counted only orders the shop placed itself. Neither of you is wrong. You are measuring different things with the same name.
This is the most common problem in analytics, and it is why companies write metric definitions down. You agree with Tomás and Imran on one definition, write it in the team's metrics document, and note that the sales sheet uses another. Metrics everyone agrees on shows how a team keeps one definition per number.
Skill used: reconciling two numbers patiently, and writing a definition someone else can apply.
Friday: writing it up
The answer goes to Imran as a short note, not a dashboard:
- The answer, first. "Yes, a little: partner orders placed by shops in the app went from about 62% to 66% in the four weeks after launch."
- How sure you are. Four weeks is short, and one week included a public holiday.
- The definition you used, with a link to the metrics document.
- One chart, labelled so it makes sense without you in the room.
- What you would check next: whether the shops that use the button are the ones who already ordered in the app.
Tomás reviews it before it goes out and cuts a third of it. That is normal too. Telling the story covers how to write for a busy reader.
Skill used: writing. Analysts who write clearly get trusted with bigger questions.
What you didn't do in week one
No machine learning. No new dashboard. Very little Python. Those come later, and some analysts rarely need them. Week one ran on five skills, roughly in this order of how much they were used:
- Asking what a question really means
- SQL: filters, joins, grouping
- Checking a number against another source
- Writing down definitions
- Short, clear writing
If you are preparing for your first analyst role, practise those five more than any tool.
How to practise before you have the job
- Follow the Data Analyst path. It starts with Data Analysis with Excel, Python & AI and SQL & Data Modeling, then moves to statistics, dashboards and product analytics, in that order for a reason.
- Query the SQL Lab's sample databases. Retail, fintech and logistics are all there. Pick a question ("which store had the most cancelled orders last quarter?"), write down what each word means, then answer it. The free SQL Basics campaign gives you six graded challenges to start.
- Write a five-line note for every analysis you do, in the Friday format above. Nobody will ask you to, which is exactly why it stands out in a portfolio.
When you have a year or two of analysis behind you, the data analyst → data scientist role switch shows what carries over and what to add.
The takeaway: the analyst who asks "what counts as an order?" on Tuesday is the one people believe on Friday.