Using mission to prioritize debt vs new feature

WHAT THIS TESTS Prioritization is the core senior skill, and the interviewer wants to see that the mission is a real decision tool for you rather than a poster on the wall. They are checking whether you can reduce two dissimilar tasks to comparable terms and pick deliberately.

A GOOD ANSWER COVERS Translate both tasks into mission-aligned outcomes. For the unproven feature, recognize that its primary product is information: it either validates or kills a hypothesis cheaply, so the question is how small you can make the bet. For the debt, recognize its value is preserved velocity and reduced incident risk over time. Then weigh cost of delay, reversibility, and the product's current phase: an early-stage product searching for fit usually favors learning, while a scaling product with reliability pressure favors paying down debt that threatens the mission.

COMMON WRONG ANSWERS A blanket rule that engineers should always fix debt first, or that growth always trumps maintenance. Ignoring the mission entirely and choosing on personal taste. Treating the unproven feature as a full commitment rather than an experiment that can be scoped down.

LIKELY FOLLOW-UPS How would you size the experiment for the unproven feature? At what debt level would you override a growth priority? How do you communicate the choice to the team that loses?

ONE CONCRETE EXAMPLE If the mission is to be the simplest tool for beginners and the product is still finding fit, you might ship a thin feature-flagged version of the unproven feature to a slice of users to gather signal, while scheduling the debt fix for the next cycle unless it is already causing onboarding failures. If the same debt is breaking signups, it directly violates the mission and jumps the queue.