A pass mark is a filter, not a verdict
Our assessments auto-advance candidates who clear the bar, and do nothing at all to those who do not. Automating the rejection was the one step we refused to build.
When a candidate clears the pass mark, the system books an interview and emails a calendar invite without anyone touching it. The obvious symmetry would be to reject everyone below the line automatically. We deliberately did not build that.
The reason is that scores fail in ways that have nothing to do with the candidate. A code-execution timeout, a test case with an off-by-one in its expected output, a network drop mid-submission — each produces a low score that looks exactly like weak performance. An interview booked in error is a scheduling annoyance. A rejection email sent in error cannot be recalled, and the candidate has already told their current employer nothing and moved on.
So below the bar is a flag. The candidate stays where they are, no email goes out, and the score sits on their record for a human to read. Every rejection in this product is a person clicking reject.
This is slower. It is also the difference between a filter that helps you prioritise and an automated system that quietly disqualifies people because a container ran out of memory.