Katkat
Back

Design a Personalized Job Suggestions Page for LinkedIn Members

LinkedInSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

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.

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.

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.

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.

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

Hints

Hint 1

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.

Hint 2

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.

Hint 3

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.

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?