# Design a Project-to-Contractor Matching System Design a service that matches projects with contractors. Explain the hardest data and product decisions, how candidates are generated and ranked, and how the system learns from outcomes without reinforcing historical exposure bias. ### Constraints & Assumptions - Projects describe required skills, timing, workload, location or time-zone constraints, and budget. - Contractors describe skills, availability, preferences, rate, and eligibility. - A contractor may be suitable for several projects but cannot accept unlimited concurrent work. - Both sides need explanations and may reject a recommendation. - New projects and contractors have little behavioral history. ### Clarifying Questions to Ask - Is the product recommending a ranked list, assigning work automatically, or enabling mutual choice? - Which hard constraints must never be relaxed? - What outcome defines a successful match and when is it observed? - How important are fairness, diversity, and exploration? ### Part 1 - Requirements and data model Separate hard eligibility filters from soft preferences and define project, contractor, availability, interaction, and outcome data. #### What This Part Should Cover - Explicit hard and soft constraints - Time-varying availability and capacity - Reliable skill taxonomy and evidence - Consent, privacy, and explainability ### Part 2 - Retrieval and ranking Design candidate generation, ranking, cold-start behavior, and a mechanism for mutual acceptance. #### What This Part Should Cover - High-recall retrieval before expensive ranking - Constraint-aware scores and calibration - Exploration for new participants - Capacity-aware and two-sided marketplace effects ### Part 3 - Evaluation and operations Define offline and online metrics, feedback loops, failure handling, and monitoring for bias or concentration. #### What This Part Should Cover - Match quality beyond clicks - Counterfactual or randomized evaluation - Exposure and acceptance funnels - Drift, abuse, and unfair-allocation checks ```hint Keep eligibility out of the learned score Apply nonnegotiable legal, availability, and capability constraints before ranking so a high model score cannot make an invalid match appear acceptable. ``` ### What a Strong Answer Covers - A two-sided matching contract with hard constraints and soft preferences - Retrieval, ranking, capacity, and cold-start strategies - Outcome-aware evaluation that accounts for selective exposure - Explanations, fairness checks, and operational safeguards ### Follow-up Questions 1. How would you prevent popular contractors from receiving every opportunity? 2. How would you learn when only displayed matches can be accepted or rejected? 3. What should happen if no candidate satisfies every hard constraint?