Example job post · Fictional company
Product engineer
Harbour Health
What we read
Harbour Health is a fictional health product company for interview practice. Its example software helps community clinics coordinate appointment preparation and administrative follow-up, rather than make clinical decisions. This vacancy and company are invented. We are looking for a product engineer who can connect user research with reliable delivery and recognise when a seemingly small interface choice creates extra work for busy clinic teams. Our product uses TypeScript, React and Node.js, with PostgreSQL storing workflow records. A shared design system supports accessible forms and status messages. Engineers work with a product designer and clinic coordinators, taking prototypes into short research sessions before committing to a larger build. We use synthetic patient records in development and demonstrations; operational logs exclude patient names and free-text clinical notes. You will observe how coordinators prepare appointment lists, prototype a follow-up task queue, and deliver changes across the interface and API. Responsibilities include making overdue and completed tasks clearly distinguishable, supporting keyboard-only use during busy reception shifts, and designing role-based access for coordinators and supervisors. You will preserve an audit trail when tasks change owner and provide a clear recovery path when a network interruption leaves a save uncertain. We require experience shipping a web product, comfort discussing scope with non-technical colleagues, and an ability to turn observations into testable assumptions. You should understand relational data modelling, write useful automated tests, and explain how you would measure administrative time saved without collecting sensitive content. We value thoughtful disagreement and explicit trade-offs over adding features to satisfy every request. Nice-to-haves include healthcare workflow research, accessibility testing with assistive technology, and experience rolling out software to small operational teams. Your first project would test whether a clearer follow-up queue reduces forgotten administrative tasks. You would agree success and rollback criteria with clinic coordinators, trial the change with one team, and review both completion rates and the reasons people still work around the product.Example questions
Pre-written examples. No AI is called in the demo.
- Tell us about a web product you shipped. How did you make decisions about scope and delivery?
From the post: We require experience shipping a web product, comfort discussing scope with non-technical colleagues, and an ability to turn observations into testable assumptions.
- How would you observe clinic coordinators preparing appointment lists and turn what you learn into testable assumptions?
From the post: You will observe how coordinators prepare appointment lists, prototype a follow-up task queue, and deliver changes across the interface and API.
- How would you design a follow-up task queue so overdue and completed tasks are easy to distinguish?
From the post: Responsibilities include making overdue and completed tasks clearly distinguishable
- What would you consider when making the queue usable by keyboard alone during a busy reception shift?
From the post: supporting keyboard-only use during busy reception shifts
- How would you model task ownership and preserve a useful history when a task changes owner?
From the post: You should understand relational data modelling
- A network interruption occurs while a coordinator saves a task update, and the result is uncertain. How would you design the recovery experience?
From the post: provide a clear recovery path when a network interruption leaves a save uncertain.
- How would you measure whether the follow-up queue saves administrative time without collecting sensitive information?
From the post: explain how you would measure administrative time saved without collecting sensitive content.
- How would you plan a one-team trial, including success and rollback criteria, and learn from people who continue to work around the product?
From the post: You would agree success and rollback criteria with clinic coordinators, trial the change with one team, and review both completion rates and the reasons people still work around the product.