Talent search: by-resume vs skills-first

Most recruiters match vacancies and resumes by titles and work history. The idea is that a candidate would be able to transition to a similar title and/or industry more easily. It works, it is time-tested, but it is not the only approach possible. LinkedIn and other resume platforms are undoubtedly an industry standard. But all standards have their limits worth exploring. In this article we’d like to compare good old Resume-based and emerging Skills-first approaches.

Issues of resume-based search 📝

The essence and pros of resume-based approach are clear and familiar to all recruiters, so we’re going to jump over that and focus on its drawbacks; which might be less obvious and recognizable. We will discuss some things “in theory” but the main goal is to derive practical and valuable conclusions, applicable to everyday work and reasoning of every recruiter.

Titles are a simplistic view

Our world of ever-expanding tech fields and ever-narrowing specializations makes it increasingly difficult to assign and evaluate titles. Developers commonly describe themselves in different and seemingly unrelated terms on different platforms and accounts. The same person can be a Backend Developer on GitHub, a Software Engineer on LinkedIn and a Django Afficianado on StackOverflow. The boundaries of engineering fields are in constant change and overlap and titles reflect that.

Another angle of the problem is that many people cannot describe their occupations with a single sentence. To make things worse, different companies prefer different titles for their employers. It’s pretty hard to find an agreement on exact Data Engineer, Data Scientist, ML Engineer, ML Ops, Dev Ops duties and definitions.

A similar problem arises with technical skills. Recruiters have to learn and apply convoluted taxonomies and hierarchies like Redux ← React ← Frontend ← Web ← Software that possess zero meaning and zero value for recruitment per-se. Such a requirement exists only as a by-product of “Title Matching”.

The palliative solution for taxonomies is a boolean search with inevitable monstrosities and inconvenience of:

(React OR “ReactJS” OR "React.js") AND 
(Engineer OR Developer OR Programmer) 
…

You may even like it as a part of your professional toolkit, but it’s worth acknowledging that it is low-level, slow, error-prone and mostly a consequence of a search system being unable to understand your intent. And this happens when the search system is too generic for the task. There is a better way.

Resumes are too subjective

The second base flaw is that resumes and CVs are fundamentally subjective. An author is free to add or omit any information. Anyone can endorse any skill of anyone. There’s a grey-hat strategy to endorse 100 random guys with the expectation that ~10 of them will endorse you in return... Money and the Universe are not the only things that inflate.

The desire to make our resumes as appealing as possible is natural. But you never know how far someone has advanced in that direction, and to which extremes. Some people exaggerate to jump out of poverty and a “nice job title” with an “impressive job history” becomes the the missing link between them and their goals. Cultural differences also plays a role with some cultures being critical to self-praise and overestimation, and others – being tolerant to that. In the end, if the only bad consequence of lying is a “bad karma” – it’s not that threatening, to be honest.

It also does not help that everyone knows the evaluation rules. Because:

When a measure becomes a target, it ceases to be a good measure.
Goodhart’s Law

Resumes are mutable

Finally, the third issue amplifies the second one and it is about mutable history. What does it mean? The most important part of a resume is a work log. And you can update any part of it any moment. You can “remember” how you “worked” in a non-existing startup in 2010 and no one would care to verify. You can add skills, improve the working/unemployed ratio, and so on – retroactively. Most people won’t lie directly, but rather round up and overemphasize their contributions.

Inflation often happens in response when you find your former colleague’s resume with a long and glorious list of achievements. His profile overshadows yours and it’s completely unfair, since he joined the team a year later. So you return to the resume, recall even more minor details... and the self-sustaining cycle repeats.

An immutable history would look like this: each person’s events and contributions are automatically tracked and can’t be changed afterwards. It’s impossible! – you think. But as the next section will prove, it’s precisely the case with the skills-first.

Resume-based is not going anywhere, it has its place and supporters, but it’s clearly not perfect. LinkedIn and other resume platforms, to their credit, recognize the inherent weaknesses of the approach and introduce additional metrics to evaluate profiles. Certificates, testimonials, course completion badges are all valuable resume extensions, and a great help when present.

Skills-first alternative 🔭

DevScanr advocates skills-first approach which, in our belief, can be a viable and affordable alternative to resume-based search in many cases. Like the name suggests, the idea is to begin talent search from the opposite direction, matching skills and specialization(s) first. With skills-first you still care about resume: intro, work history, etc. It’s just their analysis is shifted to a later stage.

The cornerstone of the methodology, at least in DevScanr’s interpretation of it, is potentially an unfamiliar thing called dev. profile. Not all tech. talent are developers, but, as DevScanr reads talent data from dev. platforms like GitHub or StackOverflow, – we call that data their “dev. profile”. Besides raw data, it also includes the inferred data and the automatic interpetations.

