Send a coding test and keep the result on the submittal

A coding assessment platform builds the problems, runs the sandbox, measures correctness and performance, detects plagiarism and defends the methodology. Those are hard problems with a lot of engineering behind them, and recruitment software has no business claiming any of it.

The planned integration is deliberately narrow: request a test, track its status, receive the score and the report, attach both to the right record. Surhires does not re-score a submission, does not interpret code quality, and does not convert a provider score into a hiring recommendation. If your process has a threshold, it is your threshold and it is recorded as your decision on the submittal.

Surhires does ship a native assessments module, and it is a different tool for a different job: structured evaluations your own team designs and scores, tied to a scorecard. It is not a code execution environment and it is not sold as one.

Today a technical recruiter copies an email address into an assessment console, sends the invitation, and then the candidate exists in two places. Chasing a non-starter is done from memory or from a browser tab left open. When the result arrives it lands in an inbox, and whether it reaches the candidate record depends on whether someone remembered to attach it.

The consequence shows up at the wrong moment. A client asks why a candidate was not progressed, and the answer is in a PDF somebody downloaded three weeks ago. Or a strong candidate who scored well six months ago is re-invited to the same test because nobody could see the previous result on the record.

The push is small: the candidate identity and email needed to issue an invitation, and which test you chose. The return is the score, the report and the completion timestamps.

What will not come back into Surhires: the candidate's actual code submissions, individual test-case results, session recordings or screen captures where those are used, plagiarism analysis internals, and your test library content. Those belong to the assessment platform, some of them are the provider's intellectual property, and none of them have a recruitment workflow that needs them sitting in a CRM.

Where a test result contributes to a hiring decision, the record shows which candidates were scored, when and against which requisition. That is what a review or an independent bias audit would need. Deciding your threshold, notifying candidates and commissioning any audit remain your responsibility.

One practical benefit of results living on the candidate record rather than in an inbox is that you can see when someone was last tested. Re-inviting a good engineer to the same assessment they passed four months ago is a fast way to lose them, and it happens because the previous result was invisible at the point of contact.

The counterpoint is that scores age, and how long a result stays valid is a policy decision for your team rather than something a CRM should decide. What the record can do is show the date and let a recruiter make the call with the information in front of them. Retention of the result itself follows your configured retention window, like any other candidate data.

Invite from the provider console, then record on the Surhires candidate record that a test was sent, which test, and the date. A custom field or a pipeline stage makes the waiting group visible so chasing is systematic. When the report arrives, attach the file to the candidate and record the score and your threshold on the submittal, not just in a note.

For agencies sharing results with clients, capture the candidate consent to share before forwarding a report. Technical candidates in particular tend to have views about where their submissions travel, and asking is cheaper than explaining afterwards.