Portfolio projects that do not look fake

Open a typical analytics portfolio and you can predict the next slide before it loads: Titanic survival, iris flowers, a perfect dashboard with no stakeholders, and a README that says “insights” without naming a single decision. Recruiters and hiring managers have seen a thousand of these. They are not impressed by your color palette. They are looking for evidence that you can do the job: frame a question, respect grain, handle messy data, show your work, and recommend something someone might actually do on Monday.

This post is a one-shot guide to building portfolio projects that do not look fake. You will get a project stack, a self-scoring rubric, a worked example for a fictional subscription product, and a list of habits that make even good analyses read like class assignments. No series membership required.

What you’ll learn

What “fake” means to a reviewer (and what signals trust)
A stack every strong project shows: question, data reality, method, checks, narrative, decision
How to pick a problem that is narrow enough to finish and real enough to matter
A filled rubric you can use before you publish a repo or case study
Common portfolio mistakes and a weekend practice sprint

What “looks fake” actually means

Fake is not “used public data.” Public data is fine. Fake is “pretended the hard parts did not exist.” Reviewers notice patterns:

Perfect tables with no missingness story
Metrics with no definition paragraph
Charts that answer a question nobody asked
SQL that never checks row counts after joins
Conclusions that could not change a budget, a roadmap, or an ops process
AI-polished prose that never shows a doubt, a dead end, or a tradeoff

Real work is messy in structured ways. You document assumptions. You show a wrong join you fixed. You admit a data gap. You recommend a decision with a confidence note. That is the texture portfolios usually sand off.

The believable project stack

Treat a portfolio piece like a thin slice of production analysis, not a science fair board.

Portfolio project stack from business question through data method checks narrative and decision

Each layer should leave an artifact in the repo or writeup:

Layer	What it answers	Artifact
Question	Who needs what decision by when?	`question.md` with success criteria
Data reality	What exists, what is broken, what grain?	Data dictionary notes + quality notes
Method	How did you compute the answer?	SQL/Python with comments on grain
Checks	Why should anyone trust the number?	Assertions, row counts, edge cases
Narrative	What should a busy reader take away?	One-page memo, not a novel
Decision	What changes if we believe you?	Explicit recommendation + risks

If a layer is missing, the project starts to look like a tutorial clone even when the code is clever. Clever without a decision is still homework.

Choose a problem that can finish

Ambitious titles kill portfolios. “AI-powered global retail brain” is not a project. “Which customer segment should we call first for renewal next month?” is a project.

Good problem shapes

A weekly or monthly metric that operations already fights about
A funnel step with leakage and a proposed intervention
A cohort or retention question with a clear definition choice
A cost or unit economics question with one recommended experiment

Weak problem shapes

Generic EDA with no decision owner
Predictive models with no cost of false positives
Dashboard galleries with twelve pages of filters
Kaggle clones with leaderboard scores as the only outcome

If you lack a workplace problem, invent a realistic stakeholder and stick to them. Write their name, role, and constraint in the README. Reviewers know it is simulated. They still prefer a coherent fiction to a leaderboard number with no human in the story.

Make the data look like work data

You do not need private company extracts. You need the behaviors of work data:

Missing values that matter (not random noise only)
Duplicate keys or late-arriving events
Timezone or currency traps if relevant
A definition choice (is trial revenue “revenue”?)
A join that can fan out if you are careless

Document what you did about each issue. A paragraph that says “we excluded test accounts tagged is_internal = true because they inflate activation” is more impressive than a neural net nobody asked for. Habits from the data quality series belong in portfolio writeups, not only in production teams.

Show method without drowning the reader

Hiring managers skim. Engineers dig. Serve both.

Top of README: question, answer, recommendation in under 15 lines
Then: metric definitions in plain English
Then: method outline (bullet steps, not a diary)
Then: links to SQL/Python and a short checks section
Appendix: full notebooks only if needed

