I sat on a hiring panel where we had ninety minutes and forty applications. That works out to slightly over two minutes each, and nobody was reading anything twice. The candidate who got the interview had a link near the top of her CV that opened a single page: a question, a chart, four sentences of finding, and one line saying what she would change if it were her budget. I never opened her repository. I did not need to.

That is the whole game at the entry level, and it is not the game most people prepare for. Twenty one parts of this series taught you to query, clean, model and present. This last one is about making somebody who has never met you believe it in under three minutes.

What a portfolio is actually for

Most beginners build a portfolio to prove they can use tools. That is the wrong target, because tools are the cheapest thing to verify. Anyone can check whether you know pandas by asking you one question in an interview. What nobody can check in an interview is whether you can take a vague business question, decide what to measure, notice that the data does not quite answer it, and say so out loud without being asked.

A portfolio is evidence of judgement. It is the only artefact you control that shows how you think when nobody is watching. That reframing changes what you build. A notebook that loads a clean dataset and produces a correlation heatmap demonstrates that you can follow instructions. A short write up that says the join dropped eleven percent of rows, here is why, and here is what I did about it, demonstrates that you can be trusted with a table nobody has looked at closely.

The second thing a portfolio does is give the interviewer something to talk about. Interviews for junior roles are hard to run because there is nothing concrete to discuss. If you hand over a project, the conversation becomes a walkthrough of work you did and understand completely, on your terms, and you stop being asked to recite definitions. I have watched nervous candidates transform the moment we switched from questions to their own project.

So the test for every piece of work you publish is simple. Does it show a decision you made and defended? If the answer is no, it is a tutorial, and tutorials do not count no matter how polished the charts are.

Three projects, not ten

Volume works against you. A reviewer with two minutes will open one thing, and if your page lists ten projects they will open the first one, find it thin, and close the tab. Three projects, each finished, each different in what it demonstrates, is the shape that survives a fast read.

I would split them like this. One SQL heavy project against a database with more than one table, where the interesting part is the join logic and the aggregation, drawing on Part 7 and Part 8. One cleaning and exploration project against a genuinely messy public file, where the write up is mostly about what you found wrong and how you decided to handle it. One dashboard, built for a named audience, that answers a question somebody would actually ask.

Then bias one of them towards the industry you want to work in. If you are applying to hospitals, use health data. If you are applying to retail, use transactions. This costs you nothing and it is the single highest return decision in the whole portfolio, because it moves you from a generic applicant to somebody who already speaks a little of the local language. An interviewer at a logistics company who sees a delivery time analysis will ask you about it, and now you are having a conversation about their problem rather than about your CV.

One more note on scope. Junior candidates consistently pick projects that are too large, run out of energy at the cleaning stage, and end up with three unfinished notebooks. A project that answers one narrow question completely is worth more than an ambitious one abandoned at week three. Finish beats impressive.

United States figures from the Occupational Outlook Handbook. These are medians across all experience levels, not starting salaries, and a first analyst job will normally sit well below them. Outside the United States the ratios hold better than the absolute numbers.

Anatomy of a project that gets read

Three artefacts, in this order of importance. A one page summary. A visible result, meaning a dashboard or a chart somebody can look at without installing anything. And the working, meaning the repository or notebook where the query lives. Most beginners build these in exactly the reverse order and then wonder why nobody engages.

The one page summary carries five things. The question, phrased the way a business person would phrase it. The data, one line on where it came from and how big it is. What you had to fix, which is where your cleaning judgement shows. The finding, stated as a sentence with a number in it rather than as a chart caption. And the recommendation, including what you would need to be more confident, because saying what would change your mind is the most senior thing a junior candidate can do.

Keep the tooling boring. A hosted dashboard link, or a rendered notebook, or even a well formatted page. What matters is that it opens in a browser with no setup. If a reviewer has to clone a repository and install dependencies to see your work, they will not see your work. That sounds unfair and it is completely reasonable when you have forty applications and ninety minutes.

Where to find data worth analysing

The competition problem is real. Titanic, Iris and the handful of tidy teaching datasets appear in hundreds of portfolios, and a reviewer who has seen them fifty times reads them as evidence that you finished a course rather than that you had an idea. Worse, they are pre cleaned, which removes the exact skill you most need to demonstrate.

Government open data portals are the reliable answer. National statistics offices, city transport authorities, health services and regulators all publish messy operational data with real gaps, inconsistent labels and format changes halfway through the time series. That mess is the feature. So is the fact that the domain is legible: everybody understands what a late train or an unfilled prescription means, which makes your finding easy to explain in an interview.

Two other sources are underused. Data you generate yourself, from a hobby, a small local business, a club you belong to, produces a project nobody else on earth has. And an organisation you already volunteer with will often hand over a spreadsheet nobody has ever analysed, which gives you a stakeholder, a real question and a genuine deadline, all of which are worth more than the dataset itself.

Whatever you pick, apply the privacy checks from Part 21 before you publish anything. A portfolio project built on real people, with the location and date fields sensibly coarsened and a note explaining why, reads as professional in a way that no chart ever will.

flowchart LR
  A[Pick a domain you can explain] --> B[Find an open dataset with real mess]
  B --> C[Write the question before you query]
  C --> D[Clean and log every decision]
  D --> E[One chart that answers it]
  E --> F[One page summary]
  F --> G[Publish where it opens in a browser]
  G --> H[Send it to one person for a reaction]
  H --> C

