Ship projects that make recruiters stop scrolling.

Build an event-driven service that scales and recovers

The synchronous version melts under spikes and loses work when something downstream fails. You re-architect it around a queue with the patterns that make async systems trustworthy.

Start building

Build a multi-region platform with real disaster recovery

After an outage took the business offline for hours, leadership wants a credible answer to "what happens if a whole region fails?". You design and build the multi-region story, and then prove it by failing over for real.

Start building

Frontend Developer

ReactTypeScriptAccessibility (ARIA)Debouncing

Build an accessible search + filter UI that handles every state

The "simple" search box on a product page is where most frontend interviews are actually won or lost. You build one properly, fast, keyboard-driven, accessible, and graceful when things go wrong.

Ships: A deployed demo with all states (loading/empty/error/results) reachable

ReactData fetching & cachingCore Web VitalsCode splitting

Build a real-data dashboard that meets a performance budget

A dashboard works on the developer’s laptop but crawls on a mid-range phone. You build one that stays fast under real data and a real network, and you prove it with numbers.

Ships: A deployed dashboard meeting its stated performance budget

React / Next.jsAuth flowsState managementForm validation

Ship a production frontend app with auth, state, and tests

You’re handed "build the frontend" for a real product. You deliver something a team could actually maintain: authenticated, well-tested, observable, and shipped through CI.

Ships: A deployed app with auth, validated forms, and a passing CI pipeline

~30h 6

Backend Engineer

API designInput validationPaginationAuth

Design and build a well-documented API

Most "build an API" submissions work but would never pass code review. You build one that would: validated, paginated, authenticated, documented, and tested.

Ships: A running API with a published OpenAPI/GraphQL schema and interactive docs

Data modelingMigrationsQuery optimization (N+1)Caching (Redis)

Build a service with a real database, caching, and limits

A service that’s correct but slow (or falls over under load) is a real on-call problem. You build one that holds up: a sensible schema, no N+1s, caching, rate limiting, and idempotent writes.

Ships: A service repo with migrations and a load/perf note

~17h 5

Event-driven architectureMessage queuesOutbox patternIdempotent consumers

Build an event-driven service that scales and recovers

The synchronous version melts under spikes and loses work when something downstream fails. You re-architect it around a queue with the patterns that make async systems trustworthy.

Ships: A service repo demonstrating the outbox + DLQ patterns

~29h 5

Cloud Engineer

S3 / object storageCDN & cachingDNSTLS certificates

Ship a global static site, defined entirely in code

A team keeps hand-uploading a marketing site to a server and it keeps breaking. You replace it with a CDN-backed static site that deploys from a Git push and is reproducible from Terraform, no console clicking.

Ships: A Terraform repo that stands up the whole site with one command

VPC designAuto ScalingLoad balancingRDS

Stand up a resilient 3-tier app across availability zones

A startup needs their web app off a single hand-configured EC2 box before launch. You own the infrastructure: it must survive an AZ outage, scale under load, keep the database private, and be reproducible from code.

Ships: A Terraform repo that stands up the full environment

Multi-region architectureTerraform modulesGlobal DNS failoverData replication

Build a multi-region platform with real disaster recovery

Ships: A module-based Terraform repo deploying two regions

~28h 5

DevOps Engineer

DockerMulti-stage buildsCI pipelinesAutomated testing

Containerize an app and put it behind CI

A team ships by running scripts on their laptops, and "works on my machine" is a daily phrase. You give them a reproducible image and a pipeline that proves every change before it merges.

Ships: A repo with a Dockerfile and a working CI pipeline

CI/CDDockerKubernetesHelm

Build a GitOps CI/CD pipeline to Kubernetes

A team deploys by SSH-ing into servers and running scripts, and nobody is sure what is actually running where. You replace that with a pipeline where a merge to main automatically builds, tests, and deploys to Kubernetes, and the cluster always matches Git.

Ships: A repo with a CI pipeline and a Helm chart with per-environment values

~18h 5

Progressive deliveryArgo Rollouts / canaryHelmObservability (metrics/logs/traces)

Build a self-service platform slice with progressive delivery

Developers wait on the ops team for every deploy and every new service, and ops is the bottleneck for the whole org. You build the beginnings of an internal platform: developers ship safely on their own, with canary rollouts and observability built in.

