How do you handle a situation where requirements change midway through building a feature?

Show that you treat it as normal rather than as a failure of process — because on most teams it is normal.

• Establish what actually changed. Often the underlying need has not changed at all, only the proposed solution. Asking what problem the new requirement solves sometimes reveals that what you have already built covers it.
• State the cost honestly and early. What is now wasted, what can be reused, and what the new date looks like. Absorbing scope quietly and missing the date is much worse than a difficult conversation on day three.
• Protect what is expensive to change. If the change touches a data model or an API contract other teams consume, that needs more scrutiny than a change to layout.

How to reduce the pain structurally: build in thin vertical slices behind a feature flag, so there is always something demonstrable and always a safe way to turn it off. Getting a rough version in front of the stakeholder early is the single most effective way to surface a change before it is expensive.