Do certificates help?

Yes, narrowly, and less than the marketing suggests. A certificate does one job well: it gets you past a screening filter run by somebody who is not an analyst and needs a reason to move your CV to the second pile. It does not help you in a technical interview, because the interviewer will ignore it and ask you to reason about a table.

Given that, buy the cheapest thing that clears the filter and spend the rest of your budget on time. If you are starting from nothing, a broad entry certificate gives you structure and a deadline, which is worth real money when you are learning alone. If you already have the skills from this series, a tool specific credential is the better buy, because it is the one a hiring manager recognises as tied to something they use.

The tool specific option most worth knowing about is the Microsoft Power BI Data Analyst Associate credential, earned by passing exam PL-300. The exam is proctored, you get 100 minutes, and it covers preparing, modelling, visualising and securing data in Power BI. Note that it expires after twelve months and is renewed by a free online assessment, so the ongoing cost is time rather than money. Price varies by country and Microsoft does not publish a single global figure, so check the schedule page for your region before budgeting.

What I would not do is collect them. Three certificates and no projects is a recognisable pattern and it reads as avoidance, because completing a course is comfortable and publishing your own analysis is not.

Costs are indicative and change. Verify current pricing on the provider page before committing, and note that the exam fee for PL-300 is set regionally rather than globally.

The job hunt as a pipeline

Treat the search itself as a dataset, because you now have the skills to. Track every application in a sheet with the date, the company, the source, the stage you reached and the reason it ended. After thirty applications you can see which stage is leaking, and the fix is different at every stage.

If you never hear back at all, the problem is the CV or the targeting, not your skills. If you get screening calls but no technical round, the problem is how you talk about your experience. If you reach technical rounds and stop there, that is a genuinely good position, because it means the pipeline works and only the SQL needs practice. Most people conclude they are unqualified when the actual finding is that they applied to twelve jobs with a CV that did not mention SQL in the first six lines.

One structural note about titles. Junior analyst roles are scarce and heavily contested, while roles with analytical work hidden inside an operational title are not: operations coordinator, reporting associate, revenue analyst, business support. Getting hired into one of those and becoming the person who builds the reports is the most common real path into analytics that I have watched people take. It is slower on paper and much faster in practice.

flowchart TD
  A[30 applications logged] --> B{Any replies}
  B -->|No| C[Fix the CV and the targeting first]
  B -->|Yes| D{Reaching a technical round}
  D -->|No| E[Rewrite how you describe your projects]
  D -->|Yes| F{Passing the technical round}
  F -->|No| G[Drill joins, aggregation and one case question a day]
  F -->|Yes| H[Offer stage, negotiate on scope not just salary]
  C --> A
  E --> A
  G --> A

What interviewers ask a junior analyst

Four things, in roughly this proportion. A SQL exercise, usually a join plus a grouped aggregation, occasionally a window function. A case question, where you are given a vague business situation and asked what you would measure. A walkthrough of one of your own projects. And a communication check, which is normally hidden inside one of the other three.

The SQL is the easiest to prepare and the least discriminating, because most candidates can do it. Where people fall down is the case question, and the failure mode is answering too fast. If somebody says signups dropped last month, work out why, the wrong move is to start listing causes. The right move is to ask what the number is measuring, whether the drop is outside normal variation, and whether anything changed in how it is counted, which is exactly the reasoning from Part 3 and Part 17. Half the time the answer is a tracking change, and the candidate who checks that first is the one who gets hired.

For the project walkthrough, prepare a two minute version and stop talking. Question, what you found, what you would do next. Then let them ask. Candidates who narrate for eight minutes are demonstrating the exact behaviour that makes stakeholders dread analyst meetings, and everybody in the room notices.

Pick one dataset this weekend and ship by Sunday

Here is the recommendation for this part, stated plainly. Do not build a portfolio. Build one project, this weekend, small enough to finish in two days, on a public dataset from a domain you can explain to your family. Write the one page summary first, before you have any results, with the numbers left blank. Then fill them in. Publish it somewhere it opens in a browser, and send the link to one person who will tell you the truth.

Do that three times over six weekends and you have the portfolio, without ever having planned one. The reason I would sequence it this way rather than designing the set up front is that your first project will be worse than you expect and your third will be better than you expect, and the only way to get to the third is to finish the first badly.

As for what to learn next, the honest answer is nothing new for a while. You have covered SQL, spreadsheets, cleaning, statistics, visualisation, dashboards, pandas, metrics, experiments, modelling and ethics across this series. The gap between you and a working analyst is now repetition rather than curriculum. Once you are in a role and the repetition is happening at work, the two directions that pay off soonest are deeper SQL against production sized tables and a proper grip on the warehouse your company actually uses.

If any part of the ground here feels shaky, the Data Analyst guide holds the whole series in order, and Part 1 is worth rereading now that the words in it mean something to you.

Open a data portal today, download one file, and put an hour into it before you close the tab. That single hour is the difference between finishing this series and using it.

References

• Data Scientists, Occupational Outlook Handbook, US Bureau of Labor Statistics
• Microsoft Certified: Power BI Data Analyst Associate, exam PL-300
• Google Data Analytics Professional Certificate, Coursera
• Data.gov, the US open data catalogue

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts