First-month mistakes new analysts make, and the fix for each

The demonstration data

The first three mistakes are easiest to understand by seeing them happen. This script builds a tiny synthetic database, makes each mistake, then applies the fix. It uses only Python's built-in sqlite3.

import sqlite3

con = sqlite3.connect(":memory:")
con.executescript("""
CREATE TABLE orders (order_id INTEGER, customer_id INTEGER, amount REAL, order_ts TEXT);
INSERT INTO orders VALUES
 (1, 10, 500, '2026-09-01 10:15'), (2, 11, 300, '2026-09-15 18:40'),
 (3, 12, 200, '2026-09-30 21:05'), (4, 10, 400, '2026-10-01 09:00');

-- customers keeps one row per address change, so customer 10 appears twice
CREATE TABLE customers (customer_id INTEGER, city TEXT, is_current INTEGER);
INSERT INTO customers VALUES
 (10, 'Noida', 0), (10, 'Delhi', 1), (11, 'Pune', 1), (12, 'Jaipur', 1);

CREATE TABLE ratings (order_id INTEGER, score INTEGER);
INSERT INTO ratings VALUES (1, 5), (2, NULL), (3, 1), (4, NULL);
""")
q = lambda sql: con.execute(sql).fetchall()

# Mistake 1: join fan-out
print("September revenue, naive join:",
      q("""SELECT SUM(o.amount) FROM orders o JOIN customers c USING (customer_id)
           WHERE o.order_ts < '2026-10-01'""")[0][0])
print("September revenue, current rows only:",
      q("""SELECT SUM(o.amount) FROM orders o JOIN customers c USING (customer_id)
           WHERE c.is_current = 1 AND o.order_ts < '2026-10-01'""")[0][0])

# Mistake 2: the date filter that drops the last day
print("Orders with BETWEEN '2026-09-01' AND '2026-09-30':",
      q("SELECT COUNT(*) FROM orders WHERE order_ts BETWEEN '2026-09-01' AND '2026-09-30'")[0][0])
print("Orders with >= '2026-09-01' AND < '2026-10-01':",
      q("SELECT COUNT(*) FROM orders WHERE order_ts >= '2026-09-01' AND order_ts < '2026-10-01'")[0][0])

# Mistake 3: AVG silently ignores NULLs
avg_rated, rated, total = q("SELECT AVG(score), COUNT(score), COUNT(*) FROM ratings")[0]
print(f"Average score {avg_rated:.1f}, but based on {rated} of {total} orders")

Running it prints:

September revenue, naive join: 1500.0
September revenue, current rows only: 1000.0
Orders with BETWEEN '2026-09-01' AND '2026-09-30': 2
Orders with >= '2026-09-01' AND < '2026-10-01': 3
Average score 3.0, but based on 2 of 4 orders

Mistake 1: trusting a join without counting rows

What happens. Customer 10 has two rows in customers, so their September order is counted twice and revenue reads ₹1,500 instead of ₹1,000. Nothing errors. The number just looks plausible.

The fix. Count rows before and after every join. If the count grows when you expected it to stay the same, find out why before you go further. Ask which row is "current"; many tables keep history.

Mistake 2: a date filter that misses the last day

What happens. BETWEEN '2026-09-01' AND '2026-09-30' compares text, and '2026-09-30 21:05' is greater than '2026-09-30', so the last evening of the month disappears. With timestamps, the same trap exists in most databases.

The fix. Use a half-open range: on or after the first day, and strictly before the first day of the next period. Then check the maximum timestamp in your result.

Mistake 3: an average that skips missing values

What happens. AVG ignores NULLs, so "average rating 3.0" is based on 2 of 4 orders. Reporting it without the count makes it sound like every order was rated.

The fix. Report the base alongside the average ("3.0 from 2 of 4 rated orders"). Decide, with your manager, whether missing means "not asked", "not answered" or "zero", because each gives a different answer.

Mistake 4: sending a number you didn't compare

What happens. A figure that is double last week's goes out, because nobody looked at last week's.

The fix. Before sending, put this week's number next to last week's and the same week last month. If the change is large, either explain it in the email or find the bug. A 10-second comparison catches a surprising share of errors.

Mistake 5: working in a copy nobody else can find

What happens. The analysis lives in final_v3_new.xlsx on your desktop, and when your manager asks how you got the number a week later, you can't reproduce it.

The fix. Save queries in a named file or the team's shared repository, with a comment line at the top: the question, the date and the source tables. Name files by content and date, not "final".

Mistake 6: answering the question you assumed

What happens. "Returns last quarter" becomes returned order count, when the manager wanted returned value by category.

The fix. Restate the request in one line (period, measure, split, due date) and confirm it before you start. There is a ready draft for this in first work emails.

Mistake 7: charts that need you standing next to them

What happens. A chart with no title, unlabelled axes and a truncated y-axis travels in a forwarded email, and a reader draws the wrong conclusion.

The fix. Give every chart a title that states the finding ("Returns rose in September, mostly in footwear"), axis labels with units, the date range and the data source. Start bar charts at zero.

Mistake 8: staying stuck in silence

What happens. A fresher spends two days on a problem a colleague could explain in ten minutes, then misses the deadline.

The fix. Set yourself a time limit for being stuck, after which you ask, and ask with what you've tried. Most teams would rather answer a clear question early than hear about a delay late.

A pre-send checklist

Copy this into a note and run through it before anything leaves your hands:

• Row counts checked before and after each join
• Date range is half-open and the max date is what I expect
• Averages and rates show their base (n)
• Compared with last week and last month
• Query saved with the question, date and sources written at the top
• Request restated and confirmed
• Chart has a finding title, labelled axes, units and a source

When a mistake does get through, correct it quickly and openly. For the plan that sits around these habits across your probation, see the first 90 days as a data analyst.

These checks are practised on messy data throughout the Data Analyst programme, 3–4 months of live online SQL, Excel and Power BI work, with optional labs at our Noida centre.