Learn to code, from zero

This starts at what a variable is. No prior experience is assumed, and nothing is gated behind an account. The path runs to genuinely advanced material — SQL window functions, async JavaScript, Python classes, Java exception handling — because stopping at the basics is what leaves people unable to pass an interview.

126 lessons across Python, JavaScript, SQL, Java, Cloud, Git, Linux, Data Engineering, Cybersecurity, Machine Learning, Power BI, R, DSA, Digital Marketing and Business Analysis, each with a worked example, the mistake that most often trips beginners, and a short quiz. Then 386 practice exercises with hints revealed one at a time, and 25 auto-graded problems that run your code against real test cases in the browser.

The tracks beyond the four languages are not padding. We read 2,411 job postings for the skill-demand study and added the tools those postings actually named: AWS in 70% of DevOps and SRE roles, Terraform in 51%, Linux in 30%, Git in 23% of those and 11% of software engineering postings. Git's figure is the one to read carefully, because it counts only the postings that bothered to write the word down. Most do not: a team that would not hire someone unable to open a pull request stops thinking to ask for it. An assumed skill is still a required one.

The same measurement decided what is not here. Vedic maths, game development, robotics and graphic design are all taught well elsewhere; nothing in 2,411 postings for these roles asked for them, so adding them would grow the syllabus and teach you nothing an employer requested.

Why each lesson names a mistake

Beginners rarely fail because a concept was too hard. They fail on the same small traps: comparing strings with == in Java, using = NULL instead of IS NULL, an arrow function with braces that silently returns undefined, a mutable default argument in Python. Every lesson calls its trap out by name, because that is where the hours actually go.

What to build

Employers hire on demonstrated work far more than on course certificates. Two finished, deployed projects will do more for you than ten started ones, which is why the practice here ends in something that runs rather than a completion badge.

The full syllabus

Every lesson, in order, with the trap it teaches you to avoid. Levels run Basics → Working level → Advanced → Job-ready.

Python — 10 lessons, about 151 minutes

• ›Variables and types · Basics
  Assignment uses a single =, comparison uses ==. Mixing them is the single most common first-week bug.
  Common mistake: Adding a number to text: "Total: " + 5 raises TypeError. Convert first with str(5), or use an f-string.
• ›Lists and loops · Basics
  len(list) gives the count; indexes start at 0, so the last item is list[len(list)-1] or simply list[-1].
  Common mistake: Dividing by len(scores) when the list might be empty raises ZeroDivisionError. Check the list is non-empty first.
• ›Functions and reuse · Working level
  Default arguments (tax_rate=0.2) let one function serve several cases without duplication.
  Common mistake: Using a mutable default like def add(item, items=[]) — the list is created once and shared across every call, which produces baffling bugs. Use None and create it inside.
• ›Dictionaries and real data · Working level
  employee["missing"] raises KeyError; employee.get("missing", default) returns a fallback instead.
  Common mistake: Assuming a key exists because it usually does. Real data has gaps — use .get() with a default, or check with 'in' first.
• ›Making decisions with if · Basics
  Order matters — the first matching branch wins, so put the narrowest condition first.
  Common mistake: Mixing tabs and spaces for indentation. It can look identical on screen and still raise IndentationError — pick spaces and let your editor enforce it.
• ›Working with text · Basics
  .strip() removes surrounding whitespace; .split(sep) breaks text into a list.
  Common mistake: Expecting s.upper() to modify s. It returns a new string; you must assign it back with s = s.upper().
• ›Errors and files · Working level
  with open(...) closes the file automatically, even if an error is raised inside.
  Common mistake: Using `except:` on its own. It also catches your own NameError typos and hides the real problem behind a misleading message.
• ›Classes and objects · Advanced
  self is the instance; you declare it but never pass it when calling e.raise_by(10).
  Common mistake: Defining an attribute on the class body instead of inside __init__. A mutable class attribute is shared by every instance, so one object's change appears on all of them.
• ›Comprehensions and clean transforms · Advanced
  The filter goes at the end: [x for x in items if condition]. An if BEFORE the for is a conditional expression and means something different.
  Common mistake: Building a comprehension purely to avoid a loop, then nesting two of them. If you cannot say what it produces in one sentence, a plain loop is the better answer and every reviewer will agree
• ›pandas for real analysis · Job-ready
  df[mask] filters rows; df[["a", "b"]] selects columns. The doubled brackets trip up everyone once.
  Common mistake: Modifying a filtered slice and expecting the original to change. df[df.x > 1]["y"] = 0 raises SettingWithCopyWarning and often does nothing. Use .loc[mask, "y"] = 0 instead.

JavaScript — 10 lessons, about 162 minutes

• ›Variables and the browser · Basics
  const prevents reassignment, not mutation — you can still push to a const array.
  Common mistake: Using == instead of ===. Loose equality converts types, so "5" == 5 is true. Always use === unless you have a specific reason.
• ›Arrays: map, filter, reduce · Working level
  map always returns an array of the same length; filter returns the same or fewer.
  Common mistake: Using map when you meant forEach. If you are not using the returned array, map allocates one for nothing — say what you mean.
• ›Async: promises and await · Advanced
  await only works inside an async function; the function itself returns a promise.
  Common mistake: Awaiting in a loop when the calls are independent. Ten sequential 200ms calls take two seconds; Promise.all takes 200ms.
