Anubhav Jain

The eager generation matched no real requirement, it was just how the legacy system worked. Report open-rate data showed parents almost never opened a report the moment it was delivered. The redesign replaced eager generation with a unique link per recipient and generated the report on open instead of on send, removing the database load for documents nobody was about to read yet. It's rolling out now, and daily queue-latency alerts have already dropped as a result.

The obvious approach is swapping API keys. At that volume it's also the wrong one: a new sending IP has no reputation with mail providers, and a cold IP taking full volume on day one gets treated as spam. A router ramped traffic onto the new provider up to a computed daily maximum, with everything above that falling back to the old one, so delivery never depended on the new IP earning trust faster than it could.

I led getting the wrongly purged customers back live: writing scripts that pulled the deleted rows out of the pre-purge backup and reinserted them, restoring the accounts with no lasting data loss. The fix that followed replaced manual validation entirely: decommissioning is now a single script that resolves every parent-child relationship itself, including the ones the original process missed, so nothing outside it needs a human to check first.

Before it, hiring ran on an off-the-shelf recruiting CRM alongside spreadsheets for tracking candidates. It was built as a v2 while the existing system kept running, so the ops team could move across when it was ready. Once they did, recurring operational work came off engineering.

Content nested as modules, sub-modules, lessons, and quizzes, with each quiz holding a handful of questions. A question could be video, image, text, or a combination of them, which meant the client had to render every shape and the API had to stay generic enough to describe them all instead of special-casing each one. Instructors named their files against a convention agreed up front, and the ingestion script used that convention to resolve each asset onto the right place in the structure.

Requirements varied by state and by license type, and they kept changing, so the platform had to absorb updates rather than be rewritten around them. Most of them fitted one underlying model. The remaining fifth were ambiguous enough in interpretation that the rules engine had to grow new capability before it could express them at all, and that minority is where most of the work went. It also integrated with partner systems to pull and reconcile compliance data across sources.