Software Engineer

We run an internal data platform behind a talent representation intelligence product that maps out the entertianment industry.
 

We are rebuilding the platform (legacy Symfony/Angular → Django + React) because the current system stores its most valuable data as unstructured text and can't support where the product is going. . This is not a greenfield toy and not a rescue job — it's a planned rebuild with an unusual amount of groundwork already done:

• A product & architecture document with the domain model decided: what each module means, what dies, what changes, and the conventions (append-only history, structured-at-entry, derived-values-never-facts, and more)
• An epic breakdown with dependency order and explicit definitions of done
• A decisions register — every product ruling logged, searchable, current
• Approved feature specs for the major new modules (representation history, deals/endorsements restructure, awards, drafts)
• A migration standard: raw-row archives, legacy-ID mapping, conflict review queues, rehearsed cutover — nothing silently dropped, nothing silently merged
   

Your job is to design and build within that system: propose schemas and migration plans per module (we call these build contracts — you propose, product approves, then you build), stand up the foundation (auth, field-level permissions, API-first architecture), build the cross-cutting primitives (audit log, unified sources, soft delete, lookups), and run a phased legacy migration where reconciliation counts get reviewed, not just produced.
 

How we work — read this part twice:

• The documents are the spec; the legacy code is not. Many current features are unused and several database tables are mislabeled (we've mapped this). When you hit a question about what something should do, you ask — you don't resolve it from old code. We answer questions daily, in writing, fast.
• Gates are real. Every epic starts with your proposed schema + migration plan; implementation starts after approval. Epics close when their definition-of-done closes — including a researcher completing the workflow without your help — not when the tasks are checked off.
• AI tooling is welcome and expected. We assume you'll use agents/copilots — we do. What we hire for is what the tools can't do: judgment. You verify what your tools produce against the real schema and the real data before it reaches us. "The agent said so" is not a source. (Our favorite recent bug: a generated diagram claiming a name column was an integer. The person who catches that is who we're hiring.)
• Evidence over memory. Unknowns get investigated — code usage, row counts, what breaks — and then ruled on. We don't guess.
  
  You're a fit if:
• Senior Django + React, with real ownership of at least one system end-to-end (schema through UI through deployment)
• You've done at least one legacy migration or system replacement and can talk concretely about what went wrong and what you'd do differently
• You read before you build — genuinely. Our last mismatch was a capable developer who never opened the app or the documents; the interview is designed to detect this, so if it's not you, save us both the call
• You're comfortable proposing designs to a non-engineer product owner who is deeply involved, defending them in writing, and being overruled on product grounds without sulking
• Strong written English; async-first habits; you leave a paper trail by default
• Bonus, not required: search infrastructure (Typesense/similar), data-pipeline/ETL work, having worked alongside scraper/ingestion systems, PostgreSQL depth