Patient Tracker — How to Explain It in the MathWorks Managerial Round

🎙️ The Pitch — Three Levels of Detail

Level 1: 30-Second Version (When they say "give me a brief overview")

"I built a full-stack patient management system — think of it as a lightweight version of Practo or MyChart. Doctors use it to add patients, write prescriptions, and view appointment history. Patients see their daily medication schedule, mark doses as taken or missed, and book appointments. The interesting technical parts are the automated medication reminder pipeline — cron jobs at 8 AM, 1 PM, and 8 PM that email patients and auto-mark overdue doses — and the appointment booking system which uses a PostgreSQL partial unique index to prevent double-booking even under 50 concurrent requests. Stack: React, Node.js/Express, PostgreSQL with Prisma, and Socket.IO for real-time chat."

Level 2: 2-Minute Structured Version (Standard "tell me about your project")

"The problem I was solving: small clinics still manage patient medications through WhatsApp or paper. There's no structured way for a doctor to digitize the prescription → reminder → adherence tracking loop.

So I built a two-role system — a doctor dashboard and a patient dashboard sharing the same database.

What it does: A doctor adds a patient, which triggers an email invite. The patient sets their password and immediately sees their prescriptions as a daily medication schedule. The system emails reminders at 8 AM, 1 PM, and 8 PM using scheduled cron jobs, and auto-marks any missed doses after the time window expires. Appointment booking is concurrency-safe — I used a PostgreSQL partial unique index so that even if two patients try to book the same slot simultaneously, only one succeeds at the database level.

Technical stack: React 19 on the frontend, Node.js/Express backend, PostgreSQL on Neon with Prisma ORM, Socket.IO for real-time doctor-patient chat.

What I'd change: I'd extract business logic into a service layer — currently my controllers mix validation, authorization, and DB queries in one function, which makes testing hard. I'd also move the medication reminder cron to a dedicated worker process, because right now it shares a database connection pool with the API server and can cause performance issues at scale."

Level 3: Deep Technical (If they ask to go deeper — for follow-up Qs)

Refer to the architecture section below. Use the specific numbers and trade-offs.

📋 Every Managerial Question — Answered Using This Project

Q1: "Tell me about a project you made (overview)"

Use Level 2 pitch above. Remember to:

• Start with the problem (clinics use WhatsApp/paper)
• State the two-role design (doctor + patient)
• Highlight one impressive technical decision (concurrency-safe appointments)
• End with one thing you'd change (shows self-reflection)

Q2: "What difficulties did you face in the project?"

Pick 2-3 of these (the most interesting ones):

Difficulty 1 — The appointment concurrency problem (most impressive)

"The hardest problem was preventing double-booking. My first approach was to check if a slot is free in the application layer — a simple SELECT before INSERT. But I realized that under concurrent requests, two users could both pass the check simultaneously and both get a successful booking. The fix was a PostgreSQL partial unique index on (doctorId, slotStart) WHERE status <> 'cancelled'. This moves the conflict detection to the database level, so even in a race condition only one INSERT can win. I validated it by firing 50 simultaneous booking requests at the same slot and confirming exactly 1 succeeded and 49 got a conflict error."

Difficulty 2 — Making reminders fire reliably on Vercel (serverless)

"I deployed to Vercel, which kills long-running processes. Cron jobs don't survive between requests. My workaround was to also trigger the medication reminder check on every incoming HTTP request as middleware — it fires asynchronously and doesn't block the response. It's an unconventional approach — I know it's not the right production design — but it solved the immediate problem of reminders not firing in a serverless environment."

Difficulty 3 — Managing two user roles with one data layer

"Having two separate user types — doctors and patients — in one database without a common user table created complexity. JWTs needed to carry role information. Every API endpoint needed to check not just 'is this user logged in?' but 'is this user a doctor or patient, and do they own this resource?' For example, a doctor can only see prescriptions for their own assigned patients — I had to validate the doctor-patient relationship before returning any data."

Q3: "What did you learn from the project?"

Pick 2-3 lessons that show maturity:

Lesson 1 — Separation of concerns

"The biggest lesson was architectural: I mixed validation, authorization, business logic, and database queries in the same controller functions. It worked, but when I wanted to test prescription creation logic, I had to simulate an entire HTTP request. The learning: a service layer separating business logic from HTTP handling is not over-engineering — it's what makes code testable and maintainable. I'd build it differently if starting again."

Lesson 2 — Database is your last line of defense

"I used to think application-level checks were enough. The appointment booking problem taught me that whenever concurrent access matters, constraints belong in the database, not just the application. A partial unique index gave me stronger guarantees than any application-level lock I could have built."

Lesson 3 — Design decisions compound

"An early inconsistency where patients use integer IDs but doctors use UUIDs caused type coercion bugs (parseInt() vs String()) scattered throughout the codebase. A small decision at the schema level created friction in every feature built afterward. I learned to think more carefully about foundational decisions before writing feature code."

