Projects

The real builds. Two 48-hour take-home rehearsals, one portfolio artifact, and one written technical opinion.

These are the artifacts you can point at in any round — and the take-homes are the only place Track E's skill can actually be measured.

Table of Contents

The Four Builds

#ProjectWhenPurpose
1webhook-delivery/Week 8, real 48h clockThe reported take-home, rehearsed
2<second-take-home>/Week 16, real 48h clockGeneralization — the skill, not the answers
3<portfolio>/Weeks 10–20, backgroundThe deep artifact you reference in every round
4technical-opinion.mdWeeks 6–12, iterativeThe "where is AI headed" answer, written

Project 1: Webhook Delivery System

projects/webhook-delivery/ — the reported take-home example (../research/source-report.md rows 10–12), independently corroborated by at least one vendor source describing a webhook delivery system as a work-trial project.

Run it under a real 48-hour wall clock, following the playbook. Not 48 hours of work — 48 hours of elapsed time, including sleep. The clock is the point; a system you built over two relaxed weeks measures nothing.

The brief, deliberately under-specified

Build a service that delivers webhooks to customer endpoints. Customers register a URL and subscribe to event types. When an event occurs, we deliver it. Customer endpoints are unreliable — they time out, return 500s, and occasionally go away entirely. We must not lose events, and we must not hammer a struggling endpoint into the ground.

Build something real. We care about how you handle the parts we did not specify.

The under-specification is the test. Row-by-row, the ambiguities you must decide and document rather than silently resolve:

AmbiguityYour decision goes in the README
Ordering — per destination? per event type? none?Ordering costs concurrency. Which did you buy?
How long do you retry before giving up?And what happens to the event then?
Is delivery at-least-once or at-most-once?Say it explicitly, and say what the consumer must do
What does "do not lose events" mean at a crash boundary?Where is your durability point?
Does a slow endpoint get isolated from a fast one?Per-destination concurrency, or one shared pool?
What does the customer see?Delivery status API? Replay? Both?

Required components

ComponentNon-negotiable detail
Retry with backoff and jitterFull vs equal vs decorrelated — pick one, benchmark the difference, and say why
Idempotency keysPer event, stable across retries, so the consumer can dedupe
Dead-letter queueWith a documented redrive path and poison-message detection
At-least-once deliveryPlus a consumer-side dedupe story you can explain
Per-destination isolationOptional ordering; concurrency caps; circuit breaker per destination
ObservabilityStructured logs, per-destination metrics, a health endpoint
Load testOne measured number, with the methodology written down
Decision logdecisions.md, appended as you go

Why the decision log is the highest-leverage file

The deep dive walks your code line by line, from a question list the interviewer writes after reading it (rows 13–15). So every choice becomes a question three weeks later. At the deep dive you will be asked "why 200ms?" and "why six attempts?" — and ninety seconds spent logging that at hour 12 buys you a complete answer, while its absence buys you a reconstruction that the interviewer will correctly hear as one.

After you ship

  1. Freeze the repo. No commits after the 48 hours.
  2. I read the actual diff and generate the project-specific interrogation list.
  3. Live drill: 45 minutes, no notes, recorded, scored on the hire-bar scale.
  4. Everything you could not defend goes into ../review/.

Project 2: The Second Take-Home

Week 16, different domain, same discipline. Row 15's real requirement is generalization — if you only ever defend the webhook system, you have memorized answers rather than built the skill.

Candidate briefs, chosen when you get there so it is genuinely cold:

BriefWhat it stresses differently
Distributed rate-limiting serviceShared state, atomicity, fail-open vs fail-closed
Log ingestion + query serviceWrite throughput, indexing, retention
Feature store with point-in-time correctnessYour domain, but the training/serving skew problem is genuinely hard
Multi-tenant job runner with fair schedulingIsolation, fairness, resource accounting

Pick one you have not built before. The point is the 48 hours, not the familiarity.

Project 3: The Portfolio Artifact

One deep, public-quality project in your strongest area — search/retrieval or inference serving. Built in the background across weeks 10–20, not against a clock.

Requirements:

  • A real benchmark with honest measured numbers, including the ones that are worse than you hoped
  • A written design doc with the tradeoffs
  • A README someone can actually run
  • One thing in it that is genuinely non-obvious

Suggested shape, given your background — an ANN index serving benchmark that measures the recall/latency/memory frontier across index types on a fixed corpus, with a written analysis of where each wins. It sits exactly on the seam between your search experience and the inference serving that Track D covers, and it produces numbers you measured yourself.

Why "numbers you measured" matters so much: the difference between "vLLM gets 3–5x" (a thing a blog said) and "I measured 2.8x at batch 32 with a 512-token prompt, and here is why it is lower than the published figure" is the difference between a candidate who reads and a candidate who builds. The second survives follow-up; the first does not.

Project 4: The Written Technical Opinion

technical-opinion.md — a short essay (800–1,500 words) taking a defensible position on a hard problem in the domain. It is what turns the recruiter-screen question from a platitude into a conversation.

Required structure:

  1. A specific, falsifiable claim. Not a trend list.
  2. The evidence — something you measured, built, or can cite with a number.
  3. The strongest counter-argument, stated fairly.
  4. Your falsifier — what would change your mind.
  5. What follows — what you would build if you believe this.

A candidate thesis you should test rather than adopt, and it draws on your actual work:

The binding constraint on useful AI over the next two years is inference cost and latency under agentic workloads, not model capability. One user action now becomes tens of model calls, decode is memory-bandwidth-bound so cost falls slower than capability rises, and the traffic shape that results breaks the autoscaling signals everyone built for request-response chat.

If you end up disagreeing with it after doing the work, write the disagreement — that is a better essay and a better interview answer.

Rules for Every Project

  • The clock is real. A 48-hour project done over two weeks measures nothing.
  • Decision log from hour zero. Ninety seconds per entry, and it is the difference between defending and reconstructing.
  • Tests as you go, never at the end. Tests-at-the-end is how you ship untested code at hour 47.
  • Commit history tells the story. It is graded, and it is the cheapest signal to get right.
  • One benchmark, honestly reported — including when the number is disappointing.
  • "Beyond the ask" is narrow. One of: a measured benchmark, a failure-injection test that proves a recovery path, or an operational concern nobody asked for. Not more features — extra features read as poor judgement, not as enthusiasm.
  • Freeze at the deadline. The interrogation runs against what you shipped.

References