5 junior data analyst mistakes and work habits that help

You get your first job as a junior data analyst. You can write a query, build a table and produce a chart. Then someone asks you to “find out what’s happening with returns”. No definition, no decision deadline, but a fairly strong expectation that an analyst should know what to do. This is where the work extends beyond a course in syntax.

I look at five areas: the purpose of the task, initiative, communication, development and visibility. Each offers a habit you can practise. Each also offers a way to make life difficult for your colleagues, even with excellent SQL. I want to show you how to recognise the problem and change something concrete in your next assignment.

First, a boundary: doing good work does not guarantee continued employment. A company can reduce its budget, close a product or reorganise a department. I would not infer from someone’s redundancy that they failed to try hard enough. My focus here is the daily work you can influence and the expectations you can discuss with your manager.

We will use a fictional report about returns at an online shop. Every situation, statement and number is an educational example, not an account of a particular employer or my results for a client. You can practise the same approach with synthetic data while building a portfolio. Be clear about the conditions under which you produced the work.

Mistake 1: building a report before agreeing on its purpose

“Look at returns” can describe several different requests. The shop manager wants to decide whether to change product descriptions. Logistics needs to plan parcel handling. Finance wants to reconcile sales adjustments. These audiences may need different dates, different units and different definitions of an accepted return. One attractive chart cannot settle all those choices.

Before opening a tool, I ask what decision follows the report. Then I establish the audience, scope and timing. If the answer is “we just want to know”, I suggest a first version of the question. For example: has the share of orders with at least one accepted return increased between comparable groups of orders? A proposed question gives the other person something specific to correct.

In this exercise, the unit is an order, not a returned item. An order with three returned items counts once. That deserves a written note before you join orders to return lines. Otherwise, it is easy to produce a technically valid number that answers a different question. Defining a measure is analytical work, even when it looks less impressive on screen than a complicated query.

I would not attach an immediate revenue claim to every report. Sometimes the useful contribution is identifying an inconsistency, agreeing on a definition or making a check repeatable. You still need to explain who benefits and how the result will be used. “I built a dashboard” describes an output. To assess its usefulness, I also need to know what the reader can check with it.

Write a brief that someone can verify

My short brief for this task would say: I am comparing the share of orders with a return in two completed groups of orders. The audience is the shop manager. The report should help select products for further investigation, without treating the chart as proof of a cause. We will review the first version on Wednesday. Someone familiar with the returns process will confirm the accepted-return definition.

I would add a comparability condition. Returns happen after purchases, so orders placed two days ago have had less opportunity to be returned than orders placed a month ago. We need the same observation window, or a clear indication of incomplete observation. Otherwise, an apparent improvement may simply reflect the calendar. A junior analyst does not need to invent company policy, but should notice when a necessary rule is missing.

The Project Poster in Atlassian’s Team Playbook is a useful reference for organising a problem, assumptions and validation. For a small analysis, I use a short note rather than a large document. The point is to let the recipient correct my understanding before I spend two days answering the wrong question.

I also agree on acceptance conditions. The output should include a definition, period, order count, count of orders with returns and exclusions. Another person should be able to reproduce the calculation. Cost forecasting and automated purchasing recommendations are outside this first version. If those needs appear later, we revisit priorities and timing. Adding a good idea to a conversation does not add another day to the week.

Mistake 2: waiting for instructions or taking on everything

A lack of initiative can be easy to spot: you finish your assigned piece, notice a problem and stay quiet because nobody added it to the task. The opposite can look heroic. You rebuild the report, change the definition and promise additional breakdowns to three departments. Your original assignment then stalls, and the team discovers the expanded scope when delivery is due.

I prefer initiative with a clear boundary. Suppose you find two meanings of “accepted” in the returns data. Record an example of each, explain the effect on the result and suggest a discussion with the process owner. You can calculate both versions if that is a small amount of work. You should not silently choose the rule that produces the more convenient chart.

An improvement proposal should include effort and a next step. “I can add a duplicate-identifier check before the report refresh. I would allow about an hour for a trial, starting with a copy of the data.” That is an example message, not a universal estimate. It gives the recipient something to compare with the existing queue. “We should automate everything” leaves quite a lot of planning for somebody else.

If you lack access or permission to make a change, a well-documented request can be a useful form of initiative. Do not bypass a restriction to prove independence. When taking an additional assignment, ask what moves in the current schedule. Identifying a conflict between commitments is useful work. Collecting unlimited promises quickly turns your calendar into a rather imaginative work of fiction.

Mistake 3: staying silent until delivery

Two days without an update might mean steady progress, a difficult technical problem or a wait for access. From the outside, those situations can look alike. I therefore agree in advance on when and where to show progress. For a small assignment, an update after inspecting the data and a message when the deadline is at risk may be enough. Nobody needs a running account of every click.

Imagine that some return records lack an order identifier. “The data is broken” is too broad. I would write: “I checked key completeness. Some records cannot be linked to an order, so I cannot yet calculate the agreed share. Examples are attached to the task. I need the export owner to confirm the identifier source by tomorrow morning.” The message identifies the issue, its significance and the help required.

You do not need to exhaust every possible investigation before asking. If an unknown business rule changes the meaning of the result, further guessing is unlikely to solve the problem. For a technical error, show a small reproducible example, the expected result and the checks you already attempted. The person helping can then start at the useful point instead of retracing your entire afternoon.

I include the effect on the plan. I can prepare the report layout and inspect complete records, while the final calculation waits for a decision. If the deadline needs to change, I say so when the risk becomes visible. I do not report an optimistic completion percentage simply to make the status look reassuring. One unresolved definition can still change the whole calculation.

