Candidate Discovery.
A cross-opening search surface that turns a dormant candidate database into the team's fastest source of hires — without ever leaking what happened to a candidate inside another team's private pipeline.
At a glance.
"The gap I caught: inclusion filters alone can't express 'everyone except rejected and joined.' So I added a dedicated exclusion layer."
What it is, why it exists.
Recruiters at HireBound were sitting on a goldmine they couldn't use. Every past search, every sourced profile, every candidate who came close on another role lived somewhere in the system — but there was no way to search across all of it. A separate "Discover Candidates (Beta)" page existed, but it was thin: a search bar and a handful of filters, disconnected from the openings where the work actually happens.
Candidate Discovery turned that into a real capability: a cross-opening search surface that lets a recruiter query the entire candidate universe, rank results by genuine fit, and pull the right person straight into a live opening — all without ever exposing what happened to that candidate inside another team's private pipeline.
The hard part was never the search box. It was drawing the line between what's global about a candidate (skills, experience, availability, CTC) and what's private to an opening (feedback, notes, stage history, offered CTC) — and enforcing that line in the interface, not just the database.
Objectives and phased delivery.
- Make the existing talent pool discoverable, trustworthy, and actionable.
- Treat data separation as a first-class design constraint, not an afterthought.
- Ship value early by respecting the existing beta — each phase de-risks the next.
Phase 1 — Enhance the beta
- Rebuilt the beta into a three-panel workspace: quick search, a full filter rail (skills, experience range, location, availability, notice period, expected CTC), and ranked result cards.
- Introduced the v1 match score and the include/exclude stage filters.
- Respected the existing foundation — faster delivery, no wasted work.
Phase 2 — Wire into openings
- Add a "Discover" tab inside each opening so recruiters can search the global pool in the context of a specific role.
- Double-booking warning fires before a candidate active elsewhere is added to a new pipeline.
Phase 3 — Reverse the lens
- Flip the model on the candidate profile: a "Find Jobs" tab that surfaces the openings a given candidate fits best.
- Turn the same match engine into a two-way street.
What we learned, card by card.
Recruiter Workflow Audit
Watched how recruiters actually re-find candidates today, and where they gave up.
The pain wasn't "I can't search," it was "I can't search across everything at once," and "I can't easily filter out the people I've already ruled out."
Directly shaped the exclusion-filter decision — a dedicated exclude layer alongside inclusion filters.
Data-Separation Constraints
Mapped every candidate field into global vs. opening-specific.
Exposing another opening's notes or offered CTC in a global view would be a genuine privacy breach between teams.
Designed the discovery response to return global fields only, with pipeline data reduced to aggregate counts.
Competitor Discovery UX
Studied how sourcing tools like Juicebox and Gem present results.
Most return a raw boolean list the recruiter still has to read and rank manually.
Led with a ranked, explainable match score — the interface does the first pass of judgement, not the human.
Match-Criteria Weighting
Pressure-tested what "fit" really means for Indian recruiting.
Skills and experience are the real signal; location and availability are practical gates; CTC is a soft factor, not a binary one.
Landed on the weighted model: Skills 40 / Experience 30 / Location 15 / Availability 10 / CTC 5.
How it came together.
A three-panel workspace built on the existing beta — quick search, a full filter rail, and ranked result cards — with data separation and double-booking prevention wired in as first-class design constraints.
- Left rail: filters across skills, experience range, location, availability, notice period, expected CTC.
- Center: ranked result cards leading with match score and explainability.
- Include and Exclude stage filters as peer controls, not a hidden toggle.
- Skills + Experience carry the majority weight because they are the real signal.
- Location and Availability act as practical gates.
- CTC is a soft factor, not a binary reject.
- Same engine designed to power reverse candidate-to-job matching in Phase 3.
- Every candidate field mapped as global or opening-specific before build.
- Discovery response returns global fields only.
- Pipeline activity in other openings reduced to aggregate counts, never detail.
- Fires at the moment of add, inside the opening context.
- Aggregated pipeline summary gives context without leaking detail.
- Global candidate index → discovery query → ranked results (global fields + aggregate pipeline counts).
- Opening context → "Discover" tab → same query, scoped add-to-pipeline with double-booking guardrail.
- Candidate profile → "Find Jobs" tab (Phase 3) → reversed match against open requisitions.
Contribution and business outcomes.
Framed data separation as a design principle
Defined the global-vs-opening boundary and enforced it in the UI, not just the schema.
Caught the exclusion-filter gap before build
Inclusion filters alone couldn't express the most common recruiter query, so I specified a dedicated exclude layer.
Designed the v1 match algorithm
Weighted the model and its rationale, turning a raw result list into a ranked, defensible shortlist.
Scoped the 3-phase rollout
Built on the existing beta so value shipped fast and each phase de-risked the next.
Specified the double-booking guardrail
Plus the aggregated pipeline summary that gives context without leaking detail.
Unlocked the existing talent pool as a reusable asset — recovering candidates the team already paid to source, instead of re-sourcing from scratch.
Protected the platform from a cross-team data leak — a trust and compliance win with zero incidents by design.
Laid the match-engine foundation reused later for candidate-to-job matching — one investment, two products.
Learned, improved, next.
Discovery didn't just add a search box — it turned a dormant database into the team's fastest source of hires. The lasting win was the discipline underneath it: a clear line between what's shared and what's private, drawn once at design time and honored everywhere the feature touches.
Ship the double-booking guardrail and aggregate pipeline summary in Phase 1 rather than Phase 2 — recruiters immediately asked for context when a candidate showed up in results, and the guardrail is the natural answer.
Phase 2 wires Discovery into every opening; Phase 3 flips the lens on the candidate profile — turning the same match engine into a two-way street between candidates and jobs.