We’re still moving forwards with our MVP for SEATS and we’re at a point where test data would be lovely. So, if you happen to have a copy of your resume lying around and wouldn’t mind sharing it, please use this form to submit a copy to us. We promise that your resume will only be used for testing our lexer/parser to ensure that the resume makes it from Word/PDF/Pages/text/RDF into our storage format correctly.
Thank you in advance.
In a quick word, no. If for no other reason than it’s awfully hard for a recruiter to do a search and have your video bubble up in the results. Simply put, a recruiter would have to watch your video to see if you’re a match — and then watch it every time you come up in a search. If the recruiter is ambitious, she may tag your video with a few key words, but that will only be helpful if the same words she tags are the same words that some other recruiter from the same company happens to search on later. Unless you are applying for a video performance job (like newscaster, actor or PR person), they’re not going to have a mountain of free on which to spend watching video resumes.
On the plus side, a video resume will make you stand out (for now, until everyone does them). But remember, not everyone should use video as the medium to sell themselves: for example, the rock band Foreigner was have good sales until MTV came out; the kids got a look at the band and largely stopped buying their records. On the flip side, Britney Spears is a converse example of image over ability.
In the minus column, a video resume can eliminate you for a job. For better or worse, some firms may favor one person over another for reasons not necessarily associated with the quality of their work — particularly if such a firm is under a diversity mandate or your individual look is outside of the cultural norm of the company to which you are applying — think of being a straight laced republican applying to Greenpeace. Bear in mind that the subtle cues embedded in the video may reveal more than you intend. What do I mean by subtle cues?
Things like that.
If you’re do decide to make a video resume, then here are a few tips:
Finally, always remember Aleksey Vayner as the cautionary tale it is. If you’re never seen his video resume, it’s a hoot.
—-
(1) — The high production values comment does not apply for video based jobs. Anything less than high production values for a person trying to be a news reporter will be a pretty big negative.
If you are a job seeker and you go to most job boards these days, you will be asked to do one of three things:
All of these approaches get the data into the resume database, but some of the approaches are better than others.
Well, the overall process is generally the same, but the specifics depend on the specific format of the file. All resume processing sites parse the resume file, attempting to allocate the resume data into neat buckets — this block of words are all associated with the work experience at firm “X” during dates “Y”-”Z”, but that block of text is about the time spent at university “A” majoring in “B” from date “C”-”D”.
Depending on how the document is formatted, the format itself — particularly with an XML variant like .docx — may contain clues within the structure of the data relating to the content of the data. In other words, metadata. While the generic overall schema specific to .docx (the MS Word format for Office 2007 and later) is not even vaguely resume oriented, the general convention amongst most resume writers is to use various formatting options (bold, italics, underline, white spaceetc.) as signifiers for changes between resume data elements.
Pretty much any format into which a resume can be saved can also be parsed. Some formats (text, docx) are easier than others (PDF, I’m looking at you); in general, it’s a matter of how much work it will take to find and correctly identify the sections of data. In the next post of this series, we’ll go into further detail for the most common resume storage formats, their associated pluses and minuses and other assorted details.
This is the first of several posts about the technical details on how resumes are commonly stored in the online world.
Since Mike has moved on and Scott and I have been looking for a replacement, we have also been closely evaluating our current business and technical model. At this time, we no longer believe it to be feasible within our current level of resources to pursue resume synchronization; we will be changing our focus and moving down the ATS route.
Be warned, this is a bit of a long post. I’m writing it to explain what is happening, why it is happening and what to expect in the future both to everyone already involved with the project and to the other people who had signed up to try the service but had not yet gained access.
To recap, the original idea behind RE was to provide a resume synchronization service to job seekers, alleviating the need to re-enter the same information on site after site. We were planning on doing this in one of two ways:
For our proof of concept, the plan was to establish three way synchronization between LinkedIn, Monster and the Washington Post.
The service was to be free to job seekers. As you can probably imagine, we had them lined up at the door. Seriously; we signed up a few hundred people on a simple landing page strictly from word of mouth (mostly me going to DC area networking events) and a very limited ad campaign. Even more encouraging, our LinkedIn ad campaign enjoyed a 72.341% conversion rate (as compared to 12.441% from AdWords and 0.000% from Facebook ads). Obviously, the FB part wasn’t so spiffy, but LI was very attractive.
We were planning on charging recruiters for access to the system; we had interest and continue to move along with validating the pricing model — even with our pivot, recruiters and sourcers will remain our primary target demographic.
We enjoyed rudimentary success with the Washington Post interaction, and pseudo-success with LinkedIn. Monster was a loss, start to finish.
The LI API is extremely limited, only dealing with a small portion of the resume data LI captures and even then universally one way (out of LI only). Given that LI’s API was insufficient, we retrenched and tried to screen scrape LI instead. We had something that worked for period of time, and then we ran into a CAPTCHA. Interestingly enough, we only encountered the CAPTCHA when running our scraping program from AWS or Rackspace; I suspect LI has instituted a CAPTCHA for an IP originating from a known cloud server farm for just this reason.
We explored some alternative means, including what Kevin DeWalt calls manulating. While that would suffice (barely) and I did find some cost effective providers in both the Philippines and Bangladesh, it was workable as a tertiary fallback mechanism, not as a primary means of scalable production.
To the best of our ability to discover, Monster does not have a published API. Screen scraping was not viable, as Monster heavily uses JavaScript and AJAX throughout their site, and the Python based solution we were using consistently choked during the attempt to process the website. While there are existing products that can drive a JavaScript/AJAX website (if nothing else, automated testing tools), there were none that we found which fit within our technical framework or made business sense.
Actually, we made good progress on screen scraping this site. We stopped killing ourselves over it based on the problems with LinkedIn & Monster, as a synchronization process linking one site to itself isn’t all that useful.
The kick of the whole thing is that even if we had been completely successful with all three sites, we would always be at the mercy of the designers of the respective sites we are synchronizing. If they change one little thing, the screen scraper would require inspection, if not refactoring. And, in today’s world of continuous deployment, they would always be changing something. It’s the epitome of a Red Queen’s Race. Initially, we accepted this risk on two assumptions:
The arrogance in that last statement is palatable, isn’t it? In any case, the amount of work required to resolve even the very limited interfaces to the synchronization sites proved this approach to be to expensive to maintain at any level of scale.
We’ve acknowledged this before, but there are a lot of job sites. And, it seems like there are more popping up every week. Even though our name is “Resume Everywhere,” we were never going to be able to cover every job site everywhere. From our initial estimates, we were going to need a junior to medium level screen scrape developer for every 20 sites we signed up. We had some ideas and tools in the pipeline that would have acted as a force mulitplier for that type of development, but it hasn’t been built yet. Strike three for synchronization in the scalable business competition.
A month or so ago, I was in NYC for SourceCon 2011. A conference dedicated to the needs of the sourcing industry, I went to do some customer validation; specifically, would these people be interested in searching the database of resumes collected through the synchronization process and how much would they be willing to pay for the privilege (the answers were “sure” and “it depends,” respectively). It was a good conference; I met lots of good people, won an iPad and learned quite a bit.
One of the things I learned was that nearly all of the people present expressed their intense dislike of their Applicant Tracking System, or ATS. The informal poll taken at the start of the conference revealed that only one — one — person rated their ATS as a 3 on a 1-5 scale; three or four more gave their system a 2 and everyone else gave it a 1 (with many saying they would give lower if they could). This is pretty clearly a market that is being underserved.
In essence, an ATS is fundamentally a workflow application in which candidates are routed through a system of decision gates where various people (hiring manager, HR, senior management, etc.) have to approve a candidate for him/her to move forwards in the process. Between Scott and myself, we’ve architected, designed, developed, deployed and maintained over 30 different workflow systems for customers such as the US Department of State US-VISIT program or the FAA OE/AAA (Obstruction Evaluation/Airport Airspace Analysis) system, just to name two off the top of my head. We know how to move data around efficiently, and we get scale.
Where we are lacking is the domain knowledge for what specifically makes an ATS a good system and what does not. That is going to be foremost on our minds for the next several weeks, as we interview potential customers to learn of their pain points in much greater detail.
Yes, no syncing. At least not for now. I still believe it’s a compelling business model and that there is significant user demand from job seekers for such a service. However, we are going to table synchronization until such a time when we either have the resources to pursue it correctly or the technical landscape has changed to make such a solution both feasible and scalable as well as cost effective.
So, that’s about it. We’re starting to execute our pivot, by which I mean we’re stopping on coding and going full time on customer development until we figure out exactly what a lean, stripped down and bulletproof ATS looks like. Then, we’ll be back in heads-down, staying-out-of-the-big-blue-room coding mode until we get things done. Hang on; it should be an interesting ride!
Over on CIO Magazine, Kristin Burnham lists four ways to enhance your LinkedIn Profile. These are:
I’m sure that Kristin is focusing on these four because they are the latest features LinkedIn has added to the profile. She did leave off patents, which may be reasonable as most people will not have a stack of them lying around. However, don’t forget the other areas in which you can customize your profile:
With all of these items, though, use your best judgement. Adding a twitter feed to your LinkedIn profile may not be the best idea if you spend a lot of time tweeting about carousing in bars and betting on boxing matches. While that may appeal to some potential employers, it will probably put off much more of them.
