Automating research participant recruitment and scheduling

WHAT THIS TESTS This is a workflow system design question centered on orchestrating external services dependably. The interviewer wants components, a clear data flow, a state machine for the participant lifecycle, and attention to failure modes like no-shows and webhook reliability.

A GOOD ANSWER COVERS Lay out the components. A screener and intake service collects applicants and stores responses. An eligibility and matching service filters applicants against study criteria and quotas. A scheduling service integrates a calendar API to expose researcher availability and book slots, avoiding double-booking with locking. A notification service sends confirmations and reminders via an email and SMS API. An incentive service triggers payout through a payment or gift-card API once a session is completed and verified. Model the participant as a state machine: applied, screened, eligible, scheduled, attended or no-show, paid. Data flows from intake through matching to scheduling, with events driving notifications and payouts. Address reliability: process provider webhooks idempotently, retry failed sends, handle cancellations and reschedules, and reconcile payment status. Add consent capture and audit logging.

COMMON WRONG ANSWERS Listing calendar, email, and payment APIs without a data flow or lifecycle. Ignoring no-shows, cancellations, and double-booking. Assuming external calls always succeed, with no retries or idempotency. Triggering payment before verifying attendance. Skipping consent and personal-data handling.

LIKELY FOLLOW-UPS How do you prevent double-booking the same slot. How do you make payment exactly-once despite webhook retries. How do you enforce study quotas across concurrent applicants.

ONE CONCRETE EXAMPLE An applicant submits the screener; the matching service marks them eligible and decrements the remaining quota atomically. They pick a slot; the scheduling service places a hold, books it through the calendar API, and moves the state to scheduled. The notification service sends a confirmation and a day-before reminder. After the session the researcher marks attended, which transitions to attended and enqueues an incentive; the payment API issues a gift card, and its webhook, processed idempotently by a payout ID, marks the participant paid even if the webhook fires twice.