Use SQL when the work is warehouse-shaped. Use Python when files, APIs, or charts need it. Do not rewrite clear SQL in pandas just to prove you know both. If AI helped draft code, say so and show how you verified it. The verification story is the skill. For a practical checklist mindset on model-written queries, see how to check AI-written SQL.

The self-scoring rubric

Before you publish, score yourself honestly. Aim for “hireable, not perfect.”

Filled portfolio rubric scoring question data method checks narrative and decision layers

Use this scoring table (0-2 each). A strong public project usually lands 9 or higher out of 12 without needing a PhD-level model.

Criterion	0	1	2
Question	Topic only	Question without owner/time	Owner, decision, time horizon
Definitions	Metric names only	Partial definitions	Written grain + inclusions/exclusions
Data reality	Clean demo data story	Some issues mentioned	Issues + handling + residual risk
Method clarity	Code dump	Some structure	Readable steps a peer can re-run
Checks	None	One ad-hoc check	Multiple checks tied to failure modes
Decision	Vague insight	Suggestion without tradeoffs	Action + risk + next measurement

If you score a 0 or 1 on Question or Decision, fix those before you polish charts. Pretty charts on a non-decision are still fake.

Worked example: Northline SaaS renewals

Imagine a fictional B2B product, Northline. Stakeholder: Priya, Head of Customer Success. Decision: which accounts the CS team should prioritize for renewal outreach in the next 30 days, given a limited call capacity of 120 accounts.

Question written in the repo:

Which 120 accounts renewing in the next 60 days should CS call first to maximize retained ARR, given we can only work 120 accounts this month?

That sentence already beats “churn analysis.” It names capacity and a business unit of value (ARR).

Definitions (excerpt)

Account grain: one row per account_id on the prioritization date
Renewal window: contract end date within the next 60 days
At-risk flag (v1): product usage drop ≥30% month-over-month or two or more severity-1 tickets in 45 days
Excluded: free tier, internal accounts, already in legal dispute

You can argue with those rules. That is good. Argueable rules are adult analytics. Silent rules are fake polish.

Method sketch in SQL

WITH renewing AS (
  SELECT
    a.account_id,
    a.arr,
    a.contract_end_date,
    a.csm_owner
  FROM accounts a
  WHERE a.plan_tier <> 'free'
    AND a.is_internal = FALSE
    AND a.in_legal_dispute = FALSE
    AND a.contract_end_date BETWEEN CURRENT_DATE
      AND CURRENT_DATE + INTERVAL '60 days'
),
usage AS (
  SELECT
    account_id,
    SUM(CASE WHEN month_offset = 0 THEN active_seats END) AS seats_m0,
    SUM(CASE WHEN month_offset = 1 THEN active_seats END) AS seats_m1
  FROM account_monthly_usage
  GROUP BY 1
),
tickets AS (
  SELECT
    account_id,
    COUNT(*) AS sev1_45d
  FROM support_tickets
  WHERE severity = 1
    AND created_at >= CURRENT_DATE - INTERVAL '45 days'
  GROUP BY 1
)
SELECT
  r.account_id,
  r.arr,
  r.contract_end_date,
  r.csm_owner,
  CASE
    WHEN u.seats_m1 IS NULL OR u.seats_m1 = 0 THEN NULL
    ELSE (u.seats_m0 - u.seats_m1) * 1.0 / u.seats_m1
  END AS seat_drop_pct,
  COALESCE(t.sev1_45d, 0) AS sev1_45d,
  CASE
    WHEN COALESCE(t.sev1_45d, 0) >= 2 THEN TRUE
    WHEN u.seats_m1 IS NOT NULL
      AND u.seats_m1 > 0
      AND (u.seats_m0 - u.seats_m1) * 1.0 / u.seats_m1 >= 0.30
      THEN TRUE
    ELSE FALSE
  END AS at_risk_v1
FROM renewing r
LEFT JOIN usage u USING (account_id)
LEFT JOIN tickets t USING (account_id);

Checks you show in the writeup

