An Engineering Blog, by
BLOG

Kieran Gill

Ownership

Our expectations for execution.

The following is from our Candidate Evaluation Framework series.

Job descriptions are often full of well-meaning platitudes that don’t say much. Instead, we’re sharing the real hiring rubric our team uses. We hope this gives you a clearer, more honest view of what we value — and whether we’re the kind of team you’d like to join.

If this resonates with you, I encourage you to apply. We’re building the most accessible and highest quality healthcare clinic for children.

Ownership

We’re a small team of engineers working in a low-hierarchy environment, where engineers have a high degree of agency. With that freedom comes responsibility — we expect our engineers to take ownership and drive their projects forward independently.

Often, engineers are either great at planning or great at execution.

Engineers who are great at planning can sequence work and design solutions. They can, however, lose interest in the implementation and maintenance phase.

Great executors can take a task and turn it into high-quality code. However, they often don’t know how to prioritize one task over another. They may lack business context. Lacking context can lead them down the path of building the wrong solution, or not pushing back when the solution is too costly or doesn’t solve the problem.

We want engineers who own large projects from planning to maintenance. They understand how the project impacts the business and plan a rollout accordingly. They independently work with the PM to understand scope and come up with a delivery timeline.

We need proactive problem solvers. That is, engineers who identify and fix things without being asked. A junior/mid-level should be able to identify and flag issues. A senior+ should drive the completion of that work.

We want engineers who take pride in their work and demonstrate ownership across the entire product suite and codebase. The more senior you are, the more you’re expected to improve the broader codebase alongside your feature work. A senior engineer who ships features by shoehorning them into the existing mess sets a bad example for the team. This behavior damages the team’s ability to move quickly in the future.

Questions

  • Get the candidate talking about a large project they worked on. How did the engineer sequence the work? How did the candidate ensure a successful rollout? What was the candidate’s role in quality assurance?
  • Where do they think their responsibilities begin and end? Are they “responsible” for shaping a PRD? Are they “responsible” for QAing?
  • “Tell me about a time when you found something to improve that was outside of an assigned task or your normal day-to-day responsibilities. This can be anything: documentation improvement, adding a new testing library, improving the structure of the code, fixing a bug or design quirk.”

What great looks like

  • They were able to identify a pain point the team had and proposed a solution to fix it. This pain point could be related to velocity, stability, or something else meaningful.
  • They consistently improved the codebase/product without being explicitly asked to do so.

Potential issues

  • Engineers who have a “not my problem” attitude. They ignore alerts. They grumble at code that predates them (or was written before them or by another team) without finding a way to make the situation better.

We’re hiring full-stack engineers.

If you’re interested in helping us build the most accessible and highest quality healthcare clinic for children, consider joining us. Go here to learn more about the role.

This article is from our Candidate Evaluation Framework series. To learn more about our ideal engineering candidate, go here.