Design a Personalized Job Suggestions Page for LinkedIn Members
Company: LinkedIn
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Onsite
Design the job suggestions page on LinkedIn: when a signed-in member opens it, they see a ranked, scrollable list of open job postings chosen for them. You own the system end to end, from where candidate jobs come from, through filtering and ranking, to serving the page quickly and learning from what members do on it.
### Constraints and Clarifications
The prompt named only the page, so treat these as assumptions:
- Members have profiles with a current title, skills, experience and location, and may set job preferences such as desired titles, locations or remote work.
- Employers post jobs that remain open until they are filled, closed or expire.
- For each suggestion a member can open it, save it, apply, or dismiss it.
- The page loads in batches as the member scrolls.
### Clarifying Questions
- What should the suggestions optimize for: clicks, applications, or applications that employers actually respond to?
- How fresh must the list be: should a job posted a few minutes ago be eligible right away, and how quickly must a closed job disappear?
- Are member preferences such as location or remote work hard filters, or only ranking signals?
- Is the same list reused for email or push digests, or is this page the only consumer?
- Roughly how many members open the page each day, and how many jobs are open at once?
### Part 1 — Requirements and the page API
State the functional and non-functional requirements, a rough estimate of scale, and the API the client uses to load the page, scroll through it, and report what the member does.
```hint Pin down the scrolling contract
Decide what a stable list means when the ranking behind it can change between requests, and what the client must send back so the system can learn from the page.
```
#### What This Part Should Cover
- Functional scope plus latency and freshness targets
- Back-of-the-envelope estimates for page loads, job volume and event logging
- A paginated read API that stays consistent while scrolling, and an API for member actions
### Part 2 — Producing the ranked list
Explain how the system narrows millions of open jobs to the few dozen this member sees: where candidates come from, which filters apply, how candidates are scored, and how the final page is assembled.
```hint Think in stages
Scoring every open job on every request is too expensive. Consider a sequence of stages, each cutting the set down with progressively more expensive logic.
```
#### What This Part Should Cover
- Several candidate sources and what each contributes
- Hard filters that must never be violated
- A ranking stage and the features that capture member-job fit
- Final re-ranking for diversity and business rules
### Part 3 — Freshness, feedback and scale
Show how new and closed jobs reach the page quickly, how member actions flow back into ranking, and how the system scales and degrades gracefully when a component fails.
```hint Two speeds of change
Job postings change within minutes while models and most profile data change more slowly. Decide which parts must react in near real time and which can run in batch.
```
#### What This Part Should Cover
- Near-real-time handling of new, edited and closed postings
- Logging impressions and actions and turning them into training labels and online signals
- Precomputation versus online work, caching, and fallbacks when dependencies fail
- Production metrics and how ranking changes are tested
### What a Strong Answer Covers
- Clarifies the optimization goal and freshness needs before designing
- Uses a multi-stage retrieval and ranking funnel with an explicit latency budget
- Enforces hard filters at serve time so closed, applied or dismissed jobs never appear
- Closes the loop from impressions and actions to features and model training, accounting for delayed labels and position bias
- Plans graceful degradation and observability for both system health and suggestion quality
### Follow-up Questions
- A member just signed up with an almost empty profile. What do they see, and how quickly does it improve?
- A job was posted a minute ago and has no engagement data. How does it get a fair chance to be shown?
- One large employer posts thousands of similar roles. How do you keep it from dominating everyone's page?
- How would you roll out a new ranking model and decide whether it is better?
Overview: Design the LinkedIn page that suggests open jobs to a signed-in member, from candidate retrieval and filtering to ranking, pagination and serving. Tests large-scale recommendation architecture, freshness for new and closed postings, feedback logging, latency budgets and graceful degradation.
Read the full LinkedIn Software Engineer interview experience this question came from
Community answers
Answer by nabajyoti.techfest
Writes. Job creates, updates, and closes land in Postgres. CDC publishes them through Kafka into Elasticsearch within a few seconds. Saves, dismissals, hides, views, searches, and applies are stored on that member.
Candidates. A GET runs two parallel Elasticsearch queries for the active filters: about 250 newest jobs, and about 250 by this member’s title and skills. Results are deduped, with at most 3 jobs per company.
Filter bubble. When recent views sit in one function, a third parallel query fetches about 100 jobs outside that function, using their latest search when they have one. The other two queries shrink so the merged set is still at most 500.
Ranking. Feedback is read from the Postgres primary, so a dismiss or hide is on the next page. The ranker scores the surviving jobs with the profile, saves, and recent activity.
Page. Twenty slots come from that ranking. Five come from the highest-scored jobs in a different function. Any of those 25 that the primary marks closed are dropped.
Cold start. A profile with no job activity still uses title and skills. With no title, skills, or location, the page is the newest jobs, a few per function.
Failure. If the third query returns nothing, show fewer than 5 of those slots. If the ranker is down, return the newest jobs that passed the filters and feedback. If Elasticsearch is down, return the newest open jobs from Postgres.
Why it holds. The ranker never sees the 20 million jobs, so the read stays inside 150 ms at about 5–10k pe