Back to path
LargePortfolio centerpiece ~28h· 6 milestones

Rescue a slow workload with the right algorithm

The real-world version of DSA: a workload is too slow in production, and the fix is a better algorithm or data structure, not more servers. You take a genuinely slow program (a graph traversal, a large-collection scan, or a quadratic pairwise computation), find the algorithmic bottleneck, redesign it to a better complexity class, and prove the win with hard before/after numbers.

ProfilingGraph & advanced algorithmsComplexity reasoningBenchmarkingTrade-off analysisAlgorithm selectionAdversarial / chaos testingRunbooks & blameless postmortems
Build this freeBrowse all projectsNo credit card. Already a member?

What you'll build

A profiled, redesigned solution to a real slow workload with a benchmark showing a major, order-of-magnitude before/after improvement, a clear complexity argument explaining WHY the new approach wins, and an honest account of the trade-offs (memory, readability, preprocessing cost) you accepted.

See how we teach, before you sign up

You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:

slow/dupes.pypy
def find_duplicate_pairs(items):
    """Return sorted list of (i, j) index pairs where items[i] == items[j]."""
    pairs = []
    n = len(items)
    for i in range(n):                 # O(n)
        for j in range(i + 1, n):      # O(n) -> O(n^2) overall
            if items[i] == items[j]:
                pairs.append((i, j))
    return sorted(pairs)

Reading this file

  • for i in range(n):The outer loop, paired with the inner one it compares every item against every later item.
  • for j in range(i + 1, n):The nested inner loop is what makes this O(n squared), the bottleneck you will redesign away.
  • if items[i] == items[j]:The pairwise equality check, cheap individually but run n squared times, that is the real cost.
  • return sorted(pairs)Returns a sorted result, the redesign must match this ordering exactly to pass the differential test.

The original O(n²) version, keep it intact as the correctness oracle.

That's 1 of 9 explained code blocks in this single project.

The build, milestone by milestone

  1. 1

    Reproduce the slowness and find the real cost

    5 guided steps

    Engineers waste enormous effort optimizing code that isn’t the bottleneck. A profiler tells you where the time actually goes, which is almost never where intuition points.

  2. 2

    Choose an approach that changes the complexity class

    5 guided steps

    Micro-optimizations shave constants; the real wins come from changing the complexity class, O(n²) → O(n log n), or repeated O(V·E) → preprocessed O(1) lookups. Choosing well, and being able to argue why, is the senior skill.

  3. 3

    Implement the redesign and prove it’s correct

    5 guided steps

    A faster wrong answer is worthless. Before you celebrate the speedup, you must prove the redesign is behaviorally identical, fast and correct, in that order of trust.

  4. 4

    Benchmark, then defend the win

    5 guided steps

    The deliverable that makes this portfolio-worthy is the proof: a benchmark showing an order-of-magnitude win, an empirical complexity curve, and an honest account of what you gave up to get it.

  5. 5

    Break it on purpose: stress the redesign with adversarial inputs

    5 guided steps

    Average-case wins lie. A hash-based rescue collapses under adversarial collisions; a preprocessed index blows memory on a pathological graph. Production traffic eventually finds these, so you find them first, this is the chaos test for an algorithm.

  6. 6

    Write the runbook and a blameless postmortem of the original

    5 guided steps

    The rescue is only durable if the next engineer knows its limits and the team learns why the slow version existed at all. A runbook keeps it safe; a blameless postmortem keeps the same mistake from recurring.

What's inside when you start

3 starter files, ready to clone
6 guided milestones
6 full reference solutions
9 code blocks explained line-by-line
6 "is it working?" checks
4 interview questions it prepares you for

You'll walk away with

A repo with the original slow solution and the optimized one, side by side
A benchmark report with before/after numbers across multiple input sizes (and ideally a runtime-vs-n chart)
A write-up of the complexity-class change and the trade-offs (memory, preprocessing, readability) you accepted
A chaos-experiment report: adversarial inputs, documented breaking points, and the safe operating envelope
A runbook + blameless postmortem covering safe operation, fallback to the original, and the prevention gate that catches the next regression

This is portfolio-grade. Build it free.

Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.

Start building