I looked at the idea of a Resume Markup Language in my previous post. That post stated my belief that a community-driven standard would quickly gain traction, and it turns out that one already has. I discovered the hresume microformat, a means for tagging web page HTML elements with resume-specific qualifiers.
Well, that saves a lot of work. :)
I was in a meeting earlier today where the owner of a company spoke about the problems they had with hiring for a new position. One big problem was the variety of job applicant information coming in the door: cover letters, portfolios, and packaging all varied widely. Small companies see a big problem when dealing with 200 or more resumes like that.
The company’s solution, and, I might add, a standard one, was to offer a web form for applicants to fill out. But the solution takes more away from the job applicant than it gains for the employer. It changes the tone of the conversation.
The applicant is putting their best foot forward – their resume is their golden ticket, and they have invested everything into personalizing it, to impress. But the employer has a hundred tickets to deal with, each ticket’s value being reduced by number of other tickets it competes against. So the employer changes the conversation; they limit the information exchange to what fits on a blank web form. An analogy would be a person buying a new mid-sized car, having a large number of makes and models to choose from, and many salesmen vieing. But the first thing the car buyer asks the salesman is “please, only tell me the color, and the price.” Truncating the conversation not only demoralizes the seller, but key aspects of the offer may be missed: deals, leasing, seller reputation, and so forth.
Another conversation would allow the seller to present all that they have to offer, in a common language. The buyer could filter the information to items of interest. In the case of the job hunter, you want to present your resume, portfolio, cover letter, everything. And the employer wants to see all 100 resumes through a common lens, with the option to see the original offers in their unfettered form.
A structured resume markup language would solve the problem nicely. The document would hold all aspects of the job application process under its domain. You, the job hunter, may still submit everything, but the employer can cherry-pick aspects of the offer as it suits them, filtering on keywords, and archiving information in a machine-searchable format alongside the original document.
One idea would be “subjective flags”; one may mean ‘I put effort into the visual design of this item, please look at it’. It’s an attempt to preserve the plurality of a resume: it speaks to your skills in writing, information design, and asthetics. Your traditional, hand-crafted resume becomes a member of your portfolio, flagged subjectively.
Formats become less of an issue as well. Different formats are faces of the same information, some crafted, some plain. HTML resumes become easier to process. PDF resumes come along beside the markup form. Extraction from office suites is possible, as is format-independent document versioning – the structure is already there, but no one has called it out.
A quick Google search for this idea turned up a little thought along these lines from the HR-XML crowd, but that spec looks a little heavy for our practical needs (but the resume.dtd they offer may be useful). A community de-facto standard would gain traction much more quickly, enabling Open Source software to take root.
We are reducing the friction in conversations between employers and prospective employees; the magnitude of that reduction will indicate this idea’s value.
Interesting stuff.
Here is a random idea: why can’t my email program, using Bayesian filtering and hints from me, make a reasonable guess as to an inbound email’s subject? For any topic in my inbox, not just Spam? Why can’t it pre-assign some tags for me based on it’s guesses?
The UI concept: the user is presented with a bar full of text tags along the top of the email message pane. Middle-clicking on a tag removes it, making it fast and easy to remove bad guesses. Right-clicking on a tag opens a menu containing sub-category tags: this makes it easy to refine the message category.
The user can also add tags by highlighting a word in the message, right-clicking on it, and navigating a hierarchy of tags based on our common “root” categories (similar to our top-level folders, or email labels). The user navigates the tag hierarchy to an appropriate sub-category, and adds the selected text as a new tag in said category. Call this ‘explicit tagging’.
Alternatively, right-clicking on a word, and navigating to an existing tag provides that word as a hint for the filtering system. Call this ‘implicit tagging’.
Every time a tag is added or removed the filtering software takes that as a hint for future mail processing, helping it to guess better next time.
As far as I can tell this goes beyond the Filter/Label/Folder model of email used by 99% of the mail clients out there, and brings in fast and easy way to add, remove, and change context-sensitive message meta-data. What’s more, the system learns as you go, taking grunt work out of your hands.
In a way it is a real shame that Gmail is becoming the personal nerve center for interacting with the web. This would be *extremely difficult* to build into Gmail, because, with Gmail, you don’t own your data!. A Mozilla Thunderbird or Outlook plugin, on the other hand….
I stumbled upon a fascinating set of presentations about being a technology futurist during my study of the technology singularity.
From John Smart of the Acceleration Studies Foundation:
How to be a Strategic Futurist
An integral approach to predicting, managing, and creating our accelerating future. For futurists.
(169 slides, 6MB)
Long, but absolutely fascinating. Some interesting things to note:
Perhaps they see something we don’t?
A Canvas for Thought 