Resume Database

Why do past applicants get overlooked?

Because nothing prompts anyone to look. A new requisition creates immediate pressure to post and source, and searching existing records requires a deliberate step that no part of the process demands. The fix is procedural rather than technological: make a database search a required first action on a new requisition, with the results recorded, so that skipping it is a visible choice rather than an omission. Teams that add this step routinely find people they had already assessed and forgotten.

What should be captured at the point a record is created?

Where the person came from, what role they were considered for, what was concluded and by whom, and anything they said about what they want next. Source and outcome are what make the record searchable later in useful ways; a bare document with no context tells a future recruiter nothing about whether this person was strong, borderline, or unsuitable. Capturing it at creation costs seconds; reconstructing it later is impossible.

How should reuse be measured?

By the share of hires and of interviews that originated from an existing record rather than from a new application or a new sourcing effort. Tracking it separately from other sources shows whether the database is functioning as a channel at all. Avoid judging the database by record count, which grows automatically and says nothing, or by search volume, which can rise while yield falls.

What makes a database searchable rather than merely large?

Four things, and record count is not among them. Parsing quality determines whether experience, titles, and skills ended up in fields or stayed buried in an attachment. Deduplication determines whether one person appears once or five times under different addresses. Consistent tagging determines whether a search for a skill returns everyone who has it or only those whose document happened to spell it the way the searcher did. Recency determines whether the results are people or historical artifacts.

Organisations usually discover the state of their database when they first try to use it seriously, which is the worst moment. A cheaper approach is to test it deliberately: take a role recently filled externally, search the database for people who could have done it, and see how many the search surfaces. The gap between what the database contained and what it returned is the actual problem, and it is almost always a data quality problem rather than a volume problem.

How quickly does the data go stale?

Continuously, and unevenly. Contact details decay as people change roles and email addresses. Current employer and title go out of date the moment someone moves. Salary expectations drift with the market. Availability is the fastest-decaying field of all, since it can be wrong within days. Skills are the most durable, though a profile that lists tools from several years ago says little about what someone works with now.

The practical response is to treat every field as carrying a date rather than a value. A recruiter who knows when a record was last confirmed can judge how much to rely on it, and a search that can be filtered by last contact date lets someone choose between reach and reliability. Systems that display a profile without showing its age invite recruiters to act on information that stopped being true two years ago.

How is a database actually mined for a live role?

Not by browsing. The workable pattern starts from the requirement, translates it into two or three search strategies rather than one, and expects the first search to be wrong. Searching by title alone misses people whose employer uses a different vocabulary; searching by skill alone returns everyone who mentioned it in passing. Running both and looking at the overlap, then widening deliberately, produces a usable list faster than refining a single query.

The second half is triage. A database search returns people at every stage of relevance and every stage of staleness, so a shortlist has to be built with the record age visible. Contacting someone whose record shows they were rejected for a similar role last quarter, without knowing that, is the most common self-inflicted wound in database work, and it is entirely preventable by surfacing prior activity alongside the profile.

Your own database or purchased access?

They solve different problems. A purchased database offers breadth: people who have never encountered your organisation, which is exactly what a search for a scarce skill needs. Your own offers context: people who applied, who were interviewed, who declined an offer, who a colleague spoke to last year and rated highly. Nobody else can sell you that.

The economics differ too. External access is a recurring cost that buys reach and is competed for, since every subscriber can see the same people and many of them are contacting the same person. Your own database costs the discipline required to keep it clean and is uncontested. Most teams need both, but the sequence matters: searching your own records before paying to search someone else's is a habit that pays for itself and is skipped surprisingly often.

What obligations attach to holding this data?

Personal data held for recruitment carries duties that vary considerably by jurisdiction. The recurring themes are having a lawful basis for holding it, telling people what you hold and why, honouring requests for access, correction, or deletion, keeping it no longer than necessary for a stated purpose, and securing it appropriately. Several of these are difficult to satisfy retrospectively across a large historical store.

The specific requirements, including how long records may be kept and what candidates must be told, differ by country and sometimes by state, and they change. Set a written retention policy with counsel for each market you hold data in, implement it as an automated rule rather than an intention, and record what candidates were told at the point their data was collected. A database nobody can lawfully use is not an asset.