• ›Functions, scope and arrow syntax · Basics
  An arrow function with no braces returns its expression automatically.
  Common mistake: Adding braces to an arrow function and forgetting return: (x) => { x * 2 } returns undefined, not double x.
• ›Objects and destructuring · Working level
  ?. stops evaluation and yields undefined instead of throwing on a missing parent.
  Common mistake: Using || for defaults on numbers: count || 10 turns a real 0 into 10. Use ?? when zero or empty string are valid values.
• ›Changing the page (DOM) · Working level
  querySelector takes any CSS selector: #id, .class, tag.
  Common mistake: Running the script before the element exists. Put the script at the end of body or use defer, or querySelector returns null and you get 'Cannot read properties of null'.
• ›Coercion, ===, and the comparisons that lie · Working level
  Use === everywhere. == converts before comparing and produces 0 == '', '0' == false and a comparison that is not even transitive.
  Common mistake: Treating a form value as a number because it looks like one. Every input value is a string, so + concatenates instead of adding, and the result — '1500' from 15 and '00' — is plausible enoug
• ›fetch, JSON and handling failure properly · Advanced
  fetch rejects only on network failure. A 404 or 500 resolves normally, so check response.ok or you will parse an error page as data.
  Common mistake: Wrapping fetch in try/catch and assuming the catch handles server errors. It does not: a 500 resolves successfully, .json() parses the error page or throws a syntax error, and the failure su
• ›Closures, `this`, and the callback that loses itself · Advanced
  A closure captures variables, not values. var gives one binding for a whole loop so every function sees the final value; let gives a fresh binding per iteration.
  Common mistake: Passing an object's method directly as an event handler or to setTimeout. It is then called plainly rather than on the object, so `this` is not the object and the method fails on a property
• ›Modules, npm and shipping a real project · Job-ready
  Modules give each file its own scope and explicit imports, replacing load-order-dependent globals. Write ES modules; expect to read CommonJS.
  Common mistake: Leaving package-lock.json out of version control, or gitignoring it because it is large and noisy in diffs. Every machine then resolves its own versions from the same ranges, and the resulti

SQL — 8 lessons, about 140 minutes

• ›SELECT, WHERE and ORDER BY · Basics
  String comparison uses single quotes: 'Finance', not "Finance".
  Common mistake: Testing for missing values with = NULL. Nothing equals NULL, not even NULL. Use IS NULL / IS NOT NULL.
• ›GROUP BY and aggregation · Working level
  Every non-aggregated column in SELECT must appear in GROUP BY.
  Common mistake: Putting an aggregate in WHERE (WHERE COUNT(*) > 5). It fails, because WHERE runs before grouping — that condition belongs in HAVING.
• ›JOINs across tables · Advanced
  LEFT JOIN keeps customers with zero orders; INNER JOIN would hide them entirely.
  Common mistake: Filtering the right table in WHERE after a LEFT JOIN. WHERE o.status = 'paid' quietly converts it back into an INNER JOIN — put that condition in the ON clause instead.
• ›Subqueries and CTEs · Working level
  A scalar subquery returns one value and can sit anywhere a value is allowed.
  Common mistake: Using a subquery that returns several rows with = instead of IN. The database raises an error rather than guessing which row you meant.
• ›Window functions · Advanced
  PARTITION BY splits into groups; ORDER BY sets the order inside each one.
  Common mistake: Trying to filter on a window function in WHERE. It is computed after WHERE runs — wrap the query in a CTE and filter outside it.
• ›Changing data safely · Working level
  Always write the WHERE clause before you write SET — habit beats memory at 6pm.
  Common mistake: Running UPDATE without WHERE. It updates every row in the table, and without a transaction there is no undo.
• ›Dates, time series and cohorts · Advanced
  DATE_TRUNC('month', ts) groups by month correctly; strftime or substring on a timestamp usually breaks on timezones.
  Common mistake: Filtering with WHERE applied_on BETWEEN '2026-01-01' AND '2026-01-31' and losing everything that happened on the 31st after midnight, because the timestamp is compared against 00:00:00.
• ›Why queries are slow · Job-ready
  Wrapping a column in a function — DATE(col), UPPER(col), col::text — usually forces a full scan. Rewrite the condition to leave the column bare.
  Common mistake: Adding an index for every column that appears in a WHERE clause. Each index slows every write and consumes space; index what is actually queried often, then measure with EXPLAIN rather than

Java — 10 lessons, about 170 minutes

• ›Types, classes and main · Basics
  The file name must match the public class name exactly — Payroll.java for class Payroll.
  Common mistake: Comparing strings with ==, which compares references rather than contents. Use .equals() — this is the classic Java interview trap.
• ›Collections and loops · Working level
  Declare against the interface (List, Map) and instantiate the implementation (ArrayList, HashMap).
  Common mistake: Modifying a collection while looping over it, which throws ConcurrentModificationException. Collect what to remove, then remove it afterwards.
• ›Conditions, loops and methods · Basics
  A method signature declares its return type: String grade(int score).
  Common mistake: Forgetting that every path must return. If an if returns but the else path falls through with no return, the code will not compile.