Ships: A golden-path service template that emits CI, a Helm chart, dashboards, and default policies

~31h 6

Site Reliability Engineer (SRE)

Metrics instrumentationGolden signalsPrometheusGrafana dashboards

Instrument a service with the four golden signals

A service is "up" but nobody can actually see how it is doing until users complain. You make its health visible, latency, traffic, errors, and saturation, on one screen a tired on-call can read in seconds.

Ships: An instrumented service exposing the four golden signals

SLI/SLO designError budgetsBurn-rate alertingIncident response

Define SLOs, alert on them, and run a game day

Alerts are either silent or screaming, and nobody can say how reliable the service should be. You define what reliable means, alert only on real user pain, and prove the team can respond by running a controlled incident.

Ships: An SLO document with SLI definitions, targets, and an error-budget policy

Multi-service SLOsBurn-rate alertingLoad & capacity testingChaos engineering

Stand up a reliability program across services

Reliability is one person's heroics, not a system. You build the program: SLOs across multiple services, capacity you have actually tested, a chaos experiment, and on-call that does not burn people out.

Ships: A reliability dashboard and SLO catalog spanning multiple services

~28h 6

Full Stack Developer

Frontend + backend integrationREST/RPCDatabaseAuth

Ship a full-stack app end-to-end

The classic "can you actually build and deploy a whole thing?" test. You take an idea from empty repo to a deployed, authenticated app with a real database, UI, API, persistence, and auth, all wired together and live on a URL a stranger can use.

Ships: A deployed app with auth and a live URL

~7h 4

WebSockets/SSEOptimistic UIConflict resolutionPresence

Build a real-time collaborative feature

Real-time is where full-stack gets genuinely hard, and genuinely impressive. You build a collaborative feature (shared editing, a live board, or presence-rich updates) that stays consistent when several people touch it at once, survives a dropped connection, and feels instant.

Ships: A deployed real-time collaborative feature

~17h 6

Multi-tenancyRBACBilling integrationCI/CD

Build a production SaaS slice (multi-tenant + billing)

You build the part of a SaaS that separates hobby projects from real products: multiple tenants isolated from each other, roles and permissions, a billing flow with plan limits, and the CI/CD plus observability glue to actually operate it. This is the realistic core of a B2B product.

Ships: A deployed multi-tenant app with RBAC and test-mode billing

~34h 8

DevSecOps Engineer

SASTDependency scanningSecret detectionContainer image scanning

Add a security gate to a CI pipeline

A team ships fast and finds vulnerabilities in production. You shift that left: every change is scanned before it can merge, and criticals block the build.

Ships: A CI config with security gates (SAST, SCA, secret + image scanning)

SBOMArtifact signing (cosign)Provenance/attestationAdmission policy

Secure the software supply chain

After a high-profile supply-chain attack, leadership asks "can we prove what’s in our builds and that they’re ours?". You make the answer yes: every artifact ships with a bill of materials, a verifiable signature, and build provenance, and the cluster refuses to run anything that can’t prove its origin.

Ships: A pipeline emitting a signed image, SBOM, and provenance attestation

~16h 5

Threat modelingIaC scanningSecrets management (Vault)Runtime/admission policy

Build a secure-by-default pipeline and threat-model an app

You own security for a service end-to-end: you threat-model it, build defenses into the pipeline and runtime, manage its secrets properly, wire up detection and alerting, then prove it all works by attacking it yourself in a controlled purple-team exercise.

Ships: A threat model (data-flow diagram + ranked threats) and a matching control map

~31h 6

AI Engineer

Structured output / function callingJSON schema validationPrompt designRetry & fallback logic

Build a reliable structured-extraction service

A team is copy-pasting invoices and emails into spreadsheets by hand. You build a service that turns messy free text into clean, validated JSON an LLM can be trusted to produce, every time, or fail loudly.

Ships: A documented extraction API with a schema

RAG architectureEmbeddings & vector searchPrompt designPII detection

Build and evaluate a RAG assistant over real docs

A support team is drowning in repetitive questions answered in a 400-page docs site. You build an assistant that answers from those docs accurately, cites sources, refuses to hallucinate, and is measurably good.

