Most data beginners get stuck in tutorial hell, collecting certificates without building anything. This lesson gives you a phase-by-phase framework — with specific projects, daily structures, and interview prep timelines — to go from zero to your first real interview in 90 days. No fluff, no vague advice.
Here's a scenario that plays out constantly in data career forums: someone decides they want to break into data, spends six months watching YouTube tutorials and completing Coursera courses, and then freezes when it's time to actually apply for jobs. They have a certificate, maybe two, but no portfolio. No GitHub. No concrete projects they can speak about with confidence. They've been learning about data work without actually doing data work. Three months later, they're still "getting ready."
This lesson is designed to break that pattern. The 30-60-90 day plan we're building together isn't a curriculum checklist — it's a structured progression that mirrors how professionals actually develop competence: through deliberate skill-building, increasing project complexity, and iterative exposure to the interview process. By following this framework, you'll arrive at your first job interview having built real things, having made real mistakes, and having fixed them. That experience is worth more than any certificate.
By the end of this lesson, you'll have a concrete, personalized 30-60-90 day roadmap you can start executing this week. You'll understand not just what to learn, but how much time to spend on each area, when to stop studying and start building, and how to get job-ready without waiting until you feel "ready."
What you'll learn:
This lesson assumes you understand what data roles exist (analyst, engineer, scientist) and have a rough sense of which direction you're heading. You should have a computer with internet access and the ability to install software. You don't need any prior programming experience — but you do need to be honest with yourself during the skills audit in the next section.
Before you build a plan, you need to know where you actually stand — not where you hope you stand, and not the version of yourself you'd like to present on LinkedIn. This audit takes about 90 minutes and it's the foundation everything else sits on.
Open a spreadsheet. Create five columns: Skill Area, Current Level (1-5), Evidence, Target Level, and Gap.
Now rate yourself honestly across these categories:
SQL — Can you write a SELECT statement? Can you GROUP BY and use aggregate functions? Can you write a JOIN across two tables? Can you write a subquery? Can you write window functions like ROW_NUMBER or LAG?
Python or R — Can you load a CSV and inspect it? Can you filter rows and select columns with pandas or dplyr? Can you create a basic visualization? Can you write a function?
Spreadsheets — Can you use VLOOKUP or INDEX/MATCH? Can you build a pivot table? Can you write an IF statement?
Statistics — Can you explain mean, median, and standard deviation in plain language? Can you explain what a p-value is (and what it isn't)? Do you understand distributions and correlation?
Data Visualization — Have you ever built a dashboard in any tool? Can you explain what makes a chart misleading?
Business Communication — Can you translate a number into a business insight? Have you ever presented data to a non-technical audience?
For each skill, your "Evidence" should be a concrete example — not "I watched a SQL course" but "I wrote queries against the Northwind database that joined four tables and calculated monthly revenue by region." If you can't name specific evidence, your rating is probably inflated.
This audit tells you two things: where to start in Phase 1, and which skills are genuinely foundational versus which ones can wait.
A word on role-specific targeting: A data analyst role requires strong SQL, solid spreadsheet skills, and good visualization. A data engineer role front-loads Python and cloud infrastructure. A data scientist role requires more statistics and machine learning. Know which door you're walking toward before you build your plan.
Most people build learning plans that are basically just topic lists. They write down "learn SQL, learn Python, learn Tableau" and then start at the top. The problem is that this creates no momentum and no feedback loops. You spend weeks on fundamentals with no idea whether you're actually getting good at anything.
The 30-60-90 framework is built around a different principle: each phase has a different primary purpose.
Notice that interview prep doesn't start until Day 61. That's intentional. Too many beginners split their attention between learning and job prep from day one, which means they do both things poorly. You need a technical foundation before behavioral interview prep means anything.
The other thing this structure does is force you to stop learning and start building at Day 31. That transition is the hardest part for most people, and we'll address how to manage it directly.
Phase 1 is not about becoming proficient. It's about becoming functional. You need to reach the point where you can look at a dataset, ask questions about it, and produce answers. That's it. Mastery comes later — in Phase 2, when you have real problems to solve.
Think of it like learning enough of a new city to get from the hotel to the conference center. You're not memorizing the whole map. You're learning the minimum navigable terrain.
If you're targeting any data role except pure data engineering, SQL is your highest-leverage investment in Phase 1. Here's why: SQL is the language of data that already exists inside organizations. Every company has databases. Every data role touches those databases. And SQL is genuinely learnable at a functional level in two to three weeks.
Your Phase 1 SQL goal: be comfortable with SELECT, WHERE, GROUP BY, HAVING, JOINs (inner, left, right), subqueries, and basic aggregate functions (COUNT, SUM, AVG, MIN, MAX).
Don't spend three weeks on SQL courses. Spend one week on a structured course (Mode Analytics SQL Tutorial and SQLZoo are both excellent and free), then immediately switch to working on real datasets. The Northwind database, the Chinook database (a music store schema), and the Stack Overflow public dataset on BigQuery are all excellent practice grounds because they have multiple related tables and enough rows that your queries actually need to be well-formed.
Here's a concrete practice exercise that will reveal whether your SQL fundamentals are solid:
-- Using the Chinook database: find the top 5 customers by total spend
-- in each country, along with their total invoice amount
-- This requires JOINs, aggregation, and a window function
SELECT
customer_country,
customer_name,
total_spend,
country_rank
FROM (
SELECT
c.Country AS customer_country,
c.FirstName || ' ' || c.LastName AS customer_name,
SUM(i.Total) AS total_spend,
RANK() OVER (
PARTITION BY c.Country
ORDER BY SUM(i.Total) DESC
) AS country_rank
FROM Customer c
JOIN Invoice i ON c.CustomerId = i.CustomerId
GROUP BY c.Country, c.CustomerId, c.FirstName, c.LastName
) ranked
WHERE country_rank <= 5
ORDER BY customer_country, country_rank;
If you can write this query from scratch after two weeks of practice — without looking at the syntax — your SQL fundamentals are solid enough for Phase 2. If you're still searching for how window functions work, spend another few days on that specifically before moving on.
If you're aiming for an analyst role, Python is important but secondary to SQL in Phase 1. If you're aiming for engineering or data science, flip those priorities.
Your Phase 1 Python goal is deliberately narrow: load a dataset, inspect it, clean obvious problems, and produce three to five basic visualizations. That's it.
Focus on these libraries: pandas for data manipulation, matplotlib or seaborn for visualization. Don't touch machine learning libraries yet. Don't touch APIs yet. Narrow focus is how you build momentum.
import pandas as pd
import seaborn as sns
import matplotlib.pyplot as plt
# Load a real dataset — this is the NYC 311 service request data, publicly available
df = pd.read_csv('nyc_311_requests.csv')
# Step 1: Actually look at what you have
print(df.shape) # How many rows and columns?
print(df.dtypes) # What data types did pandas infer?
print(df.isnull().sum()) # Which columns have missing values?
# Step 2: Identify the most common complaint types
top_complaints = (
df['Complaint Type']
.value_counts()
.head(10)
.reset_index()
)
top_complaints.columns = ['complaint_type', 'count']
# Step 3: Visualize it
plt.figure(figsize=(10, 6))
sns.barplot(data=top_complaints, y='complaint_type', x='count', palette='Blues_r')
plt.title('Top 10 NYC 311 Complaint Types')
plt.xlabel('Number of Requests')
plt.ylabel('')
plt.tight_layout()
plt.show()
The goal here isn't beautiful code. It's operational code. Can you load data, understand its shape, and communicate something from it? If yes, you're ready for Phase 2.
Phase 1 requires consistent daily practice more than it requires long weekend sessions. Ninety minutes a day, six days a week, is more effective than a seven-hour Saturday binge. Here's why: deliberate skill-building in technical domains requires your brain to consolidate information overnight. The spacing effect is real, and weekend warriors pay a steep price in retained learning.
Structure each 90-minute session like this:
The learning log is not optional. It's the mechanism by which you convert passive consumption into active understanding. When you sit down to write "today I understood why LEFT JOINs return NULLs for unmatched rows in the right table," you'll quickly discover whether you actually understood it or just watched it happen on a screen.
By Day 30, you should be able to honestly check off:
Day 31 is where most self-taught learners stall. The structure of Phase 1 — course, exercise, course, exercise — feels safe. There's always a right answer somewhere in the lesson. Phase 2 removes that safety net and asks you to work on projects where nobody has handed you the answer.
This discomfort is diagnostic, not pathological. If you're uncomfortable in Phase 2, it means you've reached the boundary of what structured learning can give you. That's the right place to be.
Your job in Phase 2: build two projects that are genuinely your own work, involve real (or realistic) data, answer a question that a business would actually care about, and live on GitHub in a state that another person could read and understand.
The most common mistake is choosing projects that are technically impressive but contextually empty. Building a sentiment analysis model on Yelp reviews might sound impressive, but if you can't explain why a business would care about the output, it doesn't hold up in an interview.
Choose projects based on this filter: Can I explain, in one sentence, why a business would pay someone to do this analysis?
Good examples:
Not-so-good examples:
For your first project, find a public dataset with multiple tables — the TPC-H benchmark dataset, the Chicago Data Portal, or Kaggle datasets with relational structure work well. Spend two weeks doing an end-to-end analysis entirely in SQL.
Your deliverable: a GitHub repository with a README that explains the business question, a SQL script with well-commented queries, and a summary document (a Markdown file is fine) that presents your findings in plain English.
The README matters more than most beginners realize. Write it as if your audience is a hiring manager who has ten seconds to understand what you did and why it matters. This is hard. Do it anyway.
Here's what a professional-quality project README structure looks like:
# Sales Performance Analysis: Regional Revenue Drivers
## Business Question
Which product categories and sales regions drove the most revenue growth
between 2022 and 2023, and what's the relationship between order volume
and discount rate?
## Dataset
TPC-H benchmark dataset (1GB scale factor), representing a fictional
parts manufacturing supply chain. Tables: orders, lineitem, customer,
nation, region, part, supplier.
## Key Findings
1. The European region showed 23% YoY revenue growth, driven primarily
by the MACHINERY category.
2. Orders with discount rates above 7% had lower average order values
but higher volume — suggesting a price-elastic customer segment.
3. Three supplier nations (Germany, France, Brazil) account for 61% of
high-priority order fulfillment.
## Technical Approach
- Data exploration: row counts, null checks, date range validation
- Revenue analysis: window functions for YoY growth calculation
- Discount analysis: correlated subquery to compare discount tiers
## Files
- analysis.sql: All queries, commented
- findings.md: Detailed narrative
Your second project should use Python to do something your SQL-only project couldn't. That might mean richer visualizations, data cleaning that requires programmatic logic, combining multiple data sources, or building a simple interactive dashboard.
A strong option for a second project: find a public dataset in a domain you actually care about (sports statistics, public health, housing markets, environmental data) and build an analysis that tells a story through visualizations. The personal interest matters because you'll be asked about it in interviews, and genuine enthusiasm is hard to fake.
Here's an example of the kind of Python work that belongs in a strong beginner portfolio:
import pandas as pd
import matplotlib.pyplot as plt
import matplotlib.ticker as mtick
from scipy import stats
# Analyzing US housing price trends by metro area (using FRED public data)
df = pd.read_csv('metro_housing_prices.csv', parse_dates=['date'])
# Calculate year-over-year percent change by metro
df = df.sort_values(['metro_name', 'date'])
df['yoy_change'] = df.groupby('metro_name')['median_price'].pct_change(periods=12)
# Identify the most volatile markets (highest std dev of YoY change)
volatility = (
df.groupby('metro_name')['yoy_change']
.agg(mean_growth='mean', volatility='std')
.dropna()
.sort_values('volatility', ascending=False)
)
top_volatile = volatility.head(8).index.tolist()
# Visualize the growth trajectories of the most volatile markets
fig, axes = plt.subplots(4, 2, figsize=(14, 16), sharex=True)
axes = axes.flatten()
for i, metro in enumerate(top_volatile):
metro_data = df[df['metro_name'] == metro].dropna(subset=['yoy_change'])
axes[i].fill_between(
metro_data['date'],
metro_data['yoy_change'],
0,
where=metro_data['yoy_change'] >= 0,
color='steelblue',
alpha=0.7,
label='Growth'
)
axes[i].fill_between(
metro_data['date'],
metro_data['yoy_change'],
0,
where=metro_data['yoy_change'] < 0,
color='tomato',
alpha=0.7,
label='Decline'
)
axes[i].yaxis.set_major_formatter(mtick.PercentFormatter(1.0))
axes[i].axhline(0, color='black', linewidth=0.8)
axes[i].set_title(metro, fontsize=11, fontweight='bold')
plt.suptitle('Year-Over-Year Housing Price Change: Most Volatile US Metros',
fontsize=14, fontweight='bold', y=1.01)
plt.tight_layout()
plt.savefig('housing_volatility.png', dpi=150, bbox_inches='tight')
plt.show()
Warning: Don't over-engineer your projects. The goal in Phase 2 is not to build production-grade systems. It's to demonstrate that you can take a question, find relevant data, apply appropriate tools, and communicate what you found. A clean, simple project with clear findings beats a complex, half-finished analysis every time.
Scope creep is the project killer. You start with "analyze sales data" and two weeks later you're trying to build a machine learning forecasting model that integrates with a live API. Projects balloon because uncertainty is uncomfortable and adding features feels like progress even when it isn't.
Use the two-week sprint structure to fight this. Each project gets exactly two weeks. At the start of Week 1, write down the one question the project will answer. Put that question at the top of every file. If a new idea doesn't directly answer that question, write it in a "future work" section in your README — and then don't touch it.
Nobody feels ready for their first interview. That feeling doesn't go away when you know more — it just becomes more familiar. The goal of Phase 3 is not to eliminate that feeling but to build the specific competencies that let you perform well despite it.
Phase 3 runs two parallel tracks: portfolio polish and active job searching. These are not sequential. They run simultaneously, and the tension between them is useful — feedback from real job applications will tell you what to polish.
Your portfolio should pass what I call the three-layer test. Each layer represents a different reader with a different amount of time.
Layer 1 (10 seconds): A recruiter glancing at your GitHub profile or LinkedIn should immediately understand: this person works with data, they complete things, and they can communicate clearly. Your profile README, pinned repositories, and clear project names do this work.
Layer 2 (3 minutes): A hiring manager reading one of your project READMEs should understand what business question you answered, what data you used, what you found, and what you would do next. This is where most beginner portfolios fail — they show code but not thinking.
Layer 3 (15 minutes): A technical interviewer reading your actual code should see clean structure, comments that explain why not just what, and evidence that you understood what you were doing. This is where you demonstrate craft.
Go back to your Phase 2 projects and audit them against all three layers. Fix what fails the test.
Data analyst and data science interviews typically have three technical components: SQL problems, Python or statistics questions, and case studies or take-home assignments. Let's be specific about what to prepare for each.
SQL interview questions at the analyst level almost always involve one or more of: multi-table JOINs with filtering conditions, aggregate functions with GROUP BY and HAVING, window functions (especially RANK, ROW_NUMBER, LAG/LEAD for time series), and finding duplicates or filling gaps in data. Practice on LeetCode (filter by SQL), HackerRank, and Stratascratch.
Here's the kind of SQL problem that appears frequently in analyst interviews:
-- Common interview problem: find users who were active in month 1
-- but not in month 2 (churn identification)
-- Table: user_activity (user_id, activity_date, event_type)
SELECT DISTINCT month1.user_id
FROM (
SELECT DISTINCT user_id
FROM user_activity
WHERE DATE_TRUNC('month', activity_date) = DATE '2023-01-01'
) month1
LEFT JOIN (
SELECT DISTINCT user_id
FROM user_activity
WHERE DATE_TRUNC('month', activity_date) = DATE '2023-02-01'
) month2 ON month1.user_id = month2.user_id
WHERE month2.user_id IS NULL;
Understanding this pattern — LEFT JOIN with a NULL filter to find records that exist in one set but not another — will cover a significant percentage of "set difference" interview questions.
Statistics questions at the analyst level focus on: explaining A/B testing and when it's appropriate, interpreting p-values and confidence intervals (with appropriate epistemic humility), understanding correlation vs. causation, and knowing when summary statistics are misleading. You don't need to derive formulas from scratch. You need to explain concepts clearly and know the common pitfalls.
Case study preparation is where most candidates underperform, and it's the most coachable skill. A typical data case study goes like this: "Our user retention rate dropped 15% last month. Walk me through how you'd investigate this." The interviewer isn't looking for the right answer — they're looking for structured thinking.
Practice the following framework for any case study question:
Practice this framework out loud, alone, with a timer running. It feels awkward. Do it anyway.
For a career-change or entry-level applicant, your resume has one job: get you to a phone screen. It should be one page, focused entirely on demonstrated skills and projects, and honest about your experience level.
The most effective format for a career changer is a functional-hybrid resume:
On application volume: you should be sending 10-20 applications per week by Day 75. This seems aggressive if you've never done a job search before, but at an early-career level, conversion rates from application to interview are low and that's normal. What matters is the quality of applications (tailored cover letter, keyword-matched resume) and the volume. You can't optimize your interview skills without interview reps.
You will get rejected. You will probably get rejected a lot before you get an offer. This is not evidence that your plan failed — it's part of how the job search process works, especially at the entry level.
The productive response to rejection is to treat every interaction as data. After every interview, write down: What questions did I struggle with? What felt solid? What would I study before the next interview? Build a running list. Pattern-match across rejections. The interview process is itself a signal about what you need to learn.
Practical rule: For every three rejections with no feedback, request one informational conversation with someone at a similar level who recently got hired. Ask what their interview process was like. You'll learn more from that conversation than from any interview prep book.
This exercise produces an artifact you'll actually use. Set aside two hours, open a document, and work through each section.
Section 1: Skills Audit (30 minutes) Complete the skills audit from the beginning of this lesson. Be ruthlessly honest. Rate yourself 1-5 in SQL, Python, spreadsheets, statistics, visualization, and business communication. Write specific evidence for any rating above a 2.
Section 2: Role Clarity (15 minutes) Write down the specific role you're targeting (data analyst, junior data engineer, business intelligence analyst, etc.) and three to five job postings that represent your target. Copy the technical requirements from each. Highlight the skills that appear in at least three of the five postings — those are your priority skills for Phases 1 and 2.
Section 3: Your Phase 1 Plan (30 minutes) Based on your skills audit and role clarity, write a week-by-week plan for Days 1-30. Be specific: not "learn SQL" but "complete SQLZoo SQL Zoo Tutorial through Section 7 by Day 7, then spend Days 8-14 practicing queries on the Chinook database." Assign 90-minute blocks to your calendar for each day.
Section 4: Your Two Projects (15 minutes) Write one sentence describing each of your two Phase 2 projects, following the format: "I will analyze [specific dataset] to answer [specific business question] using [specific tools]." If you can't write this sentence, you haven't scoped your project yet.
Section 5: Your Phase 3 Timeline (15 minutes) Write down: the date you'll start applying (it should be around Day 61), a weekly application volume target, how you'll track applications (a simple spreadsheet with company, role, date, status, and notes is sufficient), and the names of three people in your network (or network-adjacent) who work in data and could give you a mock interview.
Section 6: Your Circuit Breakers (15 minutes) These are the conditions under which you'll stop and reassess rather than pushing forward blindly. Example circuit breakers: "If I haven't completed both projects by Day 55, I'll drop the second project's scope rather than extend the timeline." "If I haven't gotten a phone screen by Day 75, I'll get three people to review my resume this week." Write yours down.
Mistake 1: Tutorial hell in Phase 1. The symptom is completing course after course without ever building anything independently. The fix is hard and simple: on Day 31, close all courses and open a blank file. The discomfort you feel is the learning.
Mistake 2: Building projects that are too small. A project that takes you two hours isn't a portfolio project — it's an exercise. Your projects should be messy enough to require problem-solving, large enough that you hit dead ends, and complex enough that you have real decisions to make. Aim for projects that take 15-20 hours each.
Mistake 3: Hiding imperfect work instead of publishing it. Many beginners wait to publish their GitHub projects until they're "ready." But readiness is a moving target. Publish your work at the end of each week, even if it's incomplete. Progress is visible to reviewers. Perfection that never ships is invisible.
Mistake 4: Underestimating the business communication layer. You can have excellent SQL skills and fail interviews because you can't explain what your analysis means in business terms. Practice translating every query result into a sentence that starts with "This suggests that the business should..." or "This tells us that customers who..."
Mistake 5: Treating the 30-60-90 plan as a fixed document. This plan should be a living document. Review it every Sunday. What did you complete? What's slipping? What did you learn about the job market this week that should change your priorities? Adjust the plan rather than abandoning it when things go sideways.
Troubleshooting: "I'm at Day 45 and my projects aren't done." Don't extend the timeline — reduce the scope. Ship what you have, document what's incomplete in a "Future Work" section, and move to Phase 3. An honest, complete small project is better than an ambitious, half-finished large project every single time.
Troubleshooting: "I'm getting interviews but not progressing past the technical screen." This means your portfolio is strong enough to attract interest but your in-the-moment technical performance needs work. Add two additional weeks of timed SQL practice (Stratascratch and DataLemur have good interview-style problems). Do at least three mock technical interviews — Pramp is free and matches you with other job seekers.
Three months is genuinely enough time to go from beginner to first interview — but only if you treat it as a structured professional development sprint, not a casual self-improvement project. The framework we've built here does three things that most beginner plans don't:
It sequences learning in a way that builds momentum rather than deferring all the interesting work to some imaginary "later." It forces you to build real things at a point when it's uncomfortable rather than when you feel fully prepared. And it integrates job search activity early enough that you're learning from the process, not just waiting to enter it.
The most important move you can make right now is to complete the hands-on exercise above and schedule your first 30 days of 90-minute sessions on your calendar before you close this page. The plan means nothing if it lives only in a document.
Immediate next steps:
Data careers are genuinely accessible to people who didn't study computer science or statistics in school. The skills are learnable. The roles exist. The gap between where you are and where you need to be is smaller than it feels right now. What you need isn't more time or a better course — you need a structured commitment and the willingness to build things before you feel ready.
Now close this article and go do the audit.
Landing Your First Data Role