What do you do when only frontend work remains in a sprint?

WHAT THIS TESTS: This question assesses your understanding of core Scrum principles, specifically team ownership and cross-functionality. The interviewer is looking for a "we" versus "me" attitude. They want to see if you prioritize the team's shared commitment to the Sprint Goal over your individual role as a "backend specialist." It's a test for a "T-shaped" engineer who contributes beyond their core expertise.

A GOOD ANSWER COVERS: A strong answer demonstrates proactivity and a focus on the team's success. First, explicitly state that the entire team owns the Sprint Goal. Second, communicate with the overloaded frontend developers and ask how you can help. This could be pairing on a simple component, writing unit/integration tests for their code, or handling manual QA. Third, offer to take on non-coding tasks to free them up, like code reviews, dependency updates, or clarifying requirements with the PO. Finally, if you cannot contribute directly, use the time to improve shared infrastructure, like CI/CD pipelines or end-to-end test frameworks, which benefits the whole team's future velocity.

COMMON WRONG ANSWERS: The most common red flag is a siloed mindset. Saying "I'd pull in a ticket from the next sprint" or "There's nothing for me to do, so I'd focus on my own refactoring" shows a fundamental misunderstanding of Scrum. According to the Scrum Guide, the entire team commits to the Sprint Goal, and "Developers" are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. Another mistake is waiting to be assigned a task. A senior engineer is expected to proactively find ways to contribute to the team's goal.

LIKELY FOLLOW-UPS: "What if you don't know the frontend framework at all? How would you help then?" (Answer: Focus on non-framework tasks: writing tests, documentation, API contract validation, manual testing, CI/CD improvements). "What if the frontend developers say they don't need help?" (Answer: Trust but verify. Ask if you can shadow or review their PRs to learn the codebase. If they're truly unblocked, pivot to high-value team improvements).

ONE CONCRETE EXAMPLE: "In a previous sprint, our two frontend engineers were struggling to finish a new settings page with 3 days left. As a backend dev, I couldn't write React code. So, I first took over all their PR reviews to unblock their merge queue. Then, I wrote the complete Cypress end-to-end test suite for the new page based on the acceptance criteria. This freed them up to focus purely on implementation, and we delivered the feature on time."