Q4: "Discuss the scalability of the project" / "What are the bottlenecks?"

"The system has three clear scaling bottlenecks:

First: The medicine search endpoint re-parses a 32MB CSV file on every request. At 50 concurrent searches, that's 1.6GB of disk reads simultaneously. The fix: import the CSV into a PostgreSQL table with a full-text search index — one-time cost, millisecond queries forever.

Second: The medication reminder cron at 8 AM runs a loop over every patient — roughly 3-4 database queries per patient. At 500 patients, that's 1,500+ queries in a single cycle, all sharing the same database connection pool with the live API. During this window, regular user requests get delayed. The fix: a dedicated worker process with a job queue like BullMQ, processing patients with bounded concurrency (say, 10 at a time) and using a separate database connection pool.

Third: The MedicineAdherence table grows by 15,000 rows/day at 1,000 patients. Without a composite index on (patientId, scheduledDate), the daily medication query does a full table scan. Fix: add that index immediately; at larger scale, partition by month.

For horizontal scaling, the API server is stateless (JWT-based), so it scales horizontally with no changes. But Socket.IO — which is currently a single in-process instance — would need a Redis adapter to work across multiple server instances."

Q5: "What improvements would you make in your project?"

"Eight specific improvements, in order of priority:

1. Express Router with grouped routes — currently app.js has 30+ individual handler imports. One router file per domain would make it navigable.
2. Service layer — separate business logic from HTTP handling for testability.
3. Dedicated cron worker — stop triggering reminders on every HTTP request; use a proper background worker.
4. Cache the medicine CSV — load once on startup or import to the database.
5. Refresh tokens — current JWT expires in 24h with no refresh; users get silently logged out.
6. Input validation library — Zod or Joi instead of scattered if (!field) checks.
7. WebSocket namespaces — separate chat and medication notification channels.
8. Standardized error format — currently inconsistent between { message } and { error }.

The one I'd prioritize first is the service layer — it unlocks everything else, including testing."

Q6: "Verification of numbers/metrics on your resume"

These are the specific, provable numbers — know them cold:

[!CAUTION] Don't make up numbers. If you're asked about a metric you're not sure about, say: "I'd have to check the code to give you the exact number, but the design decision behind it was..." Then pivot to the reasoning.

Q7: "Do you prefer to work in a team or individually?"

Use this project as context:

"This was an individual project, so I made all design decisions myself — which was valuable because I felt the full consequence of every trade-off. For example, the inconsistency in ID types (integers vs UUIDs) between patient and doctor models — I noticed it too late because there was no one to catch it in a design review.

That experience actually reinforced why I value teamwork. In a team, someone would have caught that in a code review before it propagated through the codebase. I prefer working in a team for design and architecture phases — where diverse perspectives catch blind spots — and independently for focused implementation work. At MathWorks, the design review culture you practice resonates with me for exactly this reason."

Q8: "What opportunity did you take initiative on?"

"The appointment concurrency problem. When I first built the booking system, it had the standard application-level check — SELECT to see if a slot is free, then INSERT if not. I knew this was technically a race condition, but it works fine in single-user testing. I took the initiative to actually test it under concurrent load by writing a script that fires 50 simultaneous booking requests.

That test revealed the race condition — I got multiple successful bookings for the same slot. That led me to research database-level concurrency solutions, which led me to PostgreSQL partial unique indexes. I could have shipped the 'good enough' version — most people don't bother stress-testing solo projects — but I wanted the system to actually work correctly, not just appear to work in demos."

Q9: "What criticism did you receive / what went wrong?"

(Self-reflective answer using your own retrospective)

"The biggest criticism — which I give myself — is the lack of a service layer. A senior engineer reviewing this code would immediately flag that route handlers are doing too much: they validate inputs, check authorization, run business logic, and call the database, all in one function. That makes each handler untestable in isolation and makes the code hard to reason about as it grows.

A second criticism: I fire medication reminders as middleware on every HTTP request. It solves the Vercel serverless problem pragmatically, but it's unconventional and would confuse anyone reading the code. The 'right' solution — a proper background worker — should have been the first approach, not the fallback."

Q10: "Learnings from your project / internship"

(Use if this was an internship or a major personal project)

"Three things:

First: Foundational decisions matter more than feature decisions. The database schema inconsistency (integer vs UUID IDs) caused bugs in every subsequent feature. I'd spend more time on the schema before writing any handlers.

Second: Test the edge cases you don't expect to hit. The concurrent booking test was something I almost skipped. It revealed a real correctness bug that would have affected real users.

Third: Architecture for testability from day one. I built everything working and none of it unit-testable. Adding tests to the current codebase means rewriting it — the service layer should have been there from the start."

🔗 Connecting Project Decisions to MathWorks Core Values

Use this when they ask "Why MathWorks?" or any values-related question:

⚡ Quick Reference Cheat Sheet