Curriculum Vitae Markup Language

Every time I apply for a job I have to fill in the same information. Name, address, contact details, referees, you know the kind of thing.

On the plus side this is all done electronically now. On the minus side, none of these electronic systems talk to each other. The web sites are all different, with lots of jQuery scripts that are supposed to make the site easier to use (but rarely do). Some sites allow you to apply using your LinkedIn profile, but that assumes the US-centric LinkedIn understands how you’ve completed your profile. Mine isn’t obvious, which is why they send me lots of job adverts for financial positions, owing to being a volunteer Treasurer.

While it pains me to say it (given the number of rejections I’ve had), one of the better sites is NHS Jobs. There, I can fill in a template with all my details, which will then populate any new application so that the only thing I need to do is make sure the standard information is still accurate, then write a bespoke 1,500-word piece that no-one will actually question me on in favour of the bog-standard questions so beloved of interview panels (yes, I’m still bitter).

But what if there was a way to take out having to fill in the standard information every time? Ladies and gentlemen, I give you CVML.

Is what now?

Extensible markup languages have been around for years. Even HTML, the language of the web, is XML. It’s simply a way of describing data in a structured format, readable by people and machines.

In CVML format, my personal and contact details might look like this (human readable layout):

<personal>
      <name>
             <given_name>Gary</given_name>
             <family_name>Taylor</family_name>
      </name>
      <address>
             <line1>XXXX</line1>
             <line2>XXXX</line2>
             <locality>Leeds</locality>
             <postcode>LSN NXX</postcode>
      </address>
      <contact>
             <home_telephone>0113NNNNNNN</home_telephone>
             <mobile_telephone>07890NNNNNN</mobile_telephone>
             <email>gary@taylor.email</email>
      </contact>
</personal>

What about other data?

Some items will vary between applicants of course, such as the number of previous employers, or the number of references. The importer will need to count the number of occurrences when parsing the data. Referees might look like this (a bit less human readable):

<referee>
      <name><given_name></given_name><family_name></family_name></name>
      <job_title></job_title>
      <referee_type>employer|personal</referee_type>
      <address><line1></line1><line2></line2><locality></locality><postcode></postcode></address>
      <contact><telephone></telephone><email></email></contact>
</referee>
<referee>
      (…)
</referee>

So you can throw in as many referees as you like, a new entry would be created in the application form data every time a <referee> tag was encountered. Same with <employer> or <education>, but with different tags inside those tags to include dates, degree title, etc.

Automation, automation, automation

I am not for a moment suggesting that the applicant hand-builds the file. I would, but then I’m stupid. Once we have an agreed vocabulary it would be fairly simple to write a program that would do this for you; it could be an extension to Word, or you could use a .php script and a web form to do the job. But at the end you’d have a text file that you could download to your machine or cloud drive that could then be uploaded to any site that accepted it, and your default details would be added to the job application.

Not everything in our application can be automated of course, it depends on what’s being asked. But if you had a standard file of data, the job application importer would just need to take the bits it wanted and discard the rest, leaving you to concentrate on the bits where you demonstrate you have the skills required.

I commend the idea to the house.

Post navigation

Previous post
Six months later…
Next post
A leap of faith