Katkat
Back

Design a Project-to-Contractor Matching System

MercorSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

Tests your ability to architect a two-sided matching platform that enforces strict eligibility filters, dynamic availability tracking, multi-stage ranking with exploration, and closed-loop model evaluation.

Scenario

You are tasked with designing the core matching engine for a talent platform that connects technical projects with pre-vetted contractors. When a company posts a project (or a recruiter searches for candidates), the platform must recommend top-matching contractors who are available, eligible, and likely to succeed.

Requirements

Functional Requirements

  1. Hard Filtering: Filter contractors based on rigid criteria such as minimum timezone overlap, rate range, legal work authorization, and required skills.
  2. Capacity-Aware Ranking: Score and rank remaining candidates based on profile relevance, previous performance, and current workload/capacity (avoid recommending contractors already overcommitted).
  3. Cold-Start Exploration: Incorporate newly onboarded contractors who lack historical client feedback without degrading client match quality.
  4. Outcome-Based Feedback: Track downstream outcomes (client invited, interview passed, contract signed, client review score) to update model weights and contractor scores.

Non-Functional Requirements & Scale

  • Scale: 100,000 active contractors; 10,000 active open projects; 500 new projects created daily.
  • Latency: Query-time candidate recommendations must return in under 300 ms (p95).
  • Consistency: Contractor availability updates (e.g., contractor accepts another contract) should propagate to the matching engine within 10 seconds.

What Your Design Should Cover

  • High-Level Architecture: Key services, data storage, and message queues.
  • Matching Pipeline: Multi-stage retrieval and ranking (Candidate Generation -> Hard Filtering -> Scoring -> Capacity Adjustment & Exploration -> Top-K Selection).
  • Data Model: Core entities (Contractor, Project, Application/Match, FeedbackEvent).
  • Cold-Start & Feedback Loop: Strategy for exploring unproven talent and incorporating offline/online feedback to update ranking signals.

Hints

Hint 1

Separate the matching pipeline into an inverted index or vector retrieval phase for candidate generation, followed by strict attribute filtering and fine-grained ranking.

Hint 2

Model contractor capacity as a dynamic budget that decrements upon interview holds or contract signings, using an in-memory cache like Redis for low-latency checks.

Hint 3

Address cold-start candidates using an epsilon-greedy or multi-armed bandit exploration bucket, reserving a small fixed percentage of top recommendation slots for high-potential new talent.

Follow-up questions

  • How would you prevent popular contractors from being spammed with invitations while preventing starvation for lesser-known candidates?
  • How do you handle delayed feedback signals, such as client ratings that arrive 3 months after a project completes?
  • If a client refines their search criteria in real time, how can you optimize query caching while maintaining dynamic capacity constraints?