You’ve likely already heard the recruiter database pitch; “we have millions of candidates in our extensive database, and thousands that match your specific job opening”. It was a marketing tool I was taught early on in my career, intended to create the illusion of proficiency and speed. The only problem was, at the time, I had neither. The following points are some tidbits from my personal experience with large recruiter databases.
Large recruitment companies, and occasionally the little guys too, will spend money on “resume dumps”. This means that they run programs to pull resumes off of the classic sites; Monster, Indeed, Workopolis, and yes, even LinkedIn, which are then coded and filed in their databases. They will also buy resume lists from third-party providers. The vast majority of this data is never touched, especially since resumes tend to have a “best before” date, and in an internal database it becomes difficult to separate the new from the old. This means that of those “millions” of resumes, a very small fraction has ever been contacted, and an even smaller percentage of those have been interviewed, which makes the majority of that information about as useful to filling your requirement as Google’s homepage. Which brings me to my second point:
Remember that resume “best before” date I was talking about? The good candidates - the ones who you are willing to pay a recruiter to find, typically get hired anywhere from a week to a few months after posting their resume online and initiating a job search. So all those hundreds of thousands of resumes that the company has been compiling over decades are essentially useless. The candidates’ experience has changed. Their titles, industries, companies, locations, contact information, and in some cases, their names, will have changed from the time that they posted their resume to when your recruiter stumbles across them in their database. And the most important characteristic of a job seeker; that they are actually seeking a job, is often the first thing to expire. This all means that:
If you want fast turn-around time on a search, no recruiter is wading into their massive database and sifting through the garbage as a first step. It simply takes too long. Even if we find a resume that looks promising, the chances of that candidate still being open to a new opportunity are slim, and that’s if they’re still suitable for the role. That database is reserved for long, arduous hunts where the recruiter has already tried all the faster sources; candidates who have recently been interviewed, other recruiters’ candidate lists, sourcing from job sites, posting the position online, and actually, you know, headhunting. This is especially true for niche searches where you need someone with very specific work or industry experience; no one has time to find that candidate needle in the database haystack. And just to put the icing on the cake:
This may seem obvious, but there is no broadcasted daily tally for the number of resumes in a database. Recruiters who are pitching their services are generally told to give a “rough” estimate of the size of a database, which usually errs on the side of being majestic. If you ask a recruiter how many resumes they have in their database, you will get a number that includes every single data file that company has ever pulled from the internet or third-party sources, every candidate who has ever applied to a posted position (and I’ve had Funeral Home Directors apply for Engineering positions, so let’s just say they aren’t all gems), across every single division of the organization, rounded up to the nearest hundred thousand. For a recruiter, saying that we have a massive database is like saying that we have internet access.
Large databases numbers are mostly used as a sales tool. If you want a better idea of how proficient your recruiter is, ask them how many similar positions they have personally filled in the last year. Or better yet, ask them how they’re planning on filling your requirement, and if you hear “why, with the millions of resumes in my database, of course”, you may have your answer right there.