Katkat
Back

Reduce Stale Listings in a Job Marketplace

LinkedInSoftware Engineer · Technical Screen
HardSoftware EngineerTechnical ScreenSystem Design

Last updated

Design an auditable staleness-detection and remediation engine for a global job marketplace that aggregates heterogeneous signals, enforces graduated interventions, and supports low-latency employer appeals.

Scenario

In a massive job marketplace like LinkedIn, employers frequently leave open listings long after positions have been filled or abandoned. Stale listings degrade job seeker trust, inflate search noise, and waste candidate effort.

You need to design an automated, auditable staleness management platform that aggregates heterogeneous signals, evaluates listing freshness, executes graduated enforcement actions (e.g., rank penalties, notifications, unlisting), and provides a low-latency reversal/appeals path for employers.

Requirements

Functional Requirements

  • Multi-Source Signal Ingestion: Ingest asynchronous signals from candidate interactions (reports of "role filled", unresponsive messages), recruiter activity telemetry (last login, application review frequency), external ATS syncing, and web-crawled career page statuses.
  • Staleness Scoring & Policy Engine: Combine discrete events and continuous time-decay metrics into a staleness score, driving graduated lifecycle transitions: Active -> Downranked -> Soft-Hidden (accessible only via direct link) -> Closed.
  • Reversibility & Appeals: Employers can contest staleness actions (e.g., via email prompt or recruiter dashboard button "Still Hiring"), immediately restoring the listing to its previous good standing.
  • Auditability & Explainability: Maintain an immutable audit log detailing why a listing was flagged, which signals contributed, actions taken, and employer remediation events.

Non-Functional Requirements

  • Scale: Support 50 million active listings, with up to 2 billion historical listings. Handle 150 million daily candidate/recruiter events.
  • Latency: Employer appeals must restore searchability in under 2 seconds. Graduated state transitions should propagate across search and recommendation indexes within 5 minutes.
  • Fault Tolerance: Prevent false-positive mass deactivations due to upstream crawl or telemetry outages.

What Your Design Should Cover

  1. High-Level Architecture: Signal ingestion pipelines, processing layer (stream vs. batch), staleness state machine, and index synchronization.
  2. Data Model & State Machine: State transitions, audit log schema, and storage selection for time-series signals versus current state.
  3. API Design: Core endpoints for signal ingestion, employer appeals, and administrative audit inspection.
  4. Trade-offs & Resilience: Circuit breakers for anomaly detection (avoiding bulk unlisting), handling conflicting signals, and index update strategies.

Hints

Hint 1

Separate the signal aggregation pipeline from the enforcement state machine so stale scores can be re-evaluated without directly coupled side-effects.

Hint 2

Model listing lifecycle interventions as an explicit finite state machine (FSM) backed by an append-only event ledger to ensure complete auditability and clean rollbacks.

Hint 3

Use circuit breakers and rate limits on automated demotions to guard against faulty external crawlers or coordinated candidate reporting attacks.

Follow-up questions

  • How would you differentiate between legitimately slow-to-hire roles (e.g., executive or specialized engineering positions) and genuinely abandoned job posts?
  • If a scraping job reports 404 on an employer career site, how do you prevent transient network or DOM changes from immediately hiding hundreds of company jobs?
  • How would you structure the search index updates so that appeal reversals become visible within 2 seconds without triggering costly full document reindexes?