Describe Your Process for Deciding What Your Engineers Build Next

Explain how you decide which features your engineering team builds, and in what order. Be ready to illustrate the method with an example from your own work. ```hint Show where judgment enters Trace one decision from the pile of incoming requests to the committed plan, and point out the moments where goals, engineers' estimates or a stakeholder changed the order. ``` ### Clarifying Questions - Would you like my general method, or one specific time I had to choose between competing requests? - Do bug fixes, reliability work and tech debt compete for the same engineers here, or should I focus on new user-facing features? - Is this about one team I work with directly, or several teams sharing a single roadmap? ### What a Strong Answer Covers - How the ranking ties back to company or team goals, and where the list of candidate work comes from - A repeatable way to compare items, and how engineers' input on effort, risk and dependencies shapes it - How bug fixes, reliability and tech debt get engineering time next to new features - How the decision is communicated, how pushback is handled and when the order is revisited - A concrete example with its outcome and what the candidate learned ### Follow-up Questions - A senior leader asks for a feature that sits low on your list. What do you do, and what do you tell the team? - A feature another team depends on is slipping because of bugs. How do you choose between moving the date, cutting scope and shipping a stop-gap? - How do you decide how much of the team's time to hold back for tech debt, and how do you defend that choice?