Skill verification is the first of our service principles, so here's what it actually involves, in the order it runs. Nothing in it is revolutionary. The difference is who does it and what we're willing to reject.
First pass: a practitioner reads the profile. Not a recruiter with a keyword list, but someone who has done the kind of work the role needs. Many applications stop here, usually for a specific tell: projects described in a way that suggests the person was near the work rather than doing it.
Second: a technical conversation about something the candidate has actually built or tested. We ask them to walk us through a real decision: why that approach, what broke, what they'd change. People who've done the work enjoy this conversation; people who haven't, don't get through it.
Third: practical evidence. Depending on the role, that's a review of real work, a short paired session, or a focused exercise: a QA candidate gets a feature and is asked how they'd test it; a developer gets code with planted flaws and is asked to review it.
Fourth, and least automatable: how someone communicates when they don't know something. The candidates who say 'I don't know, but here's how I'd find out' get a note in their file. The ones who bluff get a different note.
Only a small share of people who enter this process reach a shortlist, and that ratio is the product. You should want to interview most of the people we send you. If you find yourself rejecting our shortlist on paper, we've missed, and we want to hear about it the same day.
