Onsite interview guidance

If you've reached the onsite stage at Hinge Health, you've already shown us how you build with AI in our technical interviews. The onsite interview moves away from building and toward judgment and collaboration: how you review code without AI, how you partner with Product and Design, and, for Staff candidates, how you've owned complex systems in production.

Our interview loop is designed to reflect how we actually work, evaluating hands-on technical depth, AI tool fluency, and judgment in real-world engineering scenarios. The goal is to understand how you've operated in practice and how you'd operate here. This guide covers each session, what we evaluate, and how to prepare.

Senior candidates complete two sessions. Staff candidates complete three, adding the Past Project Deep Dive.

Session	Length	Senior	Staff
Code Critique & Refactoring	45 minutes	Yes	Yes
Product Collaboration	45 minutes	Yes	Yes
Past Project Deep Dive	45 minutes	No	Yes

1. Code Critique & Refactoring

45 minutes · No AI tools · Your choice of language

You'll be given a printed code sample (about 80–150 lines) and asked to critique it as you would in a real code review, then propose a refactor and explain what you're optimizing for. You can choose TypeScript, Python, Go, or Java. Let your recruiter know your choice in advance so the right sample is ready.

No AI tools in this session: This isolates your raw engineering judgment, the ability to supervise AI-generated code without assistance. Reviewing code without help is the same skill you use to supervise what your agents produce in production.

What we're evaluating

• Critique depth: Do you catch the real issues, not just the surface lint? The sample has issues at more than one level, and the most important ones usually aren't the first ones you'll spot.
• Prioritization and scope judgment: Do you lead with what matters? Can you distinguish a blocker from a nit? Volume isn't the goal. Three real issues with clear reasoning will do better than twelve observations of mixed importance. Do you avoid the "rewrite it all" trap and propose something scoped and pragmatic? We're looking for prioritization tied to risk to the system, the customer, or the team, and the judgment to know when the right answer is "not now."
• Review communication: Could your feedback be delivered as-is to a peer? Is it specific, actionable, and blameless? "This will break if X happens because Y" is more useful than "this needs better error handling."

How to prepare

• Practice narrating a code review out loud, as if you're talking to the author.
• Think about how you distinguish "I'd block this PR" from "land it with a follow-up ticket."
• Review patterns common in production services in your chosen language, such as error handling, module boundaries, and API safety.

For Staff engineers: Staff candidates are expected to go all the way down, framing issues in terms of system properties and architectural risk, not just local correctness. Feedback should read like a tech lead's: precise, raising the team's bar, and helping the author learn without lecturing.

2. Product Collaboration

45 minutes · Behavioral · STAR format

This is a behavioral interview focused on how you partner with Product and Design. You'll be asked about real examples using a STAR-style format (Situation, Task, Action, Result). The interviewer will ask a few questions covering how you handle tension between product and engineering, communicate technical constraints, and take shared ownership of outcomes.

What we're evaluating

Dimension	What we're looking for
Product partnership	Do you treat product goals as shared outcomes, or do you describe a world where Product and Engineering are separate concerns? We're looking for specific moments where your perspective shaped scope, changed a decision, or shifted how the team thought about the problem.
Tradeoff judgment	When you describe technical vs. product tensions, do you show business judgment or just advocate for one side? We want to hear you frame technical investments in business terms without being asked, and show that you know when the shortcut was the right call, with a clear plan to address the debt.
Technical communication	Can you explain constraints to non-engineers in a way that changes their decisions, not just informs them? Did the explanation land, and did it shift something concrete?
Accountability for outcomes	Do you feel responsible for the metric, not just the feature? We want to hear about a time the product didn't land the way you expected, what you did when you saw the data, and what you specifically changed about your approach on the next feature.

How to prepare

• Use the STAR framework (Situation, Task, Action, Result) to structure your stories.
• Prepare at least one story per dimension above, and make sure each story has a specific outcome.
• Think about a time you pushed back on product scope and a time you accepted a shortcut. Both are important.
• Think about a time your technical input visibly changed a product or design decision before it was locked in.
• Get familiar with our products before the session: Women's Pelvic Health, Enso, TrueMotion, and Fall Prevention.

