Design the job recommendation system for LinkedIn Jobs. When a member visits the Jobs page or receives a job alert email, the system must rank open positions from a catalog of millions by how likely the member is to apply and, ultimately, to get hired.
The ranking must respect hard constraints (location, work authorization, years of experience, salary expectations), handle the cold-start problem for new members and newly posted jobs, and avoid recommending jobs the member has already seen or dismissed. LinkedIn’s two-sided marketplace means the system also affects employers, who pay for applications and churn if candidate quality is poor.
How would you design this system? Cover the candidate generation and ranking funnel, the feature set (member profile, job requirements, interaction history), how you handle cold start, the online and offline metrics, and how you balance member and employer value.
The Problem: one member with hard eligibility constraints, millions of open postings, and a recruiter on the other side who pays for applications and leaves if the applicants are unqualified.
Answer
The design is a standard four-stage recommender funnel wrapped around a two-sided objective: hard-constraint filtering, multi-source candidate generation down to roughly a thousand jobs, a multi-task ranker, then a policy re-rank layer that enforces marketplace and compliance rules. The pivotal design decision is what the ranker optimizes. Optimizing apply probability alone maximizes member clicks and floods a few popular postings with unqualified applications, so the score blends P(apply), P(recruiter treats the application as qualified), and a delayed P(hire) head, which is the objective LinkedIn’s own confirmed-hires framing points at. The second pivotal decision is to treat eligibility as a pre-filter in the retrieval index rather than a learned soft feature, because a job the member cannot legally take is a wasted slot for both sides.
(1) Hard Constraints As Pre-Filters: location radius or remote flag, work authorization, seniority window, and compensation band are boolean index filters applied before scoring, never soft features the ranker can trade away.
(2) Multi-Source Candidate Generation: a two-tower ANN over job embeddings, plus saved searches and alerts, plus graph sources (“members with your title applied here”) and company affinity, unioned to about 1000 candidates.
(3) Multi-Task Ranker: one shared-bottom or MMoE model with heads for apply, qualified-application, and confirmed hire; the serving score is a weighted combination whose weights are the marketplace policy knob.
(4) Cold Start By Content Plus Exploration: both towers are content-based (title, extracted skills, seniority, company), so new members and postings get vectors immediately, and new postings receive a small guaranteed impression budget.
(5) Policy Re-Rank Layer: deduplicate seen and dismissed jobs, cap applicant load per posting, spread traffic beyond the head of the catalog, and apply fairness-aware re-ranking.
(6) Two Serving Paths: the Jobs page runs the funnel online under a ~200 ms budget; alert emails run the same models in a nightly batch with frequency caps and a higher score threshold.
Figure 1: The funnel narrows 20M postings to 25 shown jobs, and the loop back through label joining is what turns applies, recruiter replies, and hires into tomorrow’s model.
Clarify Before Designing:
(1) Surface And Budget: Jobs page (online, latency-bound) or alert email (batch, frequency-bound), and what end-to-end latency budget does the page allow?
(2) Label Availability: do we have recruiter-side signals (application viewed, candidate contacted) and confirmed hires, or only member-side clicks and applies?
(3) Catalog Scale And Freshness: how many open postings, what is the median posting lifetime, and how quickly must closed jobs disappear?
(4) Monetization: are promoted or sponsored jobs blended into the same slots, and is there a separate auction and pacing layer?
(5) Compliance: which fairness and audit requirements apply (employment discrimination law, automated hiring-tool bias audits), and which member attributes are forbidden as features?
(6) Employer Capacity: do postings expose applicant caps or response-time signals we can use to protect candidate quality?
Leave a Reply