Talent Community 2.0

Terydin places people with client companies, which means its inventory is people. Before this work, a talent signed up, searched jobs, and that was the whole product. Nothing brought them back between searches.

That is a business problem before it is a design problem. A pool that only surfaces when someone happens to be looking has to be re-acquired from scratch every time a client request lands. The people you spent money reaching last quarter are gone, and the roles you need to fill this week go to whoever you can find in a hurry.

The before screen makes it plain. Four navigation items, an empty job list, and a profile the user is told recruiters cannot see. There is nothing to do here and no reason to come back tomorrow.

One model pass produces one score, an integer from 0 to 100, keyed to the pairing of a person and a role. That same number is then rendered twice: once for the candidate in the second person and deliberately encouraging, and once for the recruiter in the third person and candid, with a recommendation, the evidence and the gaps to verify.

One score behind both renderings is the load-bearing part. If the candidate and the recruiter can see different numbers for the same pairing, the first difficult conversation is about the numbers instead of about the person.

The fairness rule lives in the output schema rather than in the prompt. The gaps list is structurally prevented from citing a lack of United States, contract research or international experience, and from citing retention, flight or placement risk. For an African talent business selling into United States clinical research those are precisely the biases that would otherwise turn up in writing, and a prompt instruction is a request while a schema is a constraint.

The recruiter block is excluded from any candidate-facing data export, which is what lets the candid rendering stay candid.

Withdrawal is terminal, and re-applying after withdrawing is not possible. A two hour re-apply window with a countdown was built and then torn out. At roughly one hundred to two hundred applicants per role, re-application traffic does not manage, and standard applicant tracking systems do not permit it either. The cost is real: someone who withdraws by mistake has no way back on that role.

The cap is a blunt instrument. Five active applications is right for someone applying deliberately and wrong for someone genuinely qualified for six open roles at once. A route to a higher limit through the academy or verification was scoped and deliberately pushed to a later version rather than crammed in, which means the blunt version is what people live with in the meantime.

Free text skills never reach the global skills database. It stays a managed list, which frustrates anyone whose actual skill is not on it. The alternative destroys the thing that lets operations judge the quality of a pool without reading every CV individually, and it does so within about a week of launch.

Every one of these makes the product harder to use on purpose. That is defensible only because the alternative was a pool nobody could judge and a ranking nobody could trust.

The talent side went from four surfaces to a product with somewhere to be when you are not searching: announcements, a Learning Hub with academy and general tracks, Career Paths with role progressions, ranked search, recruiter invitations, a real application flow and a status timeline.

The ranking runs as a precomputed background job rather than a live search, cached for thirty days and invalidated when a profile or a job description changes, so a wrong score has a bounded life rather than an indefinite one.

The score is never a gate. A low fit produces a warning and an explicit route to apply anyway, so the model is allowed to be wrong without it costing anyone a job.

Every feature ships with a handover document, and writing it is part of the work rather than something that happens afterwards if there is time. Talent Community 2.0 shipped as a series of three: the scoring prototype first, then the operations side, then the talent side. The scoring document is numbered first deliberately, because both portal documents point at it instead of each restating the model, so reading order matches dependency order.

A handover document answers what the feature is, what was built, and why. Everything else is chaff and gets cut. Column pinning, pagination internals, class names, breakpoints, query key shapes: none of it changes how anyone understands or uses the feature, so none of it belongs. The test is that single question, applied line by line.

The most valuable section is always how the two sides connect, and specifically the places they do not connect but a reader would reasonably assume they do. A drill-in that does not carry its source, so the back button lands somewhere wrong. An empty state telling someone to act on a screen that has no such control. Verified status seeded from mock data because no completion source exists yet. Those are the things that cost a new engineer a day each, and they are exactly what a document written from the code rather than from the product will omit.

A handover document states, it does not debate. If product settled something, it is written as settled, with no hedging and no invitation to reopen it. Genuinely open questions go in their own section, plainly. A defect in the code is stated as the fact it is. Dressing up a settled decision as an open one reads as thoroughness and is actually just a document nobody can rely on.

The model choice was settled by a head to head rather than by preference. Haiku 4.5 against Sonnet 4.6 on the final prompt across an eval set, tied at eleven of fourteen, missing the same three cases, at roughly a third of the cost: about four tenths of a cent against about 1.2 cents per dual-surface score. At the scale in question, a thousand people against fifty roles, that is roughly two hundred dollars one time.

Tied on quality and missing the same cases is the result that matters. It means the cheaper model was not worse in a way that would show up in someone's ranking, so the decision could be made on cost without quietly making the product worse.

Malformed model output is retried once and then treated as null, and the surfaces hide rather than render a fabricated score. Designing the failure state first is what allows the score to be shown plainly rather than hedged.