Deliver the result with instructions for using it

I start the handover with an answer to the agreed question. In our synthetic data, one group has 1,000 orders and 80 orders with an accepted return. The other has 1,200 and 120. The shares are 8% and 10%. The difference is 2 percentage points, while the relative increase in the share is 25%. Those last two statements describe different quantities, so I keep them distinct.

Beside the result, I state the comparable observation window and counting rule. I do not claim that worse product descriptions caused the increase. That conclusion needs more evidence and a check of alternative explanations. The mix of products, customers or recording practices could have changed. The report identifies an area to investigate. A cause does not become established because the presentation looks convincing.

A handover message could read: “For the agreed groups, the share increased from 8% to 10%. The file includes denominators, the definition and a duplicate check. It covers orders with a complete observation window. I suggest examining the product mix before changing descriptions. Please confirm whether this breakdown is sufficient to choose the next step.” This is still an educational message from our fictional example.

I also leave the source, refresh date, reproduction steps and limitations. Draft status belongs in the file itself so that the warning survives a copied table. After a correction, I record what changed the result. If the report will be used regularly, we agree on ownership and refresh checks. Sending a link does not automatically mean that someone has accepted maintenance responsibility.

Mistake 4: treating development as a list of tools

You can spend a month watching courses and still struggle to explain why joining two tables doubled the order count. I therefore start a learning plan with a specific gap in the work. In our example, that means understanding data granularity and checking the relationship between an order and its returns. A new library can wait. This problem is already on the desk.

I choose a small exercise: synthetic orders, several returns against one order, an order without a return and a record with a missing key. Before running anything, I write down the expected counts. I then calculate the result and explain to someone why the number of rows differs from the number of orders. If I cannot explain the difference, I return to the data model. An accidentally correct answer is a weak foundation for future work.

I discuss with my manager when I can practise and what outcome I will show. I would not assume that everyone has the energy for a second working day after hours. Development can involve reviewing one query carefully with a more experienced colleague. What matters is whether I can subsequently check a similar case myself, beyond receiving a corrected file.

A week later, I revisit the problem with different data. Can I recognise the mistake without a hint and justify the correction? That is more useful evidence of progress than the number of lessons watched. For the wider context, see my article on mistakes made by beginner data analysts. Here, the aim is to change one specific working habit.

Mistake 5: expecting your contribution to explain itself

Your manager does not see every check you add to a report. The recipient may not even know that the earlier version contained duplicates. You do not need to announce a triumph after each correction. You do need a place where someone can understand what changed and why. I keep a short record of the problem, my scope, the result and the evidence.

For our example, that record might say: “I agreed the accepted-return definition with the process owner, built the order-level report and added a duplicate-key check. A colleague reviewed the query, and the recipient confirmed the report layout. The linked version includes its refresh date and limitations.” My own contribution is visible, while other people’s work remains part of the account.

I do not add savings that I have not measured. If I removed a manual file-joining step, I can say that. If I want to report time saved, I need comparable observations and must include error handling. An estimate should be labelled as an estimate. A grand business-impact claim that collapses after two follow-up questions does very little for trust.

Visibility also means understanding who uses the analysis and who can resolve disputed definitions. I would rather understand those dependencies than speculate about informal office alliances. In a development discussion, I ask about expectations at my current level, specific gaps and the criteria for greater independence. I discuss documenting contributions and helping colleagues further in this article on development within a team.

When expectations change during the assignment

You can prepare a careful brief and still hear at delivery that a completely different analysis was needed. I return to the written agreement and ask what changed. Did the business decision change, or did we understand the original question differently? This separates a change in needs from an execution error. Both require action, but they suggest different improvements to the working process.

If I misunderstood a definition, I describe the error and correct the result. If new scope appeared, we agree on its timing and effect on other assignments. I do not automatically promise evening work to conceal a planning problem. When misunderstandings recur, I suggest an earlier review of a small sample. A few annotated rows can expose a disagreement before the full report exists.

Good collaboration is a shared responsibility. A junior needs someone available for consultation and clarity about how the work will be assessed. If instructions repeatedly conflict, collect specific examples and ask your manager to establish priorities. More technical courses will not resolve incompatible expectations. Discussing how work is organised is also part of professional development; it does not require pretending that greater individual effort can fix every problem.

Practise one complete assignment cycle

Start with a small analysis you can finish within an agreed period. On Monday, write down the question, recipient, definition and acceptance conditions. On Tuesday, inspect the data and describe one uncertainty. On Wednesday, show a draft result together with what cannot yet be inferred from it. The days are examples; adapt the rhythm to the actual assignment and people’s availability.

Next, hand over the result so that someone else can reproduce it. Ask for specific feedback: what was missing before the report could be used, which information arrived too late, and what had to be guessed? Choose one change for your next assignment. Attempting to fix everything at once makes it harder to see whether any particular habit has improved.

If you are not yet working in a team, play the recipient after a day away from the exercise. Open your file without consulting your working history. Check whether the definition, period and limitation are clear. You can also ask someone to reproduce the calculation using synthetic data. Do not present the exercise as commercial experience. Its value comes from checking your working method under honestly described conditions.

End a development conversation by agreeing on what you will do differently and when you will review it. “I need to be more proactive” is difficult to assess. “Before the next analysis, I will confirm the decision and recipient, and report blockers with their effect on the deadline” describes observable behaviour. That is the kind of concrete change I would start with.