‼️ IMPORTANT: Please read this carefully before starting.This is a time-sensitive test. Try to complete all tasks. Each task has associated time guideline. Manage your own time.
This test was designed to be self-serve, but if you are stuck, feel free to ask us questions.
You are allowed to use internet search engines during the test, but you must disable the AI code assist.
Implement a scheduling backend for a telemedicine platform that allows doctors to manage availability, patients to book and cancel appointments, and the system to handle operational integrity, utilization tracking, and real-time rescheduling under disruptions.
Relaxed TypeScript typing is fine. Also, we left some useful imports in the respective routes for your convenience.
- Node v22+
- Express.js
- DrizzleORM
- Vitest
npm i
npm run dev # It should serve at http://localhost:3000
# But, you actually will never need to run it!
# Read on.Time guideline: 5 minutes
npm test -- task0See tests succeed. Check the routes and schemas:
src/routessrc/db/schema.ts
Also, the following has been implemented in this repo so far:
GET /doctorsGET /doctors/:doctorId/availabilityGET /patientsGET /appointments
Time guideline: 5 minutes
Find the DELETE /doctors/:doctorId/availability/:availabilityId route in code.
Implement deletion of availability.
Drizzle documentation on delete: https://orm.drizzle.team/docs/delete
For now, return HTTP 200 in any case! No response body is required.
Check your work:
npm test -- task1Time guideline: 10 minutes
Implement in the DELETE /appointments/:appointmentId route:
Find the src/utils/emailer utility. We need to send (albeit fake) notifications to both the patient and the doctor using the emailer once an appointment is deleted.
However, because the email is an external system, handle the case for emailer failure. If the appointment is deleted, but the emailer crashes, that would put the system into an inconsistent state, wouldn't it? So, rollback a delete if the emailer fails.
For now, return HTTP 200 in any case! No response body is required.
Relevant documentation:
- We are using PGLite as the database: https://pglite.dev/docs/api#transaction
- DrizzleORM
transactions: https://orm.drizzle.team/docs/transactionsjoin: https://orm.drizzle.team/docs/joins- We already implemented a sample
joinfor you insrc/routes/appointments/get-appointments.ts
- We already implemented a sample
But, most importantly, we left a pesudocode for you at src/routes/appointments/delete-appointment.ts
Check your work:
npm test -- task2
Time guideline: 10 minutes
So far so good!
Find the POST /appointments route in code and implement the following.
Book an appointment with the following payload:
{
"availabilityId": "avail12",
"patientId": "pat456",
"date": "2025-06-15",
"startTime": "09:30",
"durationMinutes": 20
}It should return the doctor's name as a response like so:
{
"name": "Jane Doe" // On error, return "Unknown doctor"
}By the way, the lazy developer who was working on this repo forgot to implement auto-generated id, so can you come up with an appropriate id when inserting an appointment row?
Do not worry about data type or format validation. We trust our frontend, today. 🙂
At this time, always return a HTTP 200 status regardless of the outcome, even in error!
Drizzle documentation on:
Watch out for the edge cases!
Check your work:
npm test -- task3
Time guideline: 25 minutes
A doctor cannot make it to the previously posted availability, but there could already be a booking in that slot.
We have to delete that availability and rebook the affected patient's appointment for another doctor or slot.
Find the DELETE /doctors/:doctorId/availability/:availabilityId route in code.
Implement proper error codes like so:
200: on success
404: if not found
500: on errorStill, no response body is required.
However, you must implement the following use-cases:
- a. Assign the patient impacted by this deletion to the next available doctor for the same time slot
- b. If there is no available doctor found in that slot, rebook the patient for any doctor's next availability
- c. However, when rebooking, prefer the current doctor (who is canceling the availability) over others if there are more than one slots available
- d. Use the
emailerto send a (albeit fake) notification to the patient about the change. Remember, being an external system, it may crash. - e. Remember
transactions? We need to ensure integrity of the system. Provide transactional safety, i.e., all-or-nothing rescheduling.
Check your work:
npm test -- task4a # Test patient rebook at the same slot with a different doctor
npm test -- task4b # Test patient rebook at a different slot
npm test -- task4c # Test preference of current doctor
npm test -- task4d # Test emailer
npm test -- task4e # Test transactions