• ›Objects, null and exceptions · Advanced
  private fields with public methods is encapsulation — the caller cannot corrupt internal state.
  Common mistake: Calling a method on a possibly-null reference. Check for null, or use Optional, rather than discovering it as a NullPointerException in production.
• ›Strings, immutability and the loop that melts · Working level
  Strings are immutable, so every method returns a new one. A call whose result you do not assign has done nothing.
  Common mistake: Using == on strings and having it pass every test. Test data is written as literals, which the compiler pools into the same object, so identity comparison succeeds. Real input is never poole
• ›equals, hashCode and the object that vanishes · Working level
  Override equals() and hashCode() together or not at all. Equal objects must have equal hash codes; the reverse is not required.
  Common mistake: Letting the IDE generate equals() and hashCode() over every field, including mutable ones. It compiles and passes a quick test, then an object is modified after being placed in a set, its ha
• ›Interfaces, and composition over inheritance · Advanced
  Depending on an interface rather than a class is what makes code testable: the same service takes a real implementation in production and a fake in a test.
  Common mistake: Extending a class to reuse a couple of its methods. You inherit its entire surface, its constructor requirements and its future changes, in a language where that is your only parent — and th
• ›Streams, lambdas and Optional · Advanced
  Streams are lazy: without a terminal operation such as collect, count or forEach, nothing executes and the pipeline is dead code.
  Common mistake: Calling .get() on an Optional because the value 'is always there'. That is the null pointer exception you were avoiding, now thrown as NoSuchElementException — and the compiler had offered y
• ›Files, resources and the leak you cannot see · Advanced
  try-with-resources closes every declared AutoCloseable in reverse order, on success or on exception, and keeps the original exception with close's attached as suppressed.
  Common mistake: Checking Files.exists(path) before reading and treating that as safety. The file can vanish between the check and the read, the check costs an extra system call, and you still need the excep
• ›Tests, builds and shipping something real · Job-ready
  A build file makes the project reproducible: one command, identical result on any machine. That is what ends 'it works on mine'.
  Common mistake: Writing tests only for the path you already know works, so the suite is green and proves nothing. It gives the strongest possible false signal — a passing build — for the code least likely t

Cloud — 8 lessons, about 125 minutes

• ›What the cloud actually is · Basics
  Every provider has the same four building blocks under different names. Learn the concepts once and the second provider takes a weekend.
  Common mistake: Assuming you need to learn all three providers. Postings almost always name one. Pick the one your target companies use — AWS in most of India and the US, Azure in enterprise and government
• ›Regions, availability and why it matters · Working level
  Region is chosen once and is painful to change later — data has to be migrated and some services cannot move at all.
  Common mistake: Defaulting to us-east-1 because every tutorial uses it. For an Indian product that is a permanent latency tax on every user and an avoidable compliance question.
• ›Infrastructure as code with Terraform · Advanced
  Always run plan before apply. It is a dry run, and reading it is the habit that separates careful engineers from expensive ones.
  Common mistake: Making a quick change in the web console and not putting it in the code. The next apply either reverts your fix or fails on a conflict, and the file no longer describes reality — which was t
• ›Design a small system out loud · Job-ready
  Ask for the constraint before you draw anything. "How many users, and what is the read/write split?" is the single highest-scoring sentence in a cloud interview.
  Common mistake: Jumping straight to a microservice diagram with a queue, a cache and six services for a problem that one server and a database would solve. Interviewers read over-engineering as inexperience
• ›The bill, and what runs it up · Basics
  Compute bills for existence, not usage. An idle instance costs full price, so scheduled shutdown on non-production is the largest easy saving available.
  Common mistake: Deleting a virtual machine and assuming the cost is gone. Its volume may persist, and its snapshots almost certainly do — they are billed independently, they do not appear in the instance li
• ›Identity, least privilege and the leaked key · Working level
  Identity is the perimeter. Most cloud breaches are a leaked credential or an over-broad role, not a clever exploit against infrastructure.
  Common mistake: Granting a wildcard permission to unblock a deployment, intending to narrow it later. Nothing fails afterwards to remind you, so the permission stays for years and is inherited by every serv
• ›Picking the right service for the job · Advanced
  Compute choice is a trade of control against operational burden. Serverless removes the most work and takes away the most tuning — right for spiky event work, wrong for long jobs and cold-st
  Common mistake: Choosing a distributed or serverless architecture for load a single managed database would carry comfortably. You inherit cold starts, distributed debugging and a far harder local developmen
• ›Monitoring, alerts and the 3am page · Job-ready
  Monitor what you promise users, not machine internals. CPU at 90% can be healthy; a 3% checkout failure rate is an incident while every host looks green.
  Common mistake: Adding an alert after every incident without ever removing one. The board fills with pages that no longer mean anything, on-call learns to acknowledge without reading, and the alert that mat

Git — 8 lessons, about 124 minutes

• ›Commits, and what they really are · Basics
  Three states: modified (edited), staged (chosen for the next commit), committed (saved). git status names which one every file is in.
  Common mistake: Running git add . without checking git status first, and committing a secret, a 200 MB CSV, or debug prints. Once a secret is in history, deleting the file does not remove it — the commit st
