Behavioral Interview Prep

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

Tell me about yourself.

My digital health software engineering arc started back in highschool, when I developed the hardware and neural networks to record and classify EKG waveforms, such as tachycardias, bradycardias, escape, premature beats, etc. I was fascinated by the potential of already existing data and that one 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 further 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 an 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’s revenue cycle. 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. There, 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. Initially, us co-founders spent nearly a year identifying a problem and solution we could tackle, finally settling on note writing during the Cedars-Sinai Techstars Accelerator. The Regard application was a single-page EMR-embedded webapp that helped physicians write clinical notes from EMR data. Technically, this frontend represented the tip of the technical iceberg, and was underpinned by a Python backend which integrated with the EMR via SMART on FHIR, (a HIPAA compliant cloud stack) and an operational / continuous integration stack enabling changes to be made confidently.

Getting the application robust and in clients’ hands took solving the early-stage chicken-and-egg problem: 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 played the role of the tech guy in the room, fielding technical questions and explaining how we navigated the complexities of hospital IT. And, while it wasn’t easy, the money did come. With a stocked war-chest I put on another hat, that of 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. Another of my hats was serving as engineering manager, establishing 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 used would determine both how long it takes to integrate with a hospital client and whether 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 we couldn’t get around real-time data as 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 departments and researching the available options. The first option was to use EMR specific APIs, like those offered by AthenaHealth. However, these APIs weren’t portable and the market-leading EMRs like Cerner or Epic didn’t provide sufficient custom APIs. Then there was the most popular option for real-time integration: HL7. However, I discovered from speaking with hospital IT that they’re averse to HL7 integrations because they take six to twelve months along with significant IT investment.

In the end 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: we could establish a hospital integration in as little as four weeks.

Of course, there were tradeoffs. First was latency, as a pull rather than push-based technology SMART on FHIR required 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, those issues were tractable: with a bit of experience under our belt we could stand up a new integration in under a month and hit our SLO to fetch data for a new patient in under 30s and an existing patient in under 10s (95th percentile) by limiting the data fetched and parallelizing as much as possible. These load-times were satisfactory for our users, and it was technically feasible to make the clinical data fetching instantaneous from the user’s perspective via proactive fetching and caching. In retrospect, this decision unlocked our sales: hospital IT became our allies, and we could instead focus on providing value to our physician users.

Tell me about a time you mentored or developed engineers.

I created Regard’s internship program from scratch, scaling it from one intern to cohorts that now yield 50 % full-time hires and 30+ alumni. I initially established the internship program with a three-fold goal: to improve our reputation among colleges, improve our hiring pipeline, and mentor upcoming engineers. We aimed to both grow our interns as engineers and give them a positive experience they could carry into their senior year of college.

The first two years, when our engineering team was still just a few people, we had one then two interns respectively. I managed their interviews and then served as their mentor, coming up with projects which sat at the intersection of their interests, abilities, and company needs. For example, one of our interns was a data scientist, and we worked together to analyze Regard’s diagnoses to understand clinical care gaps. I taught the interns our stack, how to use professional tools like git and debuggers where necessary, and kept them unblocked.

To scale up the internship program, in the third year I began going to career fairs including MIT and RIT’s. By then the engineering team had grown to 8+ engineers and my responsibilities had also broadened, so I took the opportunity to grow the program and formalize it. I assigned a senior engineer to manage the intern class, and we set a rotation of presentations where engineers would present on topics useful to the interns. Each intern had a “buddy” who would check in with them regularly and serve as their default go-to for any questions.

This internship structure took investment, but was well worth it: we typically hired half of our intern class, many from RIT and MIT, and growing early-career relationships greatly increased the diversity of our talent pool. Each of our nearly ten intern hires were valuable members of the team, and I’ve taken great satisfaction watching their careers develop. It’s part of leadership I take seriously, and Regard is still hosting regular intern class, at this point over thirty alumni from across the years. This experience cemented my belief that in multiplying impact through hiring and coaching.

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

