The rejection letter and the scorecard told different stories
The rejection letter and the internal scorecard described different submissions.
In the candidate’s published account, they say the technical recruitment process included an HR call, a week-long take-home exercise and a live debrief. After the rejection, they made a data subject access request and received the scorecards from the company’s applicant tracking system.
The feedback sent to the candidate praised the database design and code architecture. The internal scorecard gave the frontend its lowest rating because the assessor recorded that no frontend had been built.
But the submission did include one. It used Rails ERB templates and Tailwind styles.
That choice also followed the exercise. The prompt reproduced in the account asked candidates to keep the prototype simple, said styling was not important and explicitly allowed server-rendered HTML. The candidate delivered a server-rendered interface, then encountered an assessment that treated the absence of a JavaScript framework as the absence of frontend code.
The same judgement reached the candidate in the verbal feedback, stripped of the score and the record behind it. When they challenged the mismatch, the interviewer later acknowledged that the instruction to keep the solution simple could have been ambiguous. The outcome did not change.
The scorecard exposed another difference. The official feedback was polished and general. The internal notes leaned on impressions about how the code felt and whether it resembled the work expected from an experienced Ruby engineer, without pairing those impressions with concrete examples.
The candidate could compare those two versions only because they obtained the internal record and published the documents together. Most candidates see the rejection and never see the scorecard that produced it.
One account cannot show how every recruitment process works. It can show what happened in this one: a candidate followed the stated constraint, the internal assessment penalised the result as though the requested layer did not exist, and the feedback they received concealed the contradiction.
The scorecard was the record used inside the company. The rejection letter was the version written for the candidate. The data request made the distance between them visible.
Candidates rarely see the internal records behind a rejection. This account places the feedback sent to the candidate beside the scorecards used inside the company.
The documents matter because they expose a contradiction the rejection alone concealed: the exercise asked for a simple server-rendered interface, then the submission was marked down as though no frontend existed.