Neodym / Writing
Recruitment Portal: building the handoffs around hiring
Connecting applications, candidate next steps and reviewer queues without reducing a hiring workflow to a score.
The application is only the beginning
A careers page can collect an application, but the work continues after submission. Candidates need to know where to go next. Recruiters need to follow progress across stages. Reviewers need to find the submissions they are responsible for assessing. Those are different tasks, even when they concern the same application.
Neodym’s Recruitment Portal brings applications, hiring assessments and reviews into one product. Its public entry page separates open roles and candidate sign-in from staff workspaces. The candidate portal is organized around continuing assessments, checking deadlines and viewing application updates. Staff entry points distinguish pipeline administration, recruiter work and assigned review queues.
That separation gives this project its engineering focus. The challenge is to carry an application through several handoffs while keeping the next action understandable to the person doing it. A single dashboard with every control would blur those responsibilities.
Connect the website to the next step
The Neodym website’s careers integration includes a follow-up email directing applicants to continue through the recruitment portal. The message asks them to use the same email address they used on the website, choose the role that fits their background, verify their email and complete the next steps in the portal.
Using the same address is a small instruction with a practical purpose: the website application and the portal account need a consistent point of reference. Without a clear handoff, someone may reasonably think submitting the first form has completed every step, or start again with different account details.
This also creates two experiences to design rather than one. The website introduces the opportunity; the portal carries the ongoing application workflow. A confirmation message should explain that boundary plainly. An invitation is a route into the next step, not proof that the person has already completed it. We do not attach a delivery-time promise to that handoff.
Give candidates a view of their own progress
The candidate interface represents an application through phases, with status, opening times and deadlines. It also handles application notifications and onsite invitation state. These are concrete pieces of workflow context: what stage exists, whether it is available, and whether a response or assessment is the next action.
A deadline has little value if someone cannot connect it to the right task. Likewise, a submitted assessment and a published result are different states. A useful candidate experience needs to preserve those distinctions instead of collapsing everything into a generic progress indicator.
There is a tradeoff between showing the full process and keeping the immediate task clear. Candidates need enough context to understand their application, but they should not have to navigate staff grading controls to find an assessment. Separate candidate and staff workspaces let the product present the same process through different responsibilities.
Review is a workflow of its own
The public portal describes a reviewer queue for assigned Coding and Essay submissions. In the project, review-queue records include submission state, scores, grading notes and reviewer information. The queue has explicit status and assignment scope, rather than treating every completed assessment as an undifferentiated item in a results table.
This is where human review belongs in the story. A submission needs to reach a reviewer with the context required to assess it. A score can support that work, but it is not a complete account of a candidate, and a software-generated output should not be presented as a final hiring judgment.
The project requirements explicitly call for AI to assist screening without silently making final hiring decisions or using sensitive traits. That is a design requirement, not evidence that fairness has been independently established. We make no claim here that automation eliminates bias, predicts job performance or replaces accountable review. Those would require evidence beyond the presence of a scoring feature.
Build around responsibilities before adding automation
This project is a useful reminder that hiring software has more than one user journey. Candidate next steps, recruiter progress monitoring and submission review need to connect, but each needs its own clear surface. Adding another assessment or scoring model cannot repair an ambiguous handoff between them.
If you are applying to Neodym, start with our careers page or the portal’s public entrance and follow the instructions for the relevant role. If you are building a hiring platform, start by mapping who owns each transition: application received, assessment available, work submitted and review completed. Bring that workflow to us before choosing which steps to automate. It gives the product a practical foundation while keeping people responsible for hiring decisions.
Last updated