One major technical misstep 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 physician-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 initial 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 APIs 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 EMRs 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, 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. And, rich-text-editing is never as simple as it’s ubiquity suggests.

What’s your approach to system design / technical decision-making?

When designing a system or making high-level technical decisions I optimize for simplicity, context-awareness, and shared-ownership by starting with a project proposal. The proposal describes the problem alongside one or more candidate solutions with their pros and cons. In some organizations this takes the form of a one-pager and it’s certainly good to constrain the gist to one page, but I also try to sketch out key details: what might the data models look like? The API contracts? What’s the range of dev hours I’d predict for implementing? I try to include diagrams to clarify the architecture or flow.

While the technical proposal typically has one writer, it should be informed by the team: whether it’s a product feature, an internal dev project, or a sales tool, it’s critical to meet with the stakeholders to understand the requirements, and to keep them involved from initial problem definition through final sign-off. Their input informs whether we’re optimizing for speed, extensibility, integration constraints, etc. This step prevents overdesign and helps reveal the true gist of the problem.

Once written, the plan can be refined by the engineering team. I’ve found a combination of asynchronous review with synchronous discussion is ideal. Often, the reviewers will come up with alternative solutions or find holes in an existing approach. Additionally, the technical spec writer is often different from the implementer[s]: having the implementers refine the plan gets them up to speed on the problem and bought into the solution.

This technical planning process tends to be standard for mature development teams (NeuroFlow had particularly robust refinement processes), and I implemented it at Regard as our team grew from 1 to 10+ engineers. Having it as a required step in the engineering workflow brings alignment and reduces thrashing from heading in the wrong direction.

For example, at NeuroFlow I was a contractor on a routing layer between the app’s clinical questionnaires and Redox – as a fresh contractor working on a microservice I had limited context on how the app’s existing behavior constrainted the routing layer. By creating technical feature specifications I was able to leverage the experience of the other engineers and ensure my solution would work, e.g. if the questionnaires first answer was “No” then the remaining answers were skipped.

Tell me about a time you handled conflict on your team?

One conflict I helped manage on my team was how to support microservices and fit them into our application without introducing unnecessary overhead. At Regard our application had grown beyond a simple frontend / backend split and the engineering team needed a philosophy for how to scale the application as its surface-area grew. Microservices gave an established and scalable philosophy, however under that umbrella we had to set our specific approach.

The team was a little over five engineers at that time so I still served as a hybrid CTO / EM / tech lead, and I took point. Because microservices cut across engineering functions I set up a team-wide sync to discuss, bringing in both the frontend and backend devs. We quickly found consensus setting boundaries in how projects would be split, but then the discussion stalled on how to structure our git repository.

The two general options are whether our code should live in a monorepo with all microservices under one root directory, or separate repositories for each microservice. In line with typical philosophies, the backend team wanted to go with a monorepo while the frontend team preferred separate repositories and the conversation started to go in circles.

While I was open to both directions, my own experience with both structures left me leaning towards a monorepo. But, I didn’t want to make the decision without buy-in. The meeting had wrapped without a final decision and I scheduled a follow-up. Before meeting I checked myself against blog posts and called friends with related experience. Then I went on a walk with the frontend engineers individually, reviewing the disagreement and the new information. This 1:1 discussion won most of them over except for one recalcitrant frontend engineer. Although he didn’t agree with the monorepo approach, I asked that he go with the team’s preference and pointed to frontend specific areas where he could set standards – issues he cared about more than repo structure.

With the groundwork in place, we were able to meet again and quickly sign off on the monorepo organization. The team was satisfied to have cut through the decision, and agreed that the approach wouldn’t have any fundamental limitations. This conflict showcases how I approach issues from a position of authority: I try and find natural consensus, and if it doesn’t exist use a personal touch to either bring people around or help them understand why we’re going against the preference.