Aptive Challenge
Aptive's application process includes a gauntlet of an API-driven coding challenge โ nineteen problems total, fetched one at a time from a live API, each unlocking the next. I built a CLI application in TypeScript that talks to that API directly: fetches each challenge, solves it, submits the answer, and moves on to the next one automatically until the whole gauntlet is cleared.
How it works
The app creates a session against the Aptive Challenge API, either with a static or randomized email address, and then loops over the full suite of core and bonus challenges. It doesn't hardcode a challenge order โ it follows the links included in each API response to fetch the next challenge's details, submit an answer, process the result, and eventually verify completion of the whole gauntlet. A small routing layer maps each incoming challenge_id to the handler that knows how to solve it, and every handler receives both the links it needs to submit its result and the (semi-randomized) mock data the API hands back for that particular run.
The challenges
Nineteen challenges across nine levels, roughly increasing in difficulty:
Core (levels 1โ5): start, Base64 decode, hex checksum, primes sum, palindrome product, roman numeral conversion, Fibonacci, string transform, webhook signature verification, pagination, matrix spiral traversal, deduplication, rate limiting, and consistent hashing.
Bonus (levels 6โ9), the distributed-systems half: circuit breaker, leaky bucket, quorum consensus, two-phase commit, and Raft leader election. These are the ones I found genuinely interesting to implement โ they're not algorithm-puzzle problems so much as small, correct simulations of the actual coordination patterns that show up in real distributed backends.
Design
I wanted adding support for a new challenge to be closer to "drop in a file" than "trace through a monolith." Each challenge gets its own handler file under src/handlers, named to match its challenge_id, and a central handler map in src/handlers/index.ts routes incoming challenge ids to the right function. If the API exposes new challenges in the future, the pattern is: add a handler file, register it in the map, done โ nothing else in the app needs to know it exists.
Runtime behavior is configurable through a few constants in src/index.ts: which email address (or a randomized one) to register the session under, whether to skip bonus challenges after finishing core, whether to verify the session once enough challenges are done, and whether to write progress out to a local progress.html after each submission so a run can be watched as it goes.
Stack
TypeScript, run directly with npm run start โ no build step, no external services beyond the Aptive Challenge API itself. Built to be run once, start to finish, sprinting through all nineteen challenges in a single session.
Conclusion
What made this fun wasn't any single challenge โ it was building something durable enough to survive an API that hands you challenges dynamically, in whatever order it decides, with only a link and a payload to go on each time. The distributed-systems bonus tier in particular was a good excuse to actually implement Raft election and two-phase commit instead of just reading about them.
As always, thank you for reading. I really appreciate it. ๐