Behavioral Interview Prep

I’m prepping for my behavioral interview questions and thought it couldn’t hurt to publish them for future reference or to share around.

Tell me about yourself.

My digital health software engineering arc really started back in highschool, when I developed the hardware and neural networks to record and classify EKG waveforms, such as tachycardias, bradycardias, escape, and premature beats, etc. I was fascinated by the potential of already existing data, that you could have a positive impact on health by simply recognizing and extracting the patterns which already existed. That interest carried me to MIT where I majored in Brain and Cognitive Science to support a career at the intersection of healthcare and software.

More recently, in 2017 I co-founded Regard where, after a year of customer research, we decided to develop AI copilot to help physicians write their clinical notes. For context, clinical notes play a doubly critical role in healthcare: beyond communication between healthcare practitioners, clinical notes are the source of truth for healthcare provider reimbursement. Hospital billing departments employ teams of coders to translate clinical notes into billing codes which can then be submitted to health insurers. If something isn’t in the note or if it’s underdocumented it can’t be billed for. The burden of documentation falls on physicians, and there’s often tension between clinical care, reimbursement, and physician time constraints. Recognizing this, we built an application which physicians could use via their EMR: it fetched patient data, diagnosed common conditions from that data, and then provided up-to-date documentation that the physician could build off of.

I was the technical co-founder, responsible initially for working as an IC to build the software, operations, and cloud infrastructure. I set the technical direction, e.g. using SMART on FHIR for hospital integrations, building on AWS, etc. and worked with hospital IT teams to integrate with their EMR. As Regard moved through its lifecycle as a company my role also progressed, from an IC to an Engineering Manager to a CTO managing managers. Along that path I grew the company’s engineering practices, worked as hiring manager for various technical roles, helped design scalable systems, and worked with vendors where appropriate to out-source solutions like error management. To keep patient data secure and up to regulatory standards we developed a HIPAA compliant solution and had a SOC2 audit of our stack. In 2023 I buit chatbot into our application so physicians could ask it questions about their patient.

After seven years, I stepped back to focus on IC work and acute family health needs. My most recent work was with NeuroFlow, a digital health company that presents patients with surveys on physician request. My role was to help develop a routing layer where messages could be sent bidirectionally between the NeuroFlow application and the EMR via Redox. This work kept me sharp while giving me flexibility.

I’m now looking for a full-time IC role—ideally one where I can bring my experience building compliant, scalable healthcare systems to bear at greater scale, especially where generative AI is in play.

Tell me about a time you led a project from idea to production.

I was the technical co-founder at Regard where I built the prototype and then grew a team to develop it into a robust product hospitals would pay for. By the end of my tenure we had millions of dollars in yearly revenue from hospital clients, and physicians were using Regard to write thousands of notes per day. Before we reached that point, though, I started with customer research. We spent nearly a year identifying a problem and solution we could tackle, finally settling on note writing during the Cedars-Sinai Techstars Accelerator. Regard’s application was a single-page EMR-embedded webapp that helped physicians write clinical notes from EMR data. This frontend was the tip of the technical iceberg, and was supported by a Python backend integrated with the EMR via SMART on FHIR, a HIPAA compliant cloud stack, continuous integration so changes could be made confidently.

Getting the application fully robust and in clients’ hands took staging: we couldn’t get clients without a proof-of-concept, and couldn’t build the complete MVP without client data or an integration. To solve this, I implemented a demo version of the application that operated on static patient data and worked with hospital IT teams to transfer that data securely to our servers. This demo gave a compelling sales tool that we used to bootstrap our first clinical development partners and establish the real-time SMART on FHIR the MVP required.

The final challenge was going from one developer (me) plus contractors to a several person engineering team that could grow the initial production app into a robust product with wide clinical coverage. That took money: we raised a seed round using the proof of revenue and daily active physician users. I was the tech guy in the room, fielding technical questions and explaining how we navigated the complexity of hospital IT. And, while it wasn’t easy, the money did come. I then served as hiring manager: crafting a compelling job description, designing technical interview questions, and managing our candidate pipeline. We got some great hires, people who stayed with Regard or are now working at places like Google Quantum, Bytedance, NeuroFlow, and Homebound. I served as engineering manager to establish workflows and best practices, and together we built the product into something hospitals wanted to pay for, fetching complete clinical records and serving documentation within a minute of first-patient-load (please ask me why that load time is impressive)

Tell me about a time you influenced without authority.

One of my earliest examples of influencing without authority was during my first full-time engineering role at Runway20. It was an early stage startup working on a mobile personal assistant application and I was a fresh-out-of-college engineer, laser focused on implementing the backend. However, I noticed our CEO-led product direction was thrashing. The initial MVP was similar to today’s Google Assistant: it ran in the background and monitored user information, e.g. emails and location, surfacing relevant information to the user. However, it suffered from the coldstart problem: the app took time and resources to start providing user value. The CEO thought the solution was to baking the intelligent features into an email application. For context, this was back before Gmail had intelligent features, things like showing travel information for an upcoming flight, asking if you want to include an event in your calendar, or including package tracking information – we were trying to build our own email client that supported those affordances on top of emails.

