1
Get in Touch

Get in touch with us

540 Years of Using Resumes?

540 Years of Using Resumes?

Yes, you heard that correctly, we’ve been using resumes for almost 540 years, or maybe even longer!  Leonardo da Vinci is credited with drafting the first resume back in 1482 to get a job with the Duke of Milan and we are still using resumes today.  At this rate we are literally more likely to have the human race step foot on another planet 245 million miles away before we stop looking for keywords in resumes.   

Tell me if this process sounds familiar as a recruiter:

Step 1 – intake meeting, find out needs, wants, knock-outs

Step 2 – create, edit, or use an existing job description to identify keywords

Step 3 – go into the applicant tracking system (ATS), pull up the job vacancy, then open up each applicant in chronological order one at a time and open their resume

Step 4 – look for keywords in the resume that match the keywords in the job description

I realize I’m generalizing the process, but for most companies, I speak with, this is basically how it goes.  Not only can this process be inefficient, but it can also be equally ineffective.  

Recruiters have so many tasks they need to complete each day and going through resumes one-by-one is just plain time-consuming.  They could make better use of that time by doing more passive recruiting or spending more quality time with qualified applicants.  

What do these self-authored documents tell us about a person?  Not much.  Sure, resumes tell us where an applicant worked, what they did, and sometimes what their results were.  But they are lacking the real context and objectivity usually needed to match a person to a role.   

Let’s say your job description is looking for “proficiency in MS Excel.”  You find a resume and sure enough it states, “highly proficient in MS applications, including Excel.”  Eureka, we have a match!!!  Or do we?  The problem is, humans and even artificial intelligence can’t tell us what that applicant meant by “highly proficient.”  Highly proficient could mean they know how to create Power Pivots or it could mean they know how to open Excel and put numbers in the cells.  Unfortunately you won’t know until you ask the applicant.

Unfortunately for applicants, we don’t ask every single one of them detailed screening questions about every requirement because that would take way too long.  Sadly we often miss the opportunity to ask detailed screening questions around requirements to candidates coming in for interviews.  The risks of not getting this level of detail from applicants can be very expensive.

I think if he were alive today, even da Vinci himself would tell us, “it’s time to let the resume go.” 

Why are we still using job descriptions to attract talent?

Why are we still using job descriptions to attract talent?

Job descriptions add a lot of noise and very little signal to the screening process. Why do we still use these things? What value are we really expecting they will generate when we attach them to an open job vacancy? They don’t help the applicant clarify the role and they certainly don’t help hiring organizations weed out unqualified applicants.

I look at job descriptions every day and I’m shocked with how little they have changed over 20 years, especially considering they are largely ineffective.

It doesn’t matter if the hiring organization is large or small, job descriptions are all structured almost exactly the same and all filled with the same vague language.

This creates a rather large problem for talent acquisition teams, especially if they receive a high volume number of applicants. The result…too many unqualified applicants. Why? Because companies are leaving all the interpretation up to the applicant.

Case in point: Just this week I was reviewing a job posting for a software engineer position at a large software company. The “Skills” section was riddled with vague terms such as:

  • Demonstrated proficiency in programming to include a solid foundation in computer science, with competencies in one or more of: data structures, algorithms, object-oriented software design, and working with cloud-based distributed systems.
  • Experience working in modern programming languages such as Dart, JavaScript, Go, Java, Kotlin, Python, or C#
  • Some experience debugging systems or applications
  • Familiarity with one or more of the following areas: Amazon Web Services, Google Cloud Platform, relational databases, REST, and other modern web protocols, and/or Mobile computing

What exactly do “demonstrated proficiency” and “solid foundation” mean? How do you define “experience”? What is the difference between “experience,” “some experience,” and “familiarity”? What if the person has “experience” with 1 of the 7 programming languages (Java), but that experience was 25 years ago and lasted 3 months? Is that really what you’re looking for?

Most job applicants will interpret “experience” or “demonstrated proficiency” to their benefit, which means that more applicants that don’t match what you’re looking for will apply. And this means more time reading and filtering resumes.

It’s probably time we find another way to articulate the qualifications that we are looking for with open job vacancies!!!