Data Science Guide: Statistics, Python, SQL and a Portfolio

Descriptive statistics is the everyday language of data work. The mean marks the centre, the median marks the middle value and shrugs off outliers, and the standard deviation shows how widely values spread. With salaries or house prices, a handful of extreme values drags the mean upward, so the median often tells the fairer story. Comparing the two is already training an analyst's way of thinking.

Next come probability, the normal distribution and simple hypothesis tests. The question is always some version of this: is the gap I see large enough to trust, or could a small sample have produced it by chance? Correlation belongs here too, along with its limit, since two columns that move together may have no causal link at all.

On the maths side, basic linear algebra such as vectors and matrices, plus the idea of slope behind gradient descent, is enough to get going. A useful drill is to solve a problem by hand, recompute it in pandas and compare the two answers. Tie each concept to data you already know, such as the spread of exam scores in one class or your own monthly spending. The roadmap in this guide sets aside six to eight weeks for this foundation, and the self-study guide runs it alongside Python.

Most company data lives in relational databases, and SQL is how you get it out. Five core commands carry most daily analysis: SELECT picks columns, WHERE filters rows, ORDER BY sorts, GROUP BY groups and JOIN combines tables. Add COUNT, SUM, AVG, MIN and MAX for summarising a column, plus LIMIT, BETWEEN, IN and LIKE for everyday needs, and you have most of what a feature table for a model requires.

What trips up beginners most is execution order. You write a query starting with SELECT, while the database processes it starting with FROM, then WHERE, GROUP BY, HAVING, SELECT, ORDER BY and finally LIMIT. That order explains why a column alias created in SELECT is unknown inside WHERE, and why a condition like COUNT(*) > 10 belongs in HAVING. WHERE filters raw rows before grouping; HAVING filters the grouped results afterwards.

JOIN carries its own traps. An INNER JOIN returns the rows that find a partner on both sides, whereas a LEFT JOIN carries the whole left table along, unmatched rows included. In SQLite and MySQL, a JOIN without an ON condition becomes a cross join that multiplies rows, so make a habit of checking the row count after every join. Wrap mixed AND and OR conditions in brackets as well. SQLite is the lightest place to start, with PostgreSQL or MySQL as the next step. At roughly an hour a day, the basics usually settle within three to four weeks.

Your first machine learning is supervised learning with two basic cases. Regression estimates a number, such as a house price from floor area and location. Classification sorts items into categories, such as positive or negative reviews. The introductory algorithms are linear regression, logistic regression, decision trees and random forests. scikit-learn offers all of them through one consistent pattern, fit to train and predict to predict, which leaves your attention free for how each model works.

The most important habit at this stage is splitting data into training and test sets from the start with train_test_split. A model is judged on data it has never seen, because a model scored on its own training data nearly always looks brilliant. The second habit is comparing every model with a baseline, the simplest possible guess, such as predicting the mean for regression or the most common class for classification. A model that loses to or ties with the baseline has found nothing useful yet.

Master one algorithm until you understand why it produces a given result, then move to the next. If you understand linear regression you can explain what each coefficient means; if you understand a decision tree you can show the question it asks at every branch. Small classic datasets suit this stage because common sense can check the output. The roadmap allows about eight to ten weeks here.

An end-to-end project strings every stage into one flow: frame a question, fetch data with SQL or from files, clean and explore it, train a few models if the question calls for prediction, evaluate them and write the conclusion. The question comes first and the dataset second. Asking which factors most affect flight delays, or what seasonal pattern shows up in commodity prices, gives the project a clear direction that anyone opening it can follow.

Data can come from open government portals, national statistics offices, Kaggle, the UCI repository or public APIs. Check the licence, note the source and year, and make sure no sensitive personal data ends up in the upload. A slightly messy dataset gives you room to show your cleaning skills, whereas a dataset everyone has already used makes your project hard to tell apart from thousands of others.

Descriptive questions are fully answered by sharp analysis and good charts; machine learning comes in when the question genuinely calls for prediction or grouping. Write the conclusion in three to five sentences for a non-technical reader, covering the main finding, the limits of the data and what deserves a closer look next. A complete project usually takes two to five weeks alongside ongoing study.

Data science learners tend to stall in familiar ways. The most common is the tutorial loop: following dozens of videos without ever finishing a project of your own. The second is jumping to deep learning before statistics and core machine learning are solid, so models run and nobody can explain their output. The third is hopping between courses until none of them is finished. The fourth is putting SQL off because it looks simple, even though data hiring processes test it almost every time.

A weekly rhythm is the way out. The from-scratch roadmap works on eight to ten hours a week, and many self-taught learners use ten to fifteen. Pick one core skill per week, study at the same time each day even if only for thirty minutes, complete at least one coding exercise on real data, and keep the weekend for project work. Write down one thing you newly understand and one thing that still confuses you.

A monthly review needs only two questions: which skills grew and which projects got finished. If one topic stays stuck for too long, going back over the basics of the previous stage usually helps more than pushing forward. Feedback from someone more experienced, through a data community or a tutor, speeds up fixes for problems that are hard to see alone, such as data leaking between the training and test sets.