However, the pivot set off alarm-bells in the back of my head. Not because I thought it was a bad idea, per-say, but it because came out of internal brainstorming and an urge to “solve our own problems” without wider market validation. Building an email client represented significant investment, and it wasn’t clear to me that it would be compelling to the general consumer. So, I got permission to do some extracurricular user-research, put together a survey, and headed down to the Palo Alto Caltrain station. I interviewed a handful of people waiting for the train on what their current email usage looked like: what was critical for them in an email client and what was compelling in our MVP’s feature-set. The majority of the people I talked with were using an email client that integrated with their work stack, and beyond simply handling emails the common critical need was scheduling. Most of the features we were proposing didn’t move the needle for them, and were easily satisfied by dedicated apps a tap away.

I shared this information with the team, and, after validating it we changed some of our build priorities: instead of building out a grab-bag of features we focused on scheduling and integration with existing clients. While at the end of the day Runway 20 wasn’t a successful startup, I credit my skepticism and willingness to listen to users with changing how product was prioritized and built. And, for me personally, the most salient lesson was to listen to your users. They may ask for a faster horse, but if you can’t successfully pitch your dream of a car to them you should check where your dream falls short.

Describe a time when you made a high-stakes technical decision.

At Regard we needed a source of real-time patient data so that we could create an up-to-date clinical note for physicians. This was high-stakes because the technology determines how long it takes to integrate with a hospital client and if the client’s IT is even willing to commit resources.

When tasked with figuring this out, I first took a step back and asked whether this was even necessary? It’s much simpler to get regular data-dumps at some regular cadence. But real-time data was a hard requirement of the MVP: a healthcare environment constantly has new data coming in from vitals, labs, consults etc. One critical data point can form or disprove entire diagnosis.

I set to figuring out how to get the data in real-time by talking with hospital IT and researching the options EMR provide. Traditionally, there are a few options. The first are EMR specific APIs, like those offered by AthenaHealth. While they satisfied the real-time requirement these API’s weren’t portable and they didn’t provide complete coverage of the data which we needed. Further, the market-leading EMR’s like Cerner or Epic didn’t provide custom APIs, making it a non-starter. Then there was the most popular option for real-time integration, HL7. I discovered from speaking with hospital IT, however, that HL7 integrations are expensive from a man-hour perspective: they require the hospital to specify exactly what data gets sent and we’d need a to support a downstream system that never dropped messages. It was high-effort and brittle.

Instead, I recommended a relatively new technology: SMART on FHIR. It’s a RESTful API standard developed by the same group behind HL7, but designed for modern clinical data exchange. It had the benefits of support across all popular EMRs, a modern implementation with OAuth2 for authentication and JSON for data transfer, and, most importantly, hospital IT was excited to use it vs HL7.

Of course, there were tradeoffs. First was latency, as a pull rather than push-based technology there was latency between receiving the signal that a physician was interested in a patient and then making the requests to pull down the data. Second was that it required approval from the EMRs. But, we were able to successfully navigate those issues and deliver an effective experience for physicians. In retrospect, this decision enabled us to quickly rollout to new clients. We avoided getting bogged down in a per-hospital IT negotiation, and could instead focus on our physician users.

Describe a major technical challenge or failure and how you handled it.

One major technical mistep I took was building a prototype that was impossible to run in production while at Regard. I was developing a demo to showcase the vision we had for our phsyician-facing app: we wanted to present the physician with an automatically generated clinical note and let them make changes as necessary. Given the quality of off-the-shelf rich-text-editors it was straightforward to embed a rich-text-editor so physicians could make edits within our application.

The demo would be used as a sales tool helping to convince customers to sign on. Once onboarded, we could then integrate with their EMR and embed the prototype into their stack. The first part of the plan worked well, and we were able to bootstrap a few excited initital clients. However, things broke down when we tried to run the application embedded within their EMR because both Cerner and Epic ran an ancient Internet Explorer 5 web component. Not only did I have to retrofit our application to work in such a dated environment, but the more advanced rich-text editing relied on API’s which didn’t exist in IE5. The solution was to work with our early clients to redefine the MVP and workflow (they could still edit notes, but it had to be in the EMR’s editor) and to strip out the rich-text-editor.

Later, I was able to tackle the issue more methodically: by then we then had dedicated front-end engineers, and I assigned them to work on the problem full-time. We found an old branch of a rich text-editing component that did work in the EMR’s web-component, and I worked with the team to install local Windows VM’s that could run Internet Explorer 7 in compatibility mode. As the final integration we’d roll-out to our power-users to test how the application was working in the wild. But, even so it took months to integrate and rich text editing remained a brittle component of our stack until the EMR’s finally upgraded their web components (still in process at Cerner).

I learned a few lessons from this experience: 1) ensure that you know your production environment and are building against it, 2) cut down the MVP as much as possible, and 3) pre-product prototypes should stay lean to prevent them diverging from the actual product which you deliver to physicians. Oh, and rich-text-editing is never as simple as it’s ubiquity suggests.