So how it works? The platform looks for a person’s open-source contributions and activities, the DevScanr AI engine analyzes that, extracting and deriving the necessary information. Essentially creating an automated resume substitute with its own unique characteristics.

Some recruiters believe that only a minority of users are active open-source contributors, so this approach should not work. But that depends on how broad is your definition of “open source”. Most engineers, indeed, are not library or framework authors. But it’s certain that most (almost all) engineers are open-source consumers. Here’s an incomplete list of dev. activity tracked by Git/GitHub beyond Repositories:

• Stars
• Forks
• Sandboxes, Experiments
• Documentation
• Roadmaps
• Tutorials
• Notes, Gists
• Articles
• Comments
• Issues
• Charts, Diagrams
• Exercises, Challenges, Koans
• ...

Following a user, watching an organization, posting a reaction, along with dozens of other event types are tracked, made publicly available by GitHub and, therefore, can be read and taken into account. This data contains more than enough information about talent interests, effort, seniority. And for, at least, somewhat active users the volume of that exceeds the volume of resume by orders of magnitude.

Skills-first vs Resume-based

Skills-first corrects all 3 forementioned weaknesses of resume-first. As dev. profiles typically contain substantially more data about tech. side of a person than resumes, the system can understand who-is-who to a greater extent. Instead of a single resume title it’s possible to derive several applicable titles with different percentages of applicability.

Title (mentioned): 
  Java guru at WorkLoad
  
About (mentioned, 10 screens below):   
  ... Occasionally doing React.
     
Specialization (inferred):
  Web Developer (90%)

So it does the same thing a human recruiter would do while evaluating a profile, given an unlimited time. Only it’s automated so there’s less room for errors, subjectivity, fatigue. It’s impossible to manually lurk over repositories, gists, issues of each potential candidate. But a machine can do that, so why not use its power for your benefit?

Unlike resumes, dev. profiles are objective. They are produced by a 3-rd party that does not know the person or care about their career. The whole thing can be biased in favor of some specializations – due to imperfect algorithms and the lack of data. But all this is at least unintentional and usually fixable.

Each event, like a repository creation, comes with a timestamp. Suppose one day skills-first becomes a standard and Goodhart’s Law becomes applicable. Some shady guy wants to “break the system”. He cannot technically create a repository, publish an article, or watch an organization “in the past”. So he just adds 1000 stars in one day. He also forks and pushes 200 repositories. However, unlike his resume actions, it all becomes blatantly obvious in history and can be spotted in seconds with DevScanr tools like heatmaps. It is the immutable history we mentioned earlier.

“Why objective and trustworthy dev. profiles are not used more widely in recruitment?” – you may wonder. Because making such profiles is not easy and pretty much impossible to do manually. We wouldn’t be able to do that either – without AI, automation, and a long period of trial and error.

By removing a strict tie between what’s mentioned and what’s searchable, skills-first approach allows to discover talents with missing, incomplete, unexpected titles or history records. Which opens a whole new dimension of talent pools you never seen or interacted with. And, because it applies to all recruiters in parallel, this talent pool is not spoiled by extra attention, not spammed by job proposals. And that’s huge.

Note that the table above compares Resume-based and Dev.Profile-based benefits. To our knowledge, no platform currently implements anything close to the hypothetical Resume-first: that would combine a full-blown resume with full talent activity from various dev. platforms on a single profile page. It’s probably too complex in practice.

Skills-first methodology, in theory, unites the benefits of both columns because you’ll have both resume (external) and dev. profile to analyze. More data is better, right? The time to read both sources is summed as well... But there’re two more things to consider. The churn rate of your qualified prospects: how many of them will eventually be approved and move to the next pipeline stage. And a resulting price per approved candidate. Efficiency comparison is a very complex topic so we’ll reserve the details for another article.

The issue with skills-first, to be fair, is that not all dev. accounts are equipped with resume links. This is another culturally specific feature: for example, users from South America tend to have a higher % of (mentioned) contacts in their profiles compared to other countries. And by higher we mean like ×2 more sometimes. DevScanr provides a contact filter but it, expectedly, reduces a pool of talents when applied. Another solution, from the platform side, is to reverse-search links over the Internet. Which is doable but expensive.

Summary

We introduced you the DevScanr team’s vision of resume-based vs skills-first talent search methodologies. They are really methodologies or schools of sourcing that can be called “approaches” with a degree of oversimplification. Neither one is perfect or irreplaceable. To not abuse your generous attention, let us stop with a conclusion.

We believe you will find candidates faster by matching dev. profiles before matching resumes. We have reasons to believe that, including statistical ones. In the end, both approaches work, and personal preferences are a key factor. Our recommendation for you is to try both, with enough time for a proper judgement. You might like both, or one better than the other. Regardless, the obtained skill and knowledge will undoubtedly make you a better recruiter.