Decide between cutting a feature versus taking technical debt for a deadline

WHAT THIS TESTS: This question tests whether you can escape the false dichotomy of pure engineering purity versus pure business expediency. Senior engineers are expected to treat scope and quality as a portfolio decision that requires quantified business risk, explicit stakeholder alignment, and a credible recovery plan. The interviewer wants to see systems thinking: you understand that a schema choice and a testing choice have different risk profiles, decay rates, and remediation costs.

A GOOD ANSWER COVERS: First, establish the decision framework by pulling in product management and business stakeholders to define what key means. Is the feature a launch blocker for the target segment or a nice-to-have? Is the deadline driven by a contractual obligation, a competitive window, or an internal target? Second, model both options with real numbers. For cutting the feature, estimate revenue or adoption risk and whether a fast-follow release is viable. For taking debt, separate the two risks: skipped unit tests increase regression rates and slow future velocity, while a less scalable schema creates a performance cliff and an expensive data migration. Third, document risks specifically. For tests, write that critical path coverage will be missing, bug escape probability rises, and refactors become dangerous; for the schema, document query latency thresholds, estimated user capacity before failure, and the engineering weeks required for a future migration. Fourth, secure explicit buy-in by presenting both options to leadership with a recommendation and a signed-off remediation budget. Fifth, define a concrete post-launch plan. For example, schedule a two-week hardening sprint immediately after launch to add contract tests and critical unit tests, and draft a schema migration roadmap with dual-write phases and rollback procedures.

COMMON WRONG ANSWERS: The biggest red flag is an absolute rule like we never skip tests or we must ship every feature. This signals an inability to trade off in a business context. Another failure is proposing debt with no payback plan; saying we will fix it later without dates, owners, or allocated capacity is indistinguishable from planning to fail. A third red flag is treating all debt as equal; conflating missing tests with a bad schema misses that schema migrations are often orders of magnitude more expensive to fix than adding tests retroactively.

LIKELY FOLLOW-UPS: The interviewer may push on how you would prioritize which tests to add back first if you skipped them. They might ask how you would monitor the brittle schema in production to know exactly when it will break. They could also ask what you would do if leadership refuses to allocate post-launch remediation time, or how you would communicate a launch delay as the third hidden option.

ONE CONCRETE EXAMPLE: Suppose the key feature is an export button for enterprise clients. The deadline is a contractual pilot launch in three weeks. You might recommend shipping without the export feature but with the scalable schema and full tests, because losing one enterprise pilot is smaller than a production outage during the pilot. Alternatively, if the export is the entire value proposition, you might ship it with a hardcoded schema and no unit tests, but you would immediately add API contract tests and set a hardening sprint for week four, with a schema migration scheduled for month two after validating product-market fit.