Paul Hammant's Blog: Merkleized Public Attestations

A single case - Applicant Tracking systems used in recruitment

Get far enough into your career, and you will have used a fair range of recruitment application. Many people will hate all they’ve used, but one less so. I’ve not used one that I’ve really liked, though I have had demonstrations of a couple that looked good. What I really pine for is an Applicant Tracking System (ATS) that’s as good for candidates as it is for prospective employers, while also making it easy and fair for recruitment agents (commission earners). That would mean features and experience that each of teh groups would need. What actually happens is that mid-sized and large employers select applications (Web SaaS these days) that matches their own needs. That’s the recruitment subgroup of HR primarily, and maybe hiring managers secondarily. Recruitment agents who are on the preferred supplier list (PSL) most likely just have to grin their way through the lack of features for them and get quietly busy with lots copy/paste between the employer’s ATS and their own. What they really need is a standard and some interoperation that synchronizes updates between the two. That would be quite doable, if you could get the parties to agree.

Candidates though looking for status updates, are quite often only interoperating with agents or prospective via telephone and email. Well at least after initial upload of CV/Resume during registration of an interest in an open position. Indeed, if there is a recruitment agent. then the candidate deals with them for status updates. The cracks in that sidewalk are around wish for all parties to be kept informed soon after state changes. One party can often be chasing another. There’s a need to be trusting what they say re updates. As a candidate, one of your fears is the recruitment agent isn’t on the PSL for a prospective employer, but said they were to you. The agent would be using a candidates great CV to open the door to an employer and make them a client. That may not work, but the agent doesn’t tell the candidate. Instead, they tell them the client wasn’t interested but that they have other roles/clients. Sometimes the employer gets a CV and doesn’t respond to the agent with a yes or no. Or doesn’t do so quickly. The agent has to assure tha candidate that they’re chasing for that answer without throwing their client under the bus. Those and many other cracks in a three-party system to land a job.

What would be nice would be if all the state changes were provably shared three ways. That’s the attestation of the title. The claim, the parties and the date all visible online without authentication. Using one-way hashes of claims-made + parties + date, we could see a system where the prospective employer publishes a hash of that without the un-hashed version of the same. That publication would be over HTTPS, obviously. It could as easily be static in lieu of the ATS getting the dynamic features needed.

I’ve prototyped something: GitHub Pages static site - the source for that GitHub Project. Shown is a fictionalized application and consideration of me for Tesla as CTO. Not shown is any other feature of an ATS: candidate review, advancing/rejecting candidates, form-responses, workflows, or anything. I link to Tesla’s site as if they were participating in this demo - they would be witnessing the claims/statements (attestations) made about my candidacy. The three records shown in this ATS would have continued to conclusion, but you hopefully get the gist at three entries. It’s ugly so far, sorry:

Each record/row is an update to my fake Tesla candidacy. A new claim is made and with the previous SHA1 hash, a new hash is created from that. Going forward in time it is a merkle tree. The body of each hosted hash in the ATS also contains a link to the next entry in the chain, but not the text that was used to create the hash. Those “next entry” hashes added later if they happen at all (follow-up interviews, rejections, test results, offers, acceptances). Of course, this demo is a little blockchain like. There’s no distributed byzantine consensus though as it was not needed. Distributed Byzantine consensus is a feature of regular blockchains. It is just a vanilla merkle tree with some JavaScript for in-browser verification. Try changing the /# part of URL a little (just a word or two) and reloading the page. You will get some indication of unverified claims that way. Removing the /# part of a URL completely and reloading will show you what happens when there’s no claim at all that could be verified/attested.

The ATS might nuke all entries for a candidacy after six months, or as soon as the application has concluded. That seems like a configuration choice for the employer.

Tesla would host each of the SHA1s for each update. In a backend system they know the plain-text that created the SHA1, but they never share that in any way outside their HR team. They just share the SHA1 which is linked to by the agent’s ATS (which is an evolution of the app shown above). The agent’s ATS, subject to permissions for the logged-in user, would show the text too, and allow you to verify that they one-way hashing is correct, then confirm that the prospective client sees that too.

If the employer was in the EU/UK and GDPR allowed for a candidate to discover what was stored about them, the test and the hashes would be made available, but the candidate would have already had them. Of course, HR teams keep interview notes/feedback that doesn’t get sent by default to the candidate. “Paul knows nothing about cars” is something Tesla staff could have written internally in the ATS, but not passed back to me with the “Thanks for your candidacy, but at this stage we are going with other candidates”. In the EU/UK could still ask for the full commentary, so interviews are asked to “keep it legal”.

So in the end the prototype app isn’t so much an ATS syncing standard that allows agent and client ATSs to stay in step, it is more of system of safely keeping track of top-level events in public. I had wondered whether this could be a startup, and I don’t think it is. It would be a neat idea for existing ATSs to adopt though, and it is not a lot of code as it is quite a straightforward un-blockchain implementation.

At some point transactions systems including card purchases & receipts, corporate expenses, all get merkleized presences online. Monthly statements too. Tax collection starts to use it, and more. All hosted by the key participants and not shoved into a public blockchain as that’s not needed.