Ships: A running RAG service with a documented API

~17h 6

Agent architectureTool/function callingGuardrails & safetyObservability & tracing

Ship a production agentic assistant with guardrails

The RAG bot worked, so now the business wants it to *act*, look things up, call internal tools, and complete multi-step tasks. You build that agent responsibly: observable, bounded, evaluated, and safe to put in front of users.

Ships: A deployed agent service with traced runs

~33h 7

Agentic AI Masterclass

Agent loop (ReAct)Tool callingInput validationStop conditions

Build a single-tool agent with real guardrails

Everyone can call an LLM; few can make it act safely. You build a focused agent that uses one real tool, reasons about when to use it, and can’t run away.

Ships: A working agent with traced runs

~7h 4

Multi-tool orchestrationAgent memoryEval harnessCost tracking

Build a multi-tool agent with memory and evaluation

A one-shot agent isn’t enough, the task needs several tools, memory across steps, and a way to know if it’s actually any good. You build that, and you measure it.

Ships: A multi-tool agent with short- and long-term memory

~17h 5

Multi-agent orchestrationPlanner/worker patternsHuman-in-the-loopGuardrails & governance

Build a governed multi-agent system

The frontier of the field: multiple specialized agents collaborating on a real workflow, safely enough to deploy and auditable enough to trust.

Ships: A deployed multi-agent system with traced, audited runs

~33h 6

System Design

API & data modelingCapacity estimationCachingRead/write scaling

Design a URL shortener with real capacity math

The interview classic, done at the depth interviewers actually want. You design a URL shortener and back every choice with numbers, not hand-waving.

Ships: A design doc with diagrams and capacity math

Distributed systemsSharding/partitioningConsistency modelsCaching strategy

Design a scalable system end-to-end with ADRs

You’re asked to design something with real scale and real failure modes, a feed, chat, or notification system, and to document the decisions like a senior engineer would.

Ships: A design doc with scaling, consistency, caching, and failure analysis

~14h 5

Large-scale architectureCapacity planningLoad testingBottleneck analysis

Design a high-scale system and load-test the bottleneck

Design alone is theory. You design a high-scale system (ride-sharing, streaming, or payments-style) and then prove your central assumption by building and load-testing the critical path.

Ships: A full design doc with capacity planning, a cost model, and failure analysis

~28h 6

Data Structures & Algorithms

Hash mapsLRU cacheTriesComplexity analysis

Implement core data structures from scratch, with tests

You don’t really understand a data structure until you’ve built it and broken it. You implement the three that show up in almost every codebase, a hash map, an LRU cache, and a trie, with a real test suite and honest complexity analysis, not a copy from the standard library.

Ships: A tested repo with a hash map, LRU cache, and trie built from scratch

TriesInverted indexRankingBenchmarking

Build an autocomplete / mini search engine

Turn algorithms into a product feature. You build a fast autocomplete over a real dataset, think a city list, a product catalog, or a wordbank of hundreds of thousands of entries, that ranks suggestions well and stays under a strict latency budget as the data grows.

Ships: A working autocomplete engine over a real dataset with a CLI or web demo

ProfilingGraph & advanced algorithmsComplexity reasoningBenchmarking

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.

Ships: A repo with the original slow solution and the optimized one, side by side

~28h 6

Cloud-Native Engineering: Kubernetes & Istio

Kubernetes Deployments/ServicesProbesConfigMaps/SecretsResource requests & limits

Deploy a microservice to Kubernetes the right way

Anyone can `kubectl apply` a YAML and call it done. You deploy a service the way it should actually run in production: health-checked so the platform can heal it, configured cleanly so the image is environment-agnostic, resource-bounded so it can’t starve its neighbours, and able to scale automatically under load.

Ships: A manifest repo (Deployment, Service, ConfigMap, Secret, HPA) for the service

IstioTraffic managementmTLSRetries & timeouts

Add a service mesh: traffic, mTLS, and observability

Two services talk over the network and you have no control or visibility, you can’t shift traffic for a release, can’t prove the connection is encrypted, and can’t see where latency comes from. You add Istio, and suddenly you can route, secure, and observe everything between them without touching the application code.

Ships: A meshed app with a working, weight-controlled canary release

~17h 5