Difficulty: 5/10interface inheritance, declaration merging, module augmentationUsing extends keywordsjavascriptCopyScenario Questions0-2 years experience1We have an interface `User { id: number; name: string; }`. How would you create a new interface that adds an optional `email` property while keeping the original shape?2If you write `interface Admin extends User { role: string; }` and then assign an object `{ id: 1, name: 'Bob', role: 'admin' }` to a variable of type `User`, what happens and why?3You need a function that accepts either a `User` or an `Admin`. How would you define the parameter type using interface extension?2-5 years experience1Our codebase has a `BaseConfig` interface used across several services. We need to add environment‑specific fields without modifying the original file. How would you extend `BaseConfig` in a separate module, and what pitfalls might you hit with declaration merging?2During a refactor, a colleague changed `interface Props extends HTMLAttributes<HTMLDivElement> {}` to add a new property, but the component now throws a type error when passed standard HTML props. Walk me through how you would debug the issue.3We want to create a generic `Response<T>` interface that extends a common `ErrorInfo` interface. Explain how you would design it and why extending versus intersecting matters for readability and future changes.5-8 years experience1Our micro‑frontend architecture shares a common UI library that defines many component props interfaces. Teams sometimes need to augment those interfaces for custom theming. Discuss the trade‑offs between using interface extension, declaration merging, and module augmentation at scale.2A performance‑critical data pipeline serializes TypeScript types to JSON schemas. Extending interfaces can cause deep recursive type resolution. How would you mitigate potential compile‑time slowdown while preserving extensibility?3When migrating a large codebase from plain objects to strongly‑typed DTOs, you need to extend third‑party interfaces without altering their source. What strategy would you use to keep type safety and avoid breaking existing consumers?8+ years experience1Our organization plans to version a public SDK that exposes many interfaces. Over time we need to add fields while maintaining backward compatibility. How would you structure interface extensions and versioning to minimize breaking changes for downstream users?2Multiple teams rely on a shared `Event` interface that is extended by each service. Explain how you would design a contract and governance model to prevent conflicting extensions and ensure type coherence across the ecosystem.3If we decide to move from TypeScript's interface inheritance to a composition‑over‑inheritance model for our domain models, what architectural impacts would that have on code generation, documentation, and runtime validation?Follow-up QuestionsWhat would happen if the extending interface redefines a property with a different type?How does declaration merging differ from using `extends` in terms of emitted JavaScript?Can you think of a scenario where extending an interface could introduce a breaking change for existing consumers?Suggest Improvement