When I first started working in data, I thought being good at SQL meant being good at analytics.
I came from a computer science background, so this was a natural assumption. If I could write clean queries, understand joins, debug logic, work with Python, and reason through data structures, surely that would translate directly into strong business intelligence work.
It helped, but only up to a point.
Over time, especially working as a Senior Business Intelligence Engineer at Amazon, I learned that the real difference between a junior analyst and a strong BI engineer is not just technical ability. It is the ability to turn messy business questions into clear, measurable, decision-ready analysis.
That sounds simple, but it is where many people struggle.
A lot of aspiring data professionals focus heavily on tools. They ask:
“What SQL functions should I know?”“Should I learn Tableau or Power BI?”“How much Python do I need?”“What projects should I build?”
Those are valid questions. But the bigger shift is learning how to think.
The first mistake: starting with the query
Early in my career, if someone asked for a dashboard or analysis, my instinct was to open the data warehouse and start exploring tables.
That felt productive. I was writing SQL, checking schemas, joining data, and producing outputs.
But I eventually learned that starting with the query is often a trap.
Before writing SQL, a strong BI engineer asks:
“What decision is this analysis supposed to support?”“What metric actually reflects the business problem?”“What action will someone take if the number goes up or down?”“What are the edge cases that could make this misleading?”“Who owns the definition of this metric?”
This is the part that does not show up in most SQL tutorials.
In real work, the hardest part is often not calculating the metric. It is deciding whether the metric is the right one in the first place.
Metrics are arguments, not just numbers
One of the biggest lessons I learned is that a metric is never just a number.
A metric is a definition, an assumption, and sometimes a political argument.
Take something simple like “active users,” “conversion rate,” “defect rate,” or “on-time delivery.” These sound straightforward until you ask how they are actually defined.
Does “active” mean logged in, clicked, purchased, created something, or returned within a time window?Does conversion include cancelled orders?Do we count test users?What happens when data arrives late?Are we measuring by event date, processing date, or reporting date?
Small definition choices can completely change the story.
This is why I think junior data professionals should spend more time practising metric design. SQL practice is important, but SQL without metric judgment can produce very confident wrong answers.
A good BI engineer is not just someone who can answer, “What is the number?”
They can also answer, “Should we trust this number?”
Dashboards should reduce decisions, not increase them
Another thing I had to learn is that dashboards are not meant to be data dumps.
A weak dashboard says: “Here are 25 charts. Good luck.”
A strong dashboard says: “Here is what is happening, here is what changed, here is where to look next, and here is what might need action.”
That requires editing.
When I review dashboards or portfolio projects, I often see people trying to prove they know how to make charts. They include every possible breakdown: region, month, category, user type, device, cohort, product, channel, and more.
But in business intelligence, more information is not always more useful.
A good dashboard has a point of view. It guides the reader. It makes the important thing easy to see.
One practical rule I use is this:
If every chart on the dashboard requires a meeting to explain it, the dashboard is not finished.
The goal is not to avoid nuance. The goal is to make the first layer of understanding obvious, then allow people to drill deeper when needed.
Python is useful, but not always in the way people expect
Because I have a computer science background, I like Python. It is powerful for analysis, automation, data cleaning, modelling, and working with messy datasets.
But for many data and BI roles, Python is not a replacement for SQL. It is a complement.
SQL is often the language of the data warehouse. Python is useful when the problem requires more flexible logic, repeatable analysis, statistical exploration, or automation.
The mistake I see from some candidates is treating Python as the “more advanced” skill and SQL as the basic one.
In real analytics work, excellent SQL is still a major advantage.
The strongest candidates can move between both:
Use SQL to extract and shape the right dataset.Use Python to explore, validate, model, or automate.Use business judgment to explain what the results actually mean.
That last part is the most important.
A perfect notebook that does not lead to a decision is still incomplete.
The interview skill most people under-practise
When people prepare for data interviews, they usually practise technical questions: joins, window functions, CTEs, aggregations, Python syntax, probability, or case studies.
That matters.
But many candidates under-practise explaining their reasoning.
In analytics interviews, the interviewer is often not only checking whether you get the right answer. They are checking how you think when the problem is ambiguous.
Can you clarify the question?Can you define the metric?Can you state assumptions?Can you identify missing data?Can you explain tradeoffs?Can you recommend an action without overstating the result?
This is especially important for BI, product analytics, and data analyst roles.
A candidate who silently writes a technically correct query may still perform worse than a candidate who communicates clearly, handles ambiguity, and shows sound judgment.
In real data work, you rarely get perfectly packaged textbook problems. You get vague questions from stakeholders who may not know exactly what they need yet.
Your job is to help turn that ambiguity into something measurable.
What I recommend to people breaking into data roles
If I were advising someone trying to break into data today, I would not tell them to learn every tool.
I would tell them to build a small but strong foundation around five things.
First, get very comfortable with SQL. Not just basic SELECT statements, but joins, aggregations, window functions, date logic, subqueries, CTEs, and debugging query results.
Second, learn enough Python to analyse data confidently. You do not need to become a software engineer, but you should be comfortable cleaning data, using pandas, writing functions, and explaining your work.
Third, practise metric design. Take common business questions and define how you would measure them. Be specific about numerator, denominator, time window, exclusions, and edge cases.
Fourth, build one or two portfolio projects that look like real business problems. Avoid generic dashboards that only show charts. Start with a question, define the metrics, analyse the data, and explain the recommendation.
Fifth, practise talking through your work. Record yourself explaining a project or SQL solution. If you cannot explain it clearly, you probably do not understand it deeply enough yet.
The mindset shift
The biggest shift in my own career was moving from “I can produce the data” to “I can help the business make a better decision.”
That is the difference between being someone who writes queries and someone who drives impact with data.
The tools matter. SQL matters. Python matters. Dashboards matter.
But the real value comes from connecting those tools to judgment.
When I mentor people preparing for data roles, this is usually where we spend the most important time: not just solving the problem, but improving how they frame it, communicate it, and turn it into action.
Because in the end, strong BI work is not about making data available.
It is about making decisions clearer.