For Staff engineers: Staff candidates are expected to show their input demonstrably moving the product direction, beyond executing requirements. We want specific moments where your perspective shaped scope, changed a decision, or shifted how the team thought about the problem. Your communication should be proactive, before the design is locked, not after the fact.

3. Past Project Deep Dive

45 minutes · No AI tools · Submit write-ups 24 hours in advance

Staff-only round: This session is only in the Staff engineer loop.

This is a detailed technical conversation about two projects you personally led, or where you owned a significant technical decision. Send your recruiter a 1–2 page write-up for each project at least 24 hours before the interview so your interviewer can review them in advance. The session itself is a structured deep dive. It's a conversation, not a presentation, and we'll probe hard on decisions, tradeoffs, and what you personally owned.

We strongly encourage adding a third page to each write-up with an architecture diagram, rollout diagram, or system boundary map. The goal is a concrete discussion tool, not a polished deck.

Only share what you're comfortable sharing. Don't include confidential information from a current or former employer. Describing the problem, your decisions, and the outcome at a higher level is fine, and you can tell your interviewer when you can't go further.

No AI tools are used in this session, though we're interested in hearing how AI has shaped your technical practice and the work you describe.

What we're evaluating

• Operational excellence: Did you set operational targets upfront and drive toward them? We want to see ownership of SLOs, incidents, on-call, rollout safety, and recovery. How did you keep what you shipped healthy in production? The strongest examples show cross-team delivery at predictable velocity, retiring whole classes of failure rather than patching them one at a time.
• Complexity: Pick projects with real cross-team complexity: architecture you owned across teams, alternatives you rejected with clear reasoning, and the riskiest decision you made and how you validated it. We'll probe scope, blast radius, and how much ambiguity you personally resolved versus were handed.
• Domain expertise: Can you go deep on the technologies and problem domains involved? Show us you're the go-to expert for your team's domain: someone who knows the stack cold, brings grounded ideas onto the roadmap, and is the person others consult on the hardest problems.
• Communication: Can you explain a complex technical project clearly enough that a non-engineer could follow the business rationale? Can you explain it at different levels of detail, from the business case down to the implementation, and switch when asked? We want to hear how you resolved contentious cross-team disagreements. Smooth success stories tell us less.

How to prepare

• Choose projects where you owned the architecture or a significant cross-team technical decision, not ones you only contributed to.
• Make sure the two projects show something different. Consider one that highlights operational or reliability ownership and one that highlights architectural complexity or cross-team coordination.
• Be ready to go deep on the alternatives you rejected and why, where the riskiest decision was and how you validated it, and what broke in production and what you did about it.
• Know your SLOs, incident timelines, and dependency maps.

Quick tips for success

• Make your personal contribution concrete. If the question is about a team outcome, be clear about what you specifically decided, owned, or drove.
• Lead with what matters. In the code review, in project stories, and in product collaboration, put the highest-impact thing first.
• Bring the messy stories. The most revealing answers come from situations with imperfect information, real tradeoffs, and hard calls. Don't sanitize them.
• Show the after. Every good story has a "so what": a metric that moved, a process that changed, a team that operated differently afterward.
• Don't wait to be asked. The strongest candidates surface business context, risk, and outcome data without prompting.

Our cultural values

At Hinge Health, culture is part of how the work gets done. Five values we live by:

Value	What it means
Effective Communication	Say it clearly, say it early, say the thing that moves the work forward.
Lead at All Levels	You don't need the title to see the gap and take the step.
Hustle	Bias for action means momentum with judgment.
Accountability	Own the outcome and learn from it.
Learn It All	Curiosity is how we scale. Learn fast and adjust faster.

If you haven't done your technical interviews yet, read our technical interview guidance. Questions about your onsite? Reach out to your recruiter. We're rooting for you.