How to ask a doubt your mentor can answer in one reply

The five-part doubt

Copy this into your notes and fill it every time:

Goal:      What I am trying to get (one sentence, in business terms if possible)
Code:      The smallest query / formula / cell that shows the problem (as text)
Result:    The exact error message, or the wrong output I got
Expected:  What I thought I would get, and why
Tried:     What I already changed or checked

"Expected" is the part most people leave out, and it is often where the misunderstanding lives. If you expected 500 rows and got 740, saying so tells the mentor you are confused about the join, not about the syntax.

Three rewrites

SQL, before:

sir my query is giving wrong answer pls check

After:

Goal: total revenue per city for March. Code: `SELECT city, SUM(amount) FROM orders o JOIN payments p ON o.order_id = p.order_id WHERE month = 3 GROUP BY city;` Result: Delhi shows ₹4,12,000. Expected: about ₹2,06,000, because the orders table alone sums to that. Tried: removed the WHERE, still double. I think orders with two payments are being counted twice?

The mentor can now reply with one line about joining a one-to-many table before aggregating. The learner almost answered it themselves.

Excel, before:

VLOOKUP not working

After:

Goal: bring the region into the sales sheet from the store master. Formula: `=VLOOKUP(A2, Stores!A:C, 3, FALSE)`. Result: #N/A for about half the rows. Expected: every store ID exists in the master. Tried: checked store S104 manually — it is there. Store IDs in the sales sheet are left-aligned and in the master right-aligned.

That last observation points straight at IDs stored as text in one sheet and numbers in the other.

Power BI, before:

my measure shows same value in every row

After:

Goal: sales by product category in a table visual. Measure: `Total Sales = SUM(Sales[Amount])`. Result: every category shows the grand total. Expected: different totals per category. Tried: checked the relationship view — Category table has no line to Sales.

A missing or inactive relationship is now the obvious suspect.

Shrink the problem to ten lines

When a bug appears in a long notebook, do not send the notebook. Rebuild the problem with a tiny, made-up table. Half the time, doing this shows you the cause; the rest of the time, the mentor can run your example in seconds.

Here is the SQL join problem above, reduced to synthetic data in pandas:

import pandas as pd

orders = pd.DataFrame({"order_id": [1, 2, 3], "city": ["Delhi", "Delhi", "Noida"],
                       "amount": [100, 200, 150]})
payments = pd.DataFrame({"order_id": [1, 1, 2, 3], "paid": [50, 50, 200, 150]})

joined = orders.merge(payments, on="order_id")
print(len(orders), "orders ->", len(joined), "rows after merge")
print(joined.groupby("city")["amount"].sum())

# The fix: aggregate the many side before joining
paid_per_order = payments.groupby("order_id", as_index=False)["paid"].sum()
fixed = orders.merge(paid_per_order, on="order_id")
print(fixed.groupby("city")["amount"].sum())

assert joined.groupby("city")["amount"].sum()["Delhi"] == 400
assert fixed.groupby("city")["amount"].sum()["Delhi"] == 300

Order 1 has two payment rows, so its amount is counted twice. Three orders and four payments are enough to show it. If you can write an example like this, you understand the bug well enough to ask a precise question — or to skip asking altogether.

What to leave out

• Real customer or employer data. Replace it with made-up rows. Never paste a work dataset into a class group.
• The whole error log. Send the last few lines of a Python traceback, which name the error type and the line.
• Apologies and preamble. "Sorry to disturb, I know this is silly" adds nothing. Start with the goal.
• Several unrelated doubts in one message. Split them, so each can be answered and closed.

Where to ask what

In a live class, a quick spoken version works: "Before you move on — when we join payments, why does the Delhi total double?" That is the same five parts, compressed.

After you get the answer

Write one line in your own notes: the symptom and the cause. "Totals doubled after join → many-side not aggregated first." A few weeks of these lines becomes a personal debugging guide, and you will start recognising the pattern before you need to ask.

Live sessions exist largely so these questions get answered while the problem is fresh. In the Data Analyst programme, doubts are taken during live online classes and in follow-up channels, with optional in-person labs at our Noida centre. If a doubt comes from a class you are rewatching, add the timestamp — the timestamp-log method for recordings shows how.