The posting
Nummo builds software for recruiting teams that run many searches at once. A recruiter’s day is a chain of small decisions: a new job opens, a candidate is added, a screen is passed, a client wants to meet, a time is agreed, an invite goes out, a result comes back, an offer is signed, and the search is closed. Each of those moments already lives somewhere else, in an applicant tracking system, a notes tool, a calendar, a spreadsheet, or a chat. Nummo’s job is to keep one search coherent across those tools, so the recruiter can say what happened and have the rest of the record move with her.
The backend is where that coherence is enforced. The desktop app is the place a recruiter talks to a search. The API, the database, and the workers behind it are what turn a sentence into a durable change: a candidacy, a milestone, a task, a calendar event, a stage move, a row on a tracking page. Those writes have to land in the right order, on the right search, for the right candidate, and they have to be safe to retry when a provider is slow or a worker restarts. This role owns that path.
You will design and ship the services that open a search from an external job, attach candidates, and advance them through the stages a firm actually uses. You will work on the agent runtime that reads a recruiter’s message, plans the writes for that turn, and delivers them. You will work on the workflow engine that opens the next task when a milestone is recorded, and that leaves a task alone when the step is already satisfied. You will work on the integrations that talk to applicant tracking systems, calendars, documents, and notes tools, including the polling and webhook paths that notice a new job without anyone creating it by hand.
A normal week mixes product work with operational care. One day you are adding a step to a recruiting workflow and proving that a chat message books the interview, moves the candidate, and records the milestone. The next day you are tracing a run that looked stuck because a write was delivered immediately and the interface had nothing left to approve. You will read production evidence when something fails, fix the narrow cause, and add the check that would have caught it. You will also delete the old path. We do not keep a second implementation around once the new one is the one callers use.
The system is a TypeScript monorepo. The API serves the desktop app and the workers. Postgres holds organizations, searches, candidacies, tasks, actions, and the links back to external objects. Temporal runs the agent loop and the scheduled jobs, including the poll that looks for newly published jobs. The desktop app is Electron. The interesting backend problems are not in rendering. They are in identity, ordering, and partial failure. A candidate can exist as a person, as a candidacy on one search, and as an applicant on an external job, and those three records have to stay tied together. A milestone recorded today can open a task on the day of the interview rather than the day it was typed. A chat write and a task run can both try to update the same description, and the newer one has to win. An invite can be sent at the moment it is created, so a missing approval card is not the same thing as a failure.
You should have built and operated backend systems that other people depend on. You are comfortable with relational data, with transactions, and with the ways a unique index or a soft delete changes what “already exists” means. You have shipped integrations against third-party APIs, including their rate limits, their draft-versus-published states, and their habit of returning success for a write that is not yet visible. You can read a stack from an HTTP request through a workflow history and say which step is still running. You write TypeScript that other people can change next month. You prefer a small function with a precise name over a comment that explains a muddy one.
You do not need to have worked in recruiting. You do need to care what the recruiter sees. A stage slug, a guest list, and a task title are product behavior, not internal details. When a message says a client wants to meet a named candidate, the system should record that, tell her what to send the candidate, and wait for the confirmed time. When she gives the time and the client’s email, the system should book a 30-minute online meeting for the client and the candidate, move the applicant, and close the booking tasks. When she says the candidate signed, the search should fill and the closing work should open. If you have opinions about how those steps should feel, we want them, grounded in how the current path actually behaves.
We work in the open inside the company. Changes land through pull requests with a clear description of the behavior, the risk, and what was verified. A change to authentication, authorization, schema, billing, or a send path gets a closer look than a change to copy. We verify recruiting behavior with the real app and, where the change is a prompt, with repeated model runs, not only with a unit test that asserts its own mocks. Production access for diagnosis is read-only. We do not fix a live search by writing around the product.
The team is small. You will talk to the people who use the product, including the recruiting firms we are in production with, and you will sit with a full search from the moment a job is published to the moment the offer is signed. That loop is the job. The backend engineer we hire will make that loop shorter and harder to get wrong: fewer stuck runs, fewer duplicate tasks, fewer invites with the wrong guests, and a record that still matches the story the recruiter would tell a client at the end of the search.