• ›Branches and pull requests · Working level
  Branch names that say what and why — fix/date-filter, add/csv-export — make a busy repository readable at a glance.
  Common mistake: Committing straight onto main because a branch feels like ceremony for a small change. It removes review, makes reverting risky, and on most teams it is the fastest way to be told you do not
• ›Undoing things without panic · Advanced
  revert is safe on shared branches because it adds a commit. reset rewrites history and should stay local.
  Common mistake: Reaching for git reset --hard to 'clean things up' with uncommitted changes present. Those changes were never committed, so reflog cannot bring them back — this is the one genuine way to los
• ›Work on a team without breaking main · Job-ready
  Keep the branch small. Review quality falls off a cliff somewhere around 200 changed lines, and an unreviewed merge is the thing branches exist to prevent.
  Common mistake: Working for two weeks on a branch without pulling main, then hitting forty conflicts and resolving them by taking your own side everywhere. You have just silently reverted two weeks of someb
• ›What must never go in a repository · Basics
  A secret committed once is compromised forever. Deleting the file does not help — the old commit still contains it. Rotate the key; that is the only real fix.
  Common mistake: Believing that because a repository is private, a committed secret is safe. Private repos get made public, forked, and shared with contractors, and history is copied on every clone. Treat a
• ›Merge, rebase, and reading a conflict · Working level
  Merge keeps true parallel history and is always safe. Rebase makes history linear but rewrites commits, so never rebase anything someone else has pulled.
  Common mistake: Resolving a conflict by accepting one whole side because the markers are annoying. In a config or a shared function that quietly deletes the other person's work, the tests still pass, and it
• ›Finding the commit that broke it · Advanced
  git log -S finds the commit where a string appeared or disappeared. It is the fastest way to answer 'when did this constant change'.
  Common mistake: Reading the diff of a large merge commit to find a regression. A merge commit shows the combined result, not the change that caused it. Bisect finds the individual commit, and git show on th
• ›Reviewing someone else's pull request · Job-ready
  Read the tests first. They state what the author thinks the change does, and a missing test for the main claim is the highest-value comment you can leave.
  Common mistake: Approving a large pull request quickly because the author is senior or the change is urgent. Your approval is a claim that you checked. If you have not, say so — 'I read the API changes but

Linux — 8 lessons, about 125 minutes

• ›Moving around the filesystem · Basics
  tail -f is how you watch a service misbehave in real time. It is probably the single most-used command in an incident.
  Common mistake: Using cat on a large log and flooding the terminal for thirty seconds. Use less to page, or tail to see the recent end — which is the part that matters during an incident anyway.
• ›Pipes, grep and doing real work · Working level
  sort | uniq -c is the counting idiom. uniq only collapses ADJACENT duplicates, so the sort is required, not optional.
  Common mistake: Piping straight into uniq -c without sorting first, then reporting numbers that are quietly wrong because only adjacent duplicates were collapsed. The command succeeds, which is what makes i
• ›Permissions, processes and a stuck server · Advanced
  Permission denied on a script almost always means a missing execute bit, not a broken script.
  Common mistake: Fixing a permission problem with chmod 777. It makes the file writable by every user on the machine, is flagged immediately in any review or audit, and hides the real question of which user
• ›Debug a live incident from the shell · Job-ready
  Check before you restart. A restart clears the state that would have told you the cause, and buys twenty minutes at the price of the next incident.
  Common mistake: Restarting the service immediately because it usually works. It usually does work, which is why the underlying leak or the full disk survives for months and pages someone every fortnight unt
• ›Paths, globs and the commands that bite · Basics
  The shell expands globs before the command runs, so quoting and spaces matter more than they look. ls with the same glob shows you exactly what will be affected.
  Common mistake: Running rm -rf with a variable that could be empty or a glob you have not checked. Substituting ls for rm first costs one second and shows you the exact list, and it is the difference betwee
• ›find, xargs and doing one thing to many files · Working level
  Quote the -name pattern. Unquoted, the shell expands it against the current directory and find receives something you did not type.
  Common mistake: Piping find straight into xargs without -print0 and having it work on your test data. Every name in your test happens to have no spaces; the first real filename with one becomes two argument
• ›The disk is full and the box is slow · Advanced
  Deleting a file held open by a process frees nothing until the process closes it. lsof +L1 finds these, and : > file truncates in place without a restart.
  Common mistake: Deleting a large log file, seeing df unchanged, and concluding the deletion failed — then deleting more. The application still holds the file open. Check lsof +L1 first, and truncate rather
• ›A script that can run unattended · Job-ready
  set -euo pipefail at the top of every unattended script. Without pipefail a failing command piped into a successful one reports success and the job looks fine.
  Common mistake: Testing a cron script in your own shell, where PATH, environment variables and the working directory are all set, then scheduling it and assuming it works. Run it once with env -i to see it

Data Engineering — 8 lessons, about 135 minutes

• ›What a data pipeline actually is · Basics
  ELT (load raw, transform in the warehouse) is the modern default. ETL still exists in older estates and in places where data cannot legally land unprocessed.
  Common mistake: Transforming data on the way in and keeping nothing else. The moment the business changes how it defines 'active customer', you need the raw rows to rebuild history — and if you dropped them
• ›Batch, streaming and where Kafka fits · Working level
  Kafka decouples producer speed from consumer speed. That buffering is the reason it is used, more than the throughput numbers people quote.
  Common mistake: Reaching for streaming because it sounds more advanced. A nightly batch that is correct beats a stream that double-counts, and interviewers hear 'we made it real-time' as a cost question — w
