📈 Data analyst
Turn raw data into a decision someone acts on.
Analytics interviews test three things in a fixed order: SQL, then reasoning about a business question, then whether you can present a finding without burying it.
The path, in order
Where people lose months
- ⚠Learning Python before SQL. Analyst screens are overwhelmingly SQL, and candidates regularly arrive with pandas fluency and fail on a join.
- ⚠Dashboards nobody asked for. A chart-heavy portfolio piece with no question behind it signals tool familiarity but not judgement, which is the thing being assessed.
- ⚠Reporting numbers without a recommendation. 'Revenue fell 8% in the north region' is an observation; the job is to say what you think should be done about it.
Common questions
SQL or Python first?
SQL, without much hesitation. It appears in nearly every analyst interview, is faster to reach a working level in, and is the most common single reason candidates get filtered out at the technical screen.
Do I need a statistics degree?
No. You need to use a small amount of statistics correctly and know when a number is misleading. Over-claiming significance you have not established damages credibility far more than admitting uncertainty.
What makes a good portfolio project?
One specific question, a real dataset, an honest answer, and a short written conclusion a manager could act on. Depth on one analysis beats five dashboards.
Put it to work
If the foundations are the gap rather than the job-specific skills, work through the coding lessons first — they assume no prior background.
Other paths: Software developer · Accounting & CA · Commerce & economics · English & communication · All paths
Building SQL from raw complexity, not tutorial simplicity
SQL tutorials teach on clean data: tables with consistent formats, no nulls, no unexpected characters. Real data is chaos. A person's name column contains both first-name-only and first-middle-last. A date column mixes formats. A numeric column contains text. A field you thought was unique has duplicates. Someone four job levels up asked for a number yesterday and nobody knows what definition they used. None of this appears in tutorial data, so graduates arrive with flawless query syntax and zero judgment about whether their result is real.
Practice with datasets that have these problems built in. Kaggle has several; your own organization's public data typically contains them. When you join a customer table to an order table and get 8 million rows instead of the expected 50,000, you have found a real problem: either the join condition is wrong or the data itself has duplicates. The debugging process is where the actual learning happens. The tutorial solution was 'here is the join syntax.' The real problem is 'decide which table is the source of truth and how you will handle the duplicates.'
Window functions are worth learning thoroughly because they are disproportionately useful in real analysis. A running sum, a month-over-month change, a row number within a partition — these appear constantly in analytics interviews and daily work. Spend two weeks on window functions alone. Write them until you can mentally parse a complex one without looking up syntax. This is not a small detail; it is the difference between an analyst who can produce numbers and an analyst who can produce insight.
What interviews actually measure underneath the question
Most analytics interviews follow this exact sequence. First, a SQL problem: given a schema and a business question, write a query. The interviewer is testing three things: can you parse English into database structure, can you work through a multi-step join without getting lost, can you use aggregation correctly. Second, they ask clarifying questions about your answer: what if nulls appear, what if a customer has multiple orders, how would you validate the result. They are testing whether you think about edge cases unprompted. Third, they ask why you chose that approach rather than another: this tests judgment.
The business question portion comes second or third depending on the firm. You are given data and asked 'what is interesting here' or 'why did revenue drop this quarter.' This is not testing whether you choose the right metric — there is no single right answer — but whether you ask the right clarifying questions before analyzing. An analyst who assumes and builds, then shows you a chart, tests worse than one who says 'I see revenue is down, but I need to know: is this across all customer segments or just one, and is the drop in volume or value.' The second is thinking like an analyst.
Communication is evaluated on every question. If you produce the correct SQL but explain it badly, you are asked to walk through it again. If you analyze data correctly but bury the conclusion in the supporting numbers, the interviewer pulls it out explicitly. This is not pettiness; it is testing whether you can work with non-technical stakeholders, because the skills are only useful if someone acts on them.
The specific artefacts that change how interviewers see you
A portfolio page with five dashboards has no weight. A portfolio page with one analysis you can walk through in two minutes has enormous weight. The interview will ask: why did you look at this question, what did you discover, what would you recommend based on this. If you cannot answer all three in detail, you have not finished the work. Many analysts build charts and stop. The analysis phase — deciding what it means and what to do about it — is often skipped or treated as 'let the numbers speak for themselves.' But numbers do not speak; you have to choose which numbers matter and say why.
Choose a dataset that is interesting to you personally and question-first. Do not pick a dataset then look for questions. 'I wonder whether customer retention differs by signup month' is a better starting point than 'I found a dataset about customers, let me plot signup month.' The better project starts with specificity. You should be able to explain why you chose this question in one sentence, and the sentence should be about a decision someone might make, not about what the data contains.
Walk through the analysis step-by-step in your portfolio. Show the raw data you started with. Show a few rows of the joined result. Show the SQL or spreadsheet formula you used. Show the final number. Show your summary in a paragraph. The most important piece is the last one: not 'revenue by product is X, Y, Z' but 'customers who churn within three months are disproportionately in segment C, so we should focus retention efforts there because the payback period would be six months.' An interviewer reading this knows you can think like an analyst.
Frequently asked questions
How long should I spend on SQL before moving to the BI tool stage?
Until you can write a moderately complex query — a three or four table join with grouping and a where clause — in under two minutes without looking up the basic syntax. You do not need to know every SQL function; you need to be fast enough that the tool is not the bottleneck. Three to four weeks if you are coding regularly is realistic for someone starting from zero.
Which BI tool is best for interviews — Power BI, Tableau or Looker?
The tool matters far less than ability to design a dashboard someone would open twice. Power BI is most common in corporate analytics, Tableau in agencies, Looker in tech. Start with whichever is free and fits your target industry. Master one deeply — employers test tool specifics far less than they test reasoning about what metrics matter and how to present them.
Do I need to learn Python for an analyst role?
Not to get hired; most screening is SQL. Learning Python is useful later for automation and reproducible analysis. But candidating on Python fluency without SQL is a common mistake. Prioritize SQL until you are comfortable, then add Python if the roles you want explicitly list it as required.
How do I know if my analysis is deep enough or if I should dig deeper?
Stop when you can write a one-paragraph conclusion that a manager could act on without reading any numbers. If you find yourself writing 'but it depends on X' or 'I should also look at Y,' you are not done. Go investigate X or Y. A complete analysis needs either an answer or an explicit note of what data you would need to answer it.
Should I focus on learning statistics theory or practical statistics first?
Practical first. Learn when to use a median instead of a mean, what a percentile means, why sample size matters, what 'statistical significance' actually requires. Theory comes after you have built intuition through examples. An analyst who cannot explain a concept in plain language has not understood it well enough, even if they can derive it mathematically.