Junior TypeScript developer

We're a two-person team building Déjà: a platform that issues cryptographically signed receipts proving which code change caused which production incident. Our customers will be compliance and audit teams at regulated financial firms, so the product's entire value is that its output can be trusted by someone who doesn't trust us. We're looking for a junior developer to work alongside our lead engineer on well-specified implementation work. The stack TypeScript monorepo, tRPC, Drizzle, Postgres on Supabase. Next.js front end. A separate Go CLI for offline verification — you don't need Go, but you'll read it. What the work actually looks like Two kinds, and both are real work. Enumeration. You find every instance of something across the codebase and report what you found — by call site, with file and line, never by example. Our lead engineer then reads it and says what it means. Recent enumerations here turned up defects on every single pass, and they are the highest-value work this team does. Examples: every place a database table is read, every field that enters a signing function versus every field a verifier reads back, every piece of deferred work sitting in a code comment. The acceptance criterion is not the list. It's how you know the list is complete. "I searched for these six terms across both repos and here is what each returned" is an answer. "I found seven" is not. Implementation. Work that has already been scoped down to something specific. Examples of exactly the kind of task you'd get: Seven call sites read a database table that is always empty and silently receive zero rows. The call sites are already enumerated with file and line. Add a fallback to each and a test proving it fires. Two audit events are emitted without an organisation ID. The fix is described in the code comment next to each one. Implement it, and add the test that would have caught the omission. A regression test suite needs extending to cover two more receipt types, matching an existing test that already covers a third. You will not be asked to design the cryptography, the scoring model, or the canonical form, or to judge which of your findings matters most — that's the part our lead engineer does, and it's built on knowing why the code is the way it is. You will be asked to search exhaustively, implement carefully, test properly, and say clearly what you observed and what you didn't check. How we work, and the one thing that matters most We have a house rule: described is not observed. Nothing is reported as working because it looks right or because a test passed. It's reported as working because you ran it and can show the row, the log line, or the command output. This week alone, four things in this codebase "passed" while being broken: a test that passed because a field it didn't know about was missing, a badge that reported a live connection against a revoked record, a verifier that silently downgraded a format it didn't understand, and an export that carried five of nineteen required fields. If you tell us something works, we will ask how you know. That should feel normal, not adversarial. Being wrong is fine and happens constantly here — our lead engineer retracted three of his own conclusions this week, which is why we trust the fourth. What we're not looking for Someone who reports completion without evidence. Someone who fixes a symptom without saying whether they found the cause. Someone who won't say "I don't know" — or worse, someone whose enumeration looks complete because they stopped looking rather than because they found everything. Practical Part-time to start, 15–20 hours/week, ongoing if it works Overlap with UTC+3 needed for at least a few hours daily You'll get a written runbook covering the architecture, environments, and known landmines before you touch anything Screening question (put this in the post, it's the whole filter) Tell us about a time you fixed something, believed it was fixed, and later found out it wasn't. What made you check again, and what did you find? One paragraph. We're more interested in this than your CV. Anyone who answers with a real story has the instinct. Anyone who answers with a process description doesn't.