• ›Orchestration, idempotency and backfills · Advanced
  A DAG encodes dependencies, not just order. The orchestrator can then retry one failed task rather than rerunning the whole chain.
  Common mistake: Writing tasks that append. The first retry after a partial failure double-counts a day, and nobody notices until a monthly total is wrong — by which point the bad rows are mixed in with good
• ›Design a pipeline end to end · Job-ready
  Land the raw copy before transforming. It is cheap storage and it means a bug in your SQL is an inconvenience rather than a data loss.
  Common mistake: Designing only the happy path and treating monitoring as something to add later. The interviewer's follow-up is always "what happens if the source is empty that morning?", and "the job would
• ›Where data comes from, and what dirty means · Basics
  Profile before you transform: row count, distinct key count, nulls per column, min and max of every date. Ten minutes, and it replaces assumptions with facts.
  Common mistake: Assuming a column named id is unique because it is called id. Source systems retry, backfill and merge; duplicates are normal. Count distinct against total before you join on it, or every do
• ›Modelling for analytics: grain, facts and dimensions · Working level
  Write the grain as a sentence before creating the table. 'One row per order line' is the fact that makes every later join checkable.
  Common mistake: Joining an order-header table to an order-line table and then summing the header total. Each header repeats once per line, so revenue multiplies by the average line count — and the number lo
• ›Testing data, and contracts with the people upstream · Advanced
  Volume tests catch the silent zero-row load, which succeeds without error and leaves every dashboard downstream looking plausible and stale.
  Common mistake: Testing the transformation and not the source. Your SQL is correct and your pipeline is green while the upstream team has renamed a column and every row now has a null where the join key use
• ›The query that scanned four terabytes · Job-ready
  Partition pruning only happens when the filter is on the partition column and unwrapped. CAST or any function around it forces a full scan.
  Common mistake: Rerunning an exploratory SELECT * over full history all afternoon in a notebook. Nothing errors, each run feels free, and the bill arrives a month later with no way to attribute it. Filter t

Cybersecurity — 8 lessons, about 133 minutes

• ›What a SOC analyst actually does · Basics
  Tier-one SOC is a genuine entry point into security — one of very few that hires without prior security experience.
  Common mistake: Closing an alert without writing down the reasoning. The next analyst sees the same pattern in three weeks and starts from nothing, and if it turns out to have been real, there is no record
• ›Reading logs and triaging an alert · Working level
  Baseline before you judge. "Ten failed logins" means nothing until you know whether this account normally has zero or forty.
  Common mistake: Investigating the single alerting event in isolation. Attacks are sequences, and the alert usually fires on step three of six; looking only at that step means missing both how they got in an
• ›Detection engineering and alert fatigue · Advanced
  A detection that fires constantly and is rarely right makes the organisation less safe, because analysts stop reading the queue carefully.
  Common mistake: Measuring a detection by how much it catches rather than by its precision. A rule with perfect recall and 2% precision will be muted within a month, and a muted rule catches nothing at all.
• ›Write the incident report · Job-ready
  Lead with the one-sentence summary. Most readers stop there, and it is the sentence that gets quoted upwards.
  Common mistake: Writing the timeline as a wall of raw log lines and letting the reader work it out. The report exists to save the reader that work — if they have to reconstruct the story themselves, the ana
• ›The attacks you will actually see · Basics
  Most incidents start with a person, not an exploit. Phishing and reused passwords beat firewalls, so MFA and a fast blameless reporting path do more than another appliance.
  Common mistake: Treating a reported phishing click as a training failure for the person who clicked. They will not report the next one, you lose your fastest detection signal, and the dwell time on the next
• ›Identity is the perimeter now · Working level
  Passkeys and hardware keys are phishing-resistant because the credential is bound to the real domain. SMS and app codes can be relayed by a convincing proxy page in real time.
  Common mistake: Rolling out MFA and treating identity as solved while legacy authentication endpoints remain enabled for compatibility. Attackers enumerate exactly those, and the organisation believes it is
• ›Vulnerabilities, and why 'critical' is not a plan · Advanced
  CVSS measures worst-case severity, not your exposure. Reachability, data sensitivity and active exploitation reorder a scan report far more usefully than the score.
  Common mistake: Working a scanner's list strictly in descending severity order. You spend the quarter on unreachable internal criticals while a medium-rated flaw on the public login page is being actively e
• ›A confirmed breach: the first hour · Job-ready
  Contain before you investigate. Isolate at the network layer rather than powering off, so the attacker stops while volatile evidence survives.
  Common mistake: Rebooting or reimaging the affected machine to 'clean it' before capturing memory. Everything the attacker held only in RAM is destroyed, you lose the ability to determine what was taken, an

Machine Learning — 8 lessons, about 137 minutes

• ›What a model actually learns · Basics
  Split before you explore, not after. Looking at the test set to decide which features to use leaks its information into your choices, and the score stops being honest.
  Common mistake: Reporting accuracy on imbalanced data. Fraud, churn and disease detection are all rare-event problems where accuracy is dominated by the common class — and a model with a superb accuracy sco
