Most people open a new dataset like a raccoon opening a trash can - fast, noisy, and with no plan other than to find something shiny. 

You see it in every hiring cycle: the candidate gets the link, their eyes glaze over with excitement, a short session of Analysis Paralysis (Hey there!) and they immediately start writing code. 

They want to show off. 

They want to find that oh-so-sweet-correlation. 

They want to be the hero who finds the "secret" in the numbers.

But that frantic impulse is exactly why so many take-home assignments collapse before the first JOIN is even executed. You can brute-force your way to a chart, but if your foundation is shaky, your conclusion will be nothing more than fantasy dressed up as insight.

When you receive a brief, your first move should be total silence. 

Really, that’s what I do - always.

Put your hands behind your head and read the prompt twice. 

Don't just scan it - interrogate it. 

Circle the sentences (or color them,, you know, whatever works with your technology) that describe the actual business decision that needs to be made. 

Ask yourself: “If I deliver the perfect answer, what will change tomorrow?” Will a budget move? Will a feature be killed? Will a strategy pivot? If you can’t answer that cleanly, you just aren’t ready to query yet, and that’s FINE.

After this internal clarity do you sketch three things on paper: 

  1. What success looks like

  2. What could plausibly go wrong

  3. What assumptions you are already making. 

This is the line between being a button-pusher and being a professional data person. 

When you finally do open the data, your first queries should be "boring" by design: ranges of dates, missing values, duplicates, and basic distributions. 

Think of this as looking both ways before crossing the street - it won’t win you any awards, but it keeps you alive analytically.

When I’m building tasks for XP Lab’s users, I make sure our assignments are intentionally punishing speed without thinking. 

Slow thinking isn’t laziness; it is professional hygiene. 

And exactly what I want for you.

 .

A problem-framing checklist you can use tomorrow

Before opening the dataset, write a short brief that answers these questions:

  1. What decision will this analysis support? “Understand conversion” is a topic. “Decide whether to pause the mobile campaign next week” is a decision.
  2. Who will act on the answer? Identify the person who can change the budget, product, or process. Ask what they need to know before acting.
  3. What are we comparing? Define the population, period, unit of analysis, and denominator. “Customers” could mean accounts, people, purchasers, or visits; those are different analyses.
  4. What would change our mind? Name the observation that would support a different action. If every possible result leads to the same recommendation, question the purpose of the analysis.
  5. What must be true for the data to answer this? List the assumptions about event coverage, definitions, joins, and timing that could change the conclusion.
  6. What can we responsibly deliver? Agree on scope and deadline, and separate what can be answered now from what needs another source or more time.

The brief does not need to be beautiful. It needs to expose the choices that otherwise disappear into your first query.

A worked example: “Mobile conversion is down”

Here is an illustrative scenario. A marketing manager asks you to explain a fall in mobile conversion and recommends cutting spend. The instinctive response is to split the chart by campaign until a red bar appears.

First ask which action is being considered. Is the manager deciding whether to pause a campaign, revise a landing page, or investigate tracking? Those decisions need different evidence.

Then define conversion: completed orders divided by eligible sessions, for a specified device group and a comparable time window. Check that orders and sessions use compatible definitions and that the current period is complete.

Now you have a reason for the boring queries. Inspect event counts around releases, coverage by platform and date, duplicate order IDs, and how sessions join to purchases. Compare the purchase totals with an independent operational source if one is available. Missing sessions and fewer purchases are different problems.

Your first deliverable might be: “We cannot yet distinguish a customer behavior change from a measurement change. Here are the coverage checks needed before deciding on the budget.” That is a useful answer when the alternative is a confident recommendation built on an untested assumption.

For the coverage problem, continue with data completeness. For the standards the final answer should meet, read the characteristics of good business analysis. To practice the approach, explore XP Lab’s analytical workflow.