Harbor Health interview

Your concrete performance result and API-contract testing held their interest; you lost ground when asked what you personally did to resolve a disagreement. Prepare to explain your role in that conflict, sharpen interval-boundary reasoning, and expect an answer from Ben early next week.

Study roadmap

1. State interval boundaries and test edge cases before coding. Drill by saying whether touching endpoints overlap, then test back-to-back slots, invalid ranges, and empty input. At 04:44–05:21, the inclusive comparisons incorrectly rejected a slot starting exactly when an appointment ended.
2. Make your actions explicit in conflict stories. Practise a concise situation–action–result account, naming what you did and the outcome. At 07:21–08:08, you described changing APIs and raising the issue in standup, but could not say how you addressed it or what changed through your actions.
3. Back experience claims with outcomes and scope. Prepare the baseline, result, timeframe, and your contribution for each story. Your reports-page result had those details at 01:09; your contract-testing result at 08:31 had an outcome and timeframe, but “zero breakages” was qualified as “like three months.”
4. Turn interviewer scenarios into explicit requirements. When a detail changes the logic, clarify the rule and state how it affects your solution. At 06:30–07:06, Lucia introduced a provider-specific ten-minute buffer; you proposed extending existing appointment ends, then asked whether the buffer was per clinic.

Where they dug longest

• Endpoint overlap and back-to-back bookings: Lucia asked you to walk through 09:00–09:30 followed by 09:30–10:00 (04:44). You caught the false rejection yourself, then changed the comparisons to strict inequalities.
• Your part in a workplace disagreement: Ben followed up twice—first asking what you did, then how it ended with the person (07:45, 08:01). You said you raised it in standup and that it became a “team thing”; you did not explain your own contribution or the outcome beyond getting along.
• Ways to catch API breakage: Lucia asked how you would detect the same kind of API change problem before users found it (08:19). You answered with your contract-testing example and mentioned end-to-end tests as an alternative.

Expect these same points in the next round.

Strengths and weaknesses

Strengths

• At 01:09, you gave a specific performance result: the reports page went from 6.2 to 1.8 seconds after you virtualized the table and split the chart bundle; you said you did it yourself over two sprints.
• At 02:26, you clarified whether appointment times came in the clinic’s timezone or UTC before coding; Lucia specified clinic-timezone Date objects.
• At 08:31, you connected your contract-testing experience to Harbor Health’s API-breakage problem, gave a three-month outcome, and said the backend lead extended the setup to two other teams.
• At 09:34, you asked about the frequency and cause of double bookings. Lucia’s answer revealed both the backend race condition and the frontend stale-availability issue.

Weaknesses

• At 02:45–05:21, your initial overlap comparisons treated touching endpoints as conflicts. Use strict inequalities for back-to-back appointments, and test that case before presenting the solution.
• At 07:21–08:08, your disagreement story lacked a clear personal action and result. Replace “we talked about it” with what you did and what changed.
• At 08:31, “zero breakages for like three months” was less precise than your reports-page result at 01:09, which included exact before-and-after timings and your role. Prepare precise timeframes and scope for the contract-testing story.

Your weakest answer, rewritten

Question: Tell me about a time you disagreed with someone at work.
Your answer: The backend team kept changing the policies API; you raised it in standup, and things got better as a team.
Could have sounded like: “The backend team’s changes to the policies API kept breaking our pages. I wrote contract tests against their OpenAPI file so our build would fail if a field we used was renamed or became optional. We had zero breakages for about three months, and the backend lead set the tests up for two other teams.”
Borrowed from: Your disagreement answer at 07:21–08:08 and your contract-testing example at 08:31.

The interview by time

Your strongest segment was the introduction: you gave a clear before-and-after result, your actions, and the timeframe.

Your questions

• How often do double bookings happen, and is the frontend or backend responsible? Lucia said there are a few dozen per week across clinics, mostly due to two front-desk staff booking the same slot at once; the backend needs a lock, while stale frontend availability worsens the problem.
• What would the first project be? Ben said it would probably be the availability view, making sure front-desk staff see fresh information.
• How is the team split between frontend and backend? Ben said there are six engineers, two frontend-leaning; you would be the third.
• Worth asking next: Given the race condition Lucia described and the likely availability-view project Ben named, ask how that work is divided between the backend locking fix and frontend freshness.

Follow-up email

Draft — check before sending

Hi Ben and Lucia,
Thanks for speaking with me; I enjoyed discussing the availability view and the stale availability that can worsen booking races.
My contract tests caught policy API changes before they broke pages; we had zero breakages for about three months, and the backend lead extended the setup to two other teams.
Best, Maya