• ›Overfitting, and the metric that matters · Working level
  The train-minus-test gap is the overfitting measurement. Quote both numbers, never just the good one.
  Common mistake: Tuning the model against the test set. Every time you check the test score and change something, you leak a little of it into your decisions — after twenty rounds the test set has quietly be
• ›Getting a model into production · Advanced
  Bundle preprocessing with the model. A pipeline saved as one object cannot drift apart from its own transformations.
  Common mistake: Shipping a model with no retraining plan. It is accurate on launch day and decays from then on, and because nothing ever throws an error the decay is usually discovered by a business owner n
• ›Ship a model and know when it breaks · Job-ready
  Serialise the preprocessing with the model as one artifact. Separating them is how training-serving skew gets in, and it degrades quality without raising an error.
  Common mistake: Deploying the model and considering the work finished. Six months later the business says the predictions feel wrong, nothing has errored, no alert has fired, and there is no logged history
• ›How the data is split, and why your 99% is fake · Basics
  Use three sets. The validation set is spent by tuning, so only a test set you have looked at once gives an honest estimate of new-data performance.
  Common mistake: Celebrating an unexpectedly high score instead of investigating it. On a genuinely hard problem, a jump to 99% is nearly always leakage — a column that encodes the answer, or preprocessing f
• ›Features, and the one that gives away the answer · Working level
  Derived features usually beat model choice. Hour-of-day from a timestamp, ratios instead of raw counts, and rolling windows are where most of the gain comes from.
  Common mistake: Building features from a warehouse table that has been updated since the event. The row you train on shows the final state — refunded, cancelled, upgraded — while at prediction time only the
• ›Thresholds, imbalance and the cost of being wrong · Advanced
  0.5 is a default, not a decision. Derive the threshold from the cost of each error type and it frequently lands nowhere near the middle.
  Common mistake: Reporting accuracy on an imbalanced problem and declaring success. The number is high because the majority class dominates, the model may never predict the minority class at all, and the met
• ›Explaining a model to whoever is accountable for it · Job-ready
  Translate metrics into consequences: alerts per day, share that are genuine, cost of each error type. That is the language in which the decision is actually made.
  Common mistake: Presenting AUC to a business owner. It answers a question they did not ask, invites 'is that good?', and leaves them unable to weigh the trade-off they are accountable for. Give them alerts

Power BI — 8 lessons, about 134 minutes

• ›The data model is the whole job · Basics
  Star schema — one fact table of events, dimension tables describing them. It is the shape Power BI is designed around.
  Common mistake: Importing one giant flat table because it looks simpler. It works for the first two visuals and then blocks every slicer, every time comparison and every measure that needs to filter one tab
• ›DAX: measures, columns and context · Working level
  Measures over calculated columns. A measure adapts to every filter context; a column is frozen at refresh time and inflates the file.
  Common mistake: Writing calculated columns for everything because they feel like Excel formulas. They are computed once and cannot respond to a slicer, so you end up with a dozen near-identical columns, a b
• ›Making a slow report fast, and keeping rows private · Advanced
  Measure before you optimise. Performance Analyzer names the visual and the millisecond cost, so you fix the one query taking four seconds instead of rebuilding the nine that were already fas
  Common mistake: Importing full detail when the report only shows aggregates. Forty million rows to render a monthly trend makes refresh slow, the file enormous and every interaction sluggish — and the fix b
• ›Deliver a report people actually use · Job-ready
  Write the decision the report supports in one sentence before building. If you cannot, the requirement is not finished, however clear the data model is.
  Common mistake: Building every chart the data supports and letting users find what they need. Fourteen slicers and no default view reads as a data dump, and the honest response to a data dump is to export i
• ›Power Query: cleaning before it reaches the model · Basics
  Set column types explicitly at import. Type inference samples the first rows, so a stray 'N/A' deep in the file breaks the refresh and not the preview.
  Common mistake: Cleaning in DAX what should have been cleaned in Power Query. DAX runs at query time on every visual interaction, so the same repair is recomputed constantly instead of once on refresh — and
• ›The star schema, and the flat-table trap · Working level
  One fact table of numbers, several dimension tables of descriptions, joined one-to-many in a single direction. The engine and DAX both assume this shape.
  Common mistake: Turning on a bidirectional relationship to make one slicer behave. It works, and then a total elsewhere in the report becomes wrong through a filter path nobody traced. If you need one, writ
• ›Time intelligence: YTD, prior year and the date table · Advanced
  Time intelligence replaces the date filter and re-evaluates, so a date table with gaps or one that ends too early produces wrong numbers rather than errors.
  Common mistake: Using the date column on the fact table instead of the date table in time intelligence functions. It appears to work, and then any date with no transactions is simply absent from the calcula
• ›Publishing, refresh and sharing without leaking · Job-ready
  Refresh fails silently and the report keeps showing stale data. Enable failure notifications, because nothing in the report itself indicates the data is old.
  Common mistake: Assuming row-level security works because it was configured. A role that was never assigned, or a filter expression that matches every row, produces a report identical to an unsecured one. C

R — 8 lessons, about 135 minutes

• ›Vectors, data frames and why R feels different · Basics
  R is vectorised by default. If you are writing a for loop over a column, there is almost always a one-line expression that does it faster and reads better.
  Common mistake: Writing R as though it were Python — looping over rows with an index and appending to a growing vector. It is slower, longer, and marks the code as written by someone who has not learned the
