TypeScript Communication & Stakeholder Relations 2 — Questions and Answers
Question 1: A backend team asks why TypeScript interfaces are used instead of plain JavaScript objects in API contracts. What is the best explanation?
- Interfaces enforce runtime validation automatically
- Interfaces provide compile-time shape guarantees and serve as living documentation for API contracts (Correct answer)
- Interfaces compile to smaller JavaScript bundles
- Interfaces prevent all runtime errors in production
Correct answer: Interfaces provide compile-time shape guarantees and serve as living documentation for API contracts
TypeScript interfaces define the shape of data at compile time, giving teams a shared contract that IDEs can enforce and developers can reference as documentation.
Question 2: A stakeholder requests a feature that would require changing a public TypeScript API from returning `string` to returning `string | null`. What should you communicate first?
- This is a non-breaking change and can be deployed immediately
- This is a breaking change that requires updating all consumers and coordinating a migration plan (Correct answer)
- Only TypeScript consumers are affected, not JavaScript consumers
- The change only matters if strict null checks are enabled
Correct answer: This is a breaking change that requires updating all consumers and coordinating a migration plan
Widening a return type to include `null` is a breaking change for any consumer not already handling null, requiring coordinated migration.
Question 3: During code review, a junior developer asks what `Readonly<T>` communicates to other team members. What is the correct answer?
- It signals the object is immutable at runtime and cannot be changed
- It signals intent that properties should not be mutated after construction, enforced at compile time (Correct answer)
- It prevents the object from being passed to functions
- It marks the object for garbage collection
Correct answer: It signals intent that properties should not be mutated after construction, enforced at compile time
`Readonly<T>` communicates immutable intent to developers and triggers compile-time errors if mutations are attempted, but has no runtime enforcement.
Question 4: A product manager wants to know why the team added strict TypeScript compiler options. How should you explain the business value?
- Strict mode makes the codebase compile faster
- Strict mode catches more bugs at compile time, reducing production defects and lowering maintenance costs (Correct answer)
- Strict mode is required for deployment to cloud platforms
- Strict mode enables automatic code formatting
Correct answer: Strict mode catches more bugs at compile time, reducing production defects and lowering maintenance costs
Strict compiler options like `strictNullChecks` and `noImplicitAny` surface more potential bugs during development, reducing costly production incidents.
Question 5: A cross-functional team wants to share TypeScript type definitions between a frontend and backend project. What approach best facilitates this communication?
- Copy-paste type definitions into each project manually
- Publish shared types as a versioned internal npm package so both teams consume the same source of truth (Correct answer)
- Use any type on both sides to avoid compatibility issues
- Only the frontend team should own type definitions
Correct answer: Publish shared types as a versioned internal npm package so both teams consume the same source of truth
A shared, versioned npm package ensures both teams use identical types and version bumps signal breaking changes explicitly.
Question 6: A stakeholder is confused why a TypeScript build succeeds but the app crashes at runtime. What should you explain?
- TypeScript compilation guarantees the absence of all runtime errors
- TypeScript's type system operates at compile time and cannot prevent all runtime errors, especially from external data sources (Correct answer)
- The build tool must have a configuration error
- TypeScript strict mode would have prevented the crash
Correct answer: TypeScript's type system operates at compile time and cannot prevent all runtime errors, especially from external data sources
TypeScript types are erased at runtime, so data from APIs or user input that doesn't match expected types can still cause runtime errors.
Question 7: When onboarding a new developer to a TypeScript codebase, which practice best communicates the intended usage of a complex generic utility type?
- Add a JSDoc comment with a usage example directly above the type definition (Correct answer)
- Rename the type to something shorter
- Remove the generic constraints to simplify the type
- Move the type to a separate file without documentation
Correct answer: Add a JSDoc comment with a usage example directly above the type definition
JSDoc comments with examples appear in IDE tooltips and make complex generics approachable for new team members without requiring them to read source code.
TypeScript Communication & Stakeholder Relations 2
A backend team asks why TypeScript interfaces are used instead of plain JavaScript objects in API contracts.
What is the best explanation?