Topic 11 — Landing the data analyst job

Goal: Turn your skills into a portfolio, resume, and interview performance that gets you hired.

Lesson 11.1 — The thing on your resume you almost deleted

Nadia spent six years running inventory and weekly sales reports for a chain of furniture stores before she decided to become a Data Analyst. When she started drafting her resume, her instinct was to bury the retail years — they felt like the before, the part she was leaving behind. She nearly cut them entirely to make room for "Learning SQL."

That instinct is exactly backwards, and a recruiter at Perch told her so in the first five minutes of her phone screen. What got Nadia the interview wasn't a certificate. It was the line "managed weekly stock and sales reporting across 11 stores." She already knew what a slow-moving sofa looked like in a spreadsheet, what "we're overstocked" actually costs, and how to tell a regional manager bad news without losing the room.

That is the transferable background advantage: employers hiring an entry-level analyst are buying more than SQL. They are buying someone who understands the business the data describes. The tools can be taught in months. Business judgment takes years, and Nadia already had it.

Companies don't hire analysts to run queries. They hire analysts to answer questions — and you can't answer a question you don't understand.

The move is to translate, not hide. Every time you used numbers to make or defend a decision, that was analysis, even if nobody called it that. "Tracked monthly budgets and flagged overspending" is evidence you can work with data and communicate what you found. Nadia listed every skill from this course on the left side of a page, and on the right she paired each one with a real moment from the stores. "Data cleaning" sat next to "reconciled three POS exports that never agreed." That page became her resume's backbone.

Lesson 11.2 — The proof a resume can only promise

Here is the problem with a resume: anyone can write "proficient in SQL." A hiring manager reading two hundred applications has no way to tell the people who can do the work from the people who can describe it.

A portfolio solves that. It's two or three finished projects, built on free public data, published where anyone can see them. A resume claims you can do the work. A portfolio shows it, end to end, which is why it's the single most convincing thing a career-changer can put in front of an employer.

Nadia's mentor Priya gave her the rule that saved her from the most common mistake: two or three deep projects, not ten shallow ones. Ten half-finished notebooks signal someone who starts and quits. Three complete projects, each answering a real business question, signal someone who can be trusted with a real one.

Where does the data come from when you don't have a job yet? Free public sources:

• Kaggle — thousands of clean, downloadable datasets. The Telco Customer Churn set (about 7,000 customer records, 21 columns) is a classic because churn is a question every business actually cares about.
• data.gov and other government open-data portals — real, messy, civic-scale data on transit, health, spending, and more.
• Public company data — financials, app-store reviews, sports stats, anything you can legally download and that maps to a question someone would pay to answer.

Nadia picked furniture-adjacent data on purpose: a public retail-sales dataset, because she could reason about it. She knew what a sane number looked like, so she could catch the data when it lied.

Lesson 11.3 — What makes a project worth showing

A folder of charts is not a portfolio project. Nadia's first attempt was exactly that — twelve plots, no point — and Priya's feedback was one question: "So what should the business do?"

A project worth showing tells a complete story, in this order:

1. A clear question. Not "explore this dataset" but "which customers are most likely to stop buying, and what do they have in common?" The question is the whole frame.
2. The data and cleaning work. What you fixed, what you threw out, and why. This is where you prove you noticed the data was dirty (it always is).
3. The analysis, with the right statistics. The actual finding, supported correctly — not a correlation dressed up as a cause.
4. A few clean visuals. Three sharp charts beat thirty. Each one earns its place by making one point.
5. A "so what" conclusion. The recommendation, in plain business language. The line a busy VP could act on.

Then publish it with a README that explains your methodology: what you asked, where the data came from, how you cleaned it, what you found, and what you'd recommend. The README is what a hiring manager reads first. A brilliant analysis with no explanation reads like luck. A clearly-explained one reads like a colleague.

Nadia's churn project ended with a single sentence: customers who never received a follow-up email within 30 days of their first order were nearly twice as likely to never order again. That sentence — a clear recommendation, not a number dump — is what she got to talk about in every interview after.

Lesson 11.4 — A resume two machines and one human will read

Nadia's resume went into a portal, and the first thing that read it wasn't a person. Most companies run applications through an applicant-tracking system (ATS) that scans for specific terms before a human ever sees the page. Then a recruiter skims it for six seconds. Then, maybe, a hiring manager reads it properly. The resume has to survive all three.

Surviving the scan means leading with the skills employers actually search for:

• SQL — non-negotiable for analyst roles.
• Excel / Google Sheets — still in roughly 40% of analyst postings; don't skip it because it feels basic.
• A BI tool — Tableau, Power BI, or Looker. Name the specific one you used.
• Data cleaning and data visualization — the verbs of the actual job.

Then reframe every bullet around an outcome, not a task. "Built weekly reports" is a task. "Automated weekly reporting, cutting prep time by 40%" is an outcome — it has a verb, a result, and a number. Nadia rewrote each retail bullet this way, and her resume stopped reading like a list of chores.

Three more rules Priya drilled in: link the portfolio near the top, where it can't be missed. Keep it to one page — for an entry-level role, two pages reads as padding. And tailor it per role: a posting heavy on dashboards gets her Tableau work up front; one heavy on SQL leads with the database projects. Same Nadia, different emphasis, aimed at the specific job instead of sprayed at all of them.

Lesson 11.5 — Surviving the four interviews inside the interview

The analyst interview is really several tests wearing one calendar invite. Nadia learned to recognize each so none of them ambushed her.

The SQL test is the most common technical screen, and it's often timed. Modern tests have moved past basic SELECT. Expect JOINs, GROUP BY with HAVING, and — increasingly the part that filters people out — window functions for top-N questions: "find the top 3 products in each category by revenue." That's ROW_NUMBER() or RANK() over a partition.

Know the difference, because interviewers test it on purpose. For sales of 100, 100, 90: ROW_NUMBER gives 1, 2, 3 (always unique, ties broken arbitrarily); RANK gives 1, 1, 3 (ties share, then it skips); DENSE_RANK gives 1, 1, 2 (ties share, no gap). And the classic trap: you cannot write WHERE ROW_NUMBER() OVER (...) <= 3 directly — the WHERE clause runs before the window function exists. The fix is always to compute the ranking in a CTE or subquery, then filter on it outside:

WITH ranked AS (
  SELECT category, product, revenue,
         ROW_NUMBER() OVER (PARTITION BY category ORDER BY revenue DESC) AS rn
  FROM sales
)
SELECT category, product, revenue
FROM ranked
WHERE rn <= 3;

The only way through is reps: write dozens of small queries until the syntax is automatic and you're free to think about the question instead of the comma.

The case or take-home hands you a dataset and says "find something interesting." It's testing the whole workflow — clarifying the question, cleaning, analyzing, explaining — not one clever number. So narrate your thinking in business terms. State your question, name your assumptions, show the cleaning, and end with a recommendation a non-technical person could act on.

Behavioral questions — "tell me about a time your analysis changed a decision" — want a story, not a philosophy. Use STAR: the Situation, the Task, the Action you took, the Result, with a real number if you can. Nadia kept three such stories ready from the stores. One ended "...and we cut the dead inventory by a third the next quarter," and that result is what made it land.

Worked example — Nadia gets the offer at Perch

Perch, a 150-person online furniture retailer trying to grow repeat purchases, posts an entry-level analyst role. Watch the whole chain work.

The resume. Nadia leads with SQL, Tableau, Excel, and data cleaning so the ATS catches her. Her retail bullets are now outcomes: "automated 11-store weekly reporting, cutting prep time ~40%." Her portfolio link sits under her name. She tailors the summary to mention repeat customers, because the posting is all about retention.

The portfolio. Her churn project — built on public retail data — answers exactly the question Perch is trying to solve. The README walks through the question, the cleaning, the analysis, and the one-line recommendation about follow-up emails. The hiring manager reads it before the call and already half-believes she can do the job.

The SQL screen. Timed, 30 minutes. The hard question: top 2 best-selling products per category. Nadia writes a CTE with ROW_NUMBER() OVER (PARTITION BY category ORDER BY units DESC) and filters rn <= 2 outside it. She doesn't fall into the WHERE-clause trap, because she'd written that pattern twenty times that month.

The take-home. Perch sends 90 days of orders: "find something useful." Nadia doesn't just report a number. She frames the question (what predicts a second purchase?), shows her cleaning, and ends with: buyers who got a delivery within five days reorder at nearly double the rate of those who waited two weeks — and recommends Perch investigate shipping speed. She writes for Dana, the non-technical VP, who wants the answer in one sentence.

The behavioral round. Marcus asks for a time her analysis changed a decision. Nadia tells the dead-inventory story in STAR form, lands the "cut it by a third" result, and the loop is over. Offer.

One role. A translated background, a portfolio that mirrored the company's real problem, a resume built to be scanned, and four interviews she saw coming. That's the whole playbook this topic exists to give you.