• ›dplyr and the tidyverse pipeline · Working level
  Six verbs cover most analysis: filter (rows), select (columns), mutate (new columns), group_by, summarise, arrange.
  Common mistake: Forgetting to ungroup after a group_by. The grouping persists into later steps, so a subsequent mutate silently computes per group instead of across the whole frame — the numbers look plausi
• ›Statistical testing without fooling yourself · Advanced
  Report the confidence interval and effect size, not the p-value alone. Significant and meaningful are different claims.
  Common mistake: Reporting statistical significance without the size of the effect. On a large sample almost any difference becomes significant, so a result presented as 'significant at p < 0.05' with no int
• ›Make an analysis somebody else can rerun · Job-ready
  Use a project and relative paths. An absolute path to your Desktop is the most common reason an analysis will not run for anyone else.
  Common mistake: Cleaning the data by hand in Excel before loading it into R. The result is unreproducible and, worse, unreviewable — nobody can see which rows you dropped, including you in three months.
• ›Getting real data in, and the types that go wrong · Basics
  Read the column specification read_csv prints. A numeric column parsed as character is telling you something non-numeric is hiding in it.
  Common mistake: Letting the reader guess types on a file that changes monthly. It infers numeric in January and character in February because one row gained an 'N/A', and every downstream calculation change
• ›Reshaping, joining and grouped summaries · Working level
  Check the row count before and after every join. An inner join dropping unmatched rows is silent, and it is the most common cause of a total that shrinks between steps.
  Common mistake: Joining on a key you have not checked for duplicates. Ten thousand rows become forty thousand, every sum multiplies, and because the shape of the result is still a sensible-looking table the
• ›ggplot2: plots that answer a question · Advanced
  Inside aes() maps a variable to a visual property; outside aes() sets a fixed value. colour = 'blue' inside aes() creates a variable named blue and draws a legend for it.
  Common mistake: Presenting a scatter plot of fifty thousand overlapping points as evidence of no relationship. The points are drawn on top of one another, so the shape is invisible — alpha, jitter or a 2-D
• ›Functions, vectorisation and the loop that took an hour · Job-ready
  Growing a vector or data frame inside a loop reallocates and copies on every iteration. Pre-allocate, or vectorise and remove the loop entirely.
  Common mistake: Optimising the part of the script you assume is slow. Profiling regularly shows the time going into a repeated file read or a type coercion inside a loop, while the algorithm everyone worrie

DSA — 8 lessons, about 136 minutes

• ›Big O, and why interviewers ask · Basics
  A loop inside a loop over the same data is the O(n²) signature, and it is the most common performance bug in working code.
  Common mistake: Optimising the wrong thing. Rewriting a function that runs once on ten items while leaving an O(n²) loop over a million rows untouched is the classic misjudgement, and it is why interviewers
• ›The four structures that dominate screens · Working level
  Arrays, hash maps, strings and stacks cover most screening questions. Be fluent in those before touching trees and graphs.
  Common mistake: Grinding problem counts instead of patterns. Fifty problems solved by looking up the answer teaches recognition without recall, and it collapses the moment the wording changes — ten problems
• ›Solving a problem out loud · Advanced
  Restate the problem first. A misunderstanding caught in minute one costs nothing; the same one caught in minute fifteen costs the interview.
  Common mistake: Going quiet while thinking. The interviewer cannot distinguish deep concentration from being completely lost, and after ninety seconds of silence they usually assume the second — narrate the
• ›The live coding interview · Job-ready
  State the brute force and its complexity before writing anything. It banks a correct answer and frames the optimisation as deliberate.
  Common mistake: Going quiet and writing the optimal solution from memory. If it works you get partial credit for an answer they cannot tell you understood; if it does not, there is no partial credit at all
• ›Arrays and strings: two pointers and the sliding window · Basics
  Two pointers works when the input is sorted or you can work inward from both ends. Each move eliminates a whole set of candidates rather than testing one.
  Common mistake: Reaching for two pointers on unsorted input because the problem mentions pairs. The technique depends on the ordering to know which pointer to move; without it, moving either one discards ca
• ›The hash map, and turning O(n²) into O(n) · Working level
  The core trade is memory for time: store what you have seen so a second scan becomes a single constant-time lookup.
  Common mistake: Mutating an object after using it as a key. Its hash was computed on insertion, so the map now looks in the wrong bucket: the entry is still there, `in` reports false, and iterating the map
• ›Recursion, trees and traversal · Advanced
  Every recursion needs a base case and a recursive case that provably shrinks the input. For trees the base case is the empty node.
  Common mistake: Claiming a tree traversal is O(log n) space because trees are 'logarithmic'. That holds only when the tree is balanced. An unbalanced tree built from sorted insertions is a linked list, the
• ›Sorting, binary search, and using the order you have · Job-ready
  Sorting costs n log n once and makes membership, ranges, medians and duplicates cheap afterwards. For a single lookup it is wasted; for many it is the solution.
  Common mistake: Writing a binary search where a branch sets lo = mid rather than mid + 1. On a two-element range mid equals lo, nothing shrinks, and the loop runs forever — and it passes every small test wh