Row count of renewing equals distinct accounts in window after exclusions
No duplicate account_id in the final prioritization table
Sum of ARR in final top 120 vs total renewing ARR (coverage story)
Sensitivity note: if seat drop threshold moves from 30% to 20%, how many more accounts flip to at-risk?

A tiny check snippet (Python or SQL) belongs in the repo:

assert prioritization["account_id"].is_unique
assert prioritization["arr"].min() >= 0
assert prioritization.query("at_risk_v1")["account_id"].nunique() > 0
# coverage: top 120 by score should not be empty when capacity is 120
assert len(top_120) == min(120, len(prioritization))

Decision paragraph (the part people skip writing)

Example memo ending:

“Prioritize the 120 accounts with highest arr among at_risk_v1 = true. If fewer than 120 are at-risk, fill remaining slots by ARR among not-at-risk renewals so capacity is not wasted. Risk: usage data lags by up to three days; re-run every Monday. Do not treat this as a churn model. It is an operations queue for CS capacity. Next measurement: compare renewal rate of called vs not-called accounts in the same risk band after 60 days.”

That is portfolio signal. Not “we found insights about customers.”

Presentation choices that reduce fake vibes

One primary chart, not twelve. Annotate the decision threshold.
Show a dead end: “We tried ticket volume alone; it ranked tiny accounts with noisy support.”
Keep AI prose under control. Short sentences. Your voice. No hype.
Link related learning without padding: SQL practice on the SQL series, metric clarity via the metrics series, and broader paths on Learn.
License and data source line for public datasets. Ethics is part of professionalism.

How many projects?

Two excellent projects beat six half-built dashboards. A common strong set:

One SQL-heavy decision analysis (warehouse thinking)
One end-to-end piece with light Python (files, chart, memo)
Optional third: a quality or experiment design writeup if that is your target role

Depth in definition and checks matters more than stacking every library on PyPI.

Common mistakes

Tool museum: Spark, dbt, Airflow, three BI tools, no decision.
Accuracy theater: model scores without business cost of errors.
Invisible grain: weekly and daily mixed until charts lie.
No stakeholder voice: analysis floating in space.
Secret sauce opacity: code so clever nobody can audit it in an interview.
Resume-driven metrics: vanity KPIs that nobody in a real company would fund.
Copy-paste AI README: generic “using synergies” paragraphs. Delete them.

Practice: a weekend anti-fake sprint

Block six hours across a weekend.

Hour 1: write the question with owner, capacity constraint, and success metric.
Hour 2: write definitions and exclusion rules before touching charts.
Hours 3-4: implement one method path and three checks.
Hour 5: write the one-page memo with a decision and a risk.
Hour 6: score the rubric. Fix the lowest criterion only. Publish a draft folder even if ugly.

Ugly and decision-ready beats pretty and hollow. You can polish later.

Quick recap

Fake portfolios hide mess, definitions, and decisions. Real ones show them cleanly.
Use the stack: question, data reality, method, checks, narrative, decision.
Pick finishable problems with a named stakeholder and constraint.
Score yourself with a rubric before you redesign charts.
Two deep projects beat a zoo of clones.
Verification stories (including AI verification) are part of the portfolio, not a confession to hide.

Sources

Google re:Work, hiring and structured interviewing principles (signal over polish): https://rework.withgoogle.com/
US Bureau of Labor Statistics, Occupational Outlook for data-related roles (what work often includes): https://www.bls.gov/ooh/
Hadley Wickham, Tidy Data (Journal of Statistical Software) on structure and clarity of datasets: https://www.jstatsoft.org/article/view/v059i10
PostgreSQL documentation (practical SQL reference for portfolio queries): https://www.postgresql.org/docs/current/
The Turing Way, Guide for Reproducible Research (documentation and project hygiene): https://the-turing-way.netlify.app/
Microsoft, data analytics career learning paths (role skill framing, not a required vendor path): https://learn.microsoft.com/en-us/training/paths/data-analytics-microsoft/