Digital Marketing — 8 lessons, about 135 minutes

• ›The funnel, and the numbers that describe it · Basics
  CTR, conversion rate, CAC and ROAS describe nearly any campaign. Be able to compute them from raw numbers without a calculator.
  Common mistake: Reporting impressions and reach as achievements. They cost nothing to inflate and correlate weakly with revenue, and an interviewer reading a CV full of reach numbers with no conversion figu
• ›SEO that survives an algorithm update · Working level
  Technical, then on-page, then off-page. Crawlability problems make everything downstream irrelevant.
  Common mistake: Chasing keyword volume without checking intent. Ranking a product page for a question query produces traffic that bounces immediately, and a high bounce with no engagement teaches the search
• ›Attribution, and why the numbers disagree · Advanced
  Every platform claims conversions it touched, so platform-reported totals overlap and exceed reality. Reconcile against your own order data.
  Common mistake: Adding up conversions reported by each ad platform and presenting the total. The same sale is counted by two or three platforms at once, so the number exceeds actual orders — and being caugh
• ›Report a channel to the person paying for it · Job-ready
  Convert every metric into money before it reaches the report. CAC against customer value is a decision; CTR is trivia to a budget holder.
  Common mistake: Reporting traffic, impressions and engagement with no conversion or cost figure attached. It optimises for what is easy to measure, and the reader — who is deciding about money — learns noth
• ›Who you are actually selling to · Basics
  Segment by shared problem, not demographics. Two buyers of the same age and city can be in completely different situations, and situation is what drives the purchase.
  Common mistake: Writing positioning from an internal workshop and going straight to paid spend. The message is in the company's vocabulary rather than the buyer's, the click-through looks acceptable, and th
• ›Running paid without lighting money on fire · Working level
  Search captures existing demand and social creates it. That difference sets the intent you can expect and how much work the creative has to do.
  Common mistake: Optimising a campaign toward clicks because the number moves quickly and looks healthy. The platform delivers exactly that — cheap clicks from people who will never buy — and the campaign re
• ›Email and lifecycle: the channel you own · Advanced
  Behaviour-triggered sequences beat calendar broadcasts because they arrive when the message is relevant, and they keep running once built.
  Common mistake: Increasing send frequency because the last campaign performed well. Complaints and unsubscribes rise faster than revenue, mailbox providers respond by filtering, and the damage lands on ever
• ›Landing pages and testing without fooling yourself · Job-ready
  Doubling conversion halves the cost per acquisition of every channel at once, without extra spend. It is usually cheaper than buying more traffic.
  Common mistake: Calling a test after three days because the variant is ahead. Early results swing wildly on small samples, the lead usually evaporates, and rolling it out means every later decision is built

Business Analysis — 8 lessons, about 135 minutes

• ›Requirements are decisions, not documents · Basics
  A stated request is usually a solution. The requirement is the decision underneath it, and asking why three times gets you there.
  Common mistake: Writing down what the stakeholder asked for and passing it on. That is transcription, and it is why 'the BA just wrote what we said' is a common complaint from both sides — the developers ge
• ›Process mapping and finding the real problem · Working level
  Map what actually happens, not what the documentation says. The undocumented spreadsheet is usually where the problem is.
  Common mistake: Designing the future state before mapping the current one. The new process is built on how people say the work is done, and it fails on the exceptions and workarounds that were never mention
• ›Making the case with numbers · Advanced
  Quantify the benefit or the recommendation competes on opinion, and loses to whichever proposal has a number attached.
  Common mistake: Presenting a single precise savings figure with no assumptions shown. It invites the reviewer to test the number rather than the idea, and when reality lands anywhere else, every subsequent
• ›Run the requirements workshop · Job-ready
  Bring a current-state map, not a blank page. People correct a picture accurately and describe a process badly.
  Common mistake: Running the workshop, feeling it went well because everyone agreed, and writing it up three days later from memory. Half the agreement was people using the same words to mean different thing
• ›Stakeholders: who decides, who blocks, who is loud · Basics
  Map power against interest. The high-power, low-interest approver who is contacted first in week ten is the classic cause of a late derailment.
  Common mistake: Treating the most vocal participant as the decision maker. Requirements get built around their preferences, the actual approver sees the result late and disagrees, and the rework is blamed o
• ›Stories and acceptance criteria a developer can build from · Working level
  The 'so that' clause names the outcome and permits a better solution than the one requested. Dropping it turns a conversation into an order.
  Common mistake: Writing acceptance criteria that only describe the happy path. The feature is built, demonstrated successfully, and fails in its first week on an empty dataset or a permission case nobody sp
• ›Asking the database the right question · Advanced
  Establish what one row represents before writing the query. Counting rows in an order-lines table answers a question about lines, not orders.
  Common mistake: Reporting a number without checking it against anything. A duplicated join key or a missing status filter produces a total that is confidently wrong, and it is discovered by someone else in
• ›UAT, sign-off and the change that arrives late · Job-ready
  UAT must be executed by the people who do the work, against realistic data and whole processes. A demonstration by the project team tests nothing.
  Common mistake: Accepting a small late change without recording what it displaces. Several small changes absorbed quietly consume the contingency, the date slips with no single decision anyone can point to,

Common questions

Next: the developer path · engineer interview questions · English for work