TypeScript Leadership & Professional Development 3 — Questions and Answers
Question 1: A TypeScript team lead is establishing a Definition of Done for pull requests. Which TypeScript-specific criterion is most critical to include?
- No new TypeScript errors and no new 'any' usages without justification (Correct answer)
- All functions must use explicit return type annotations
- No use of generics without constraints
- All types must be defined in a separate .d.ts file
Correct answer: No new TypeScript errors and no new 'any' usages without justification
Preventing new errors and undocumented 'any' usages maintains type safety standards without being overly prescriptive.
Question 2: When mentoring a mid-level developer struggling with TypeScript generics, which teaching approach is most effective?
- Start with a concrete use case like a typed identity function, then generalize the concept (Correct answer)
- Provide the full generic type theory first, then show examples
- Assign reading the TypeScript handbook chapter on generics as homework
- Pair them with a senior developer and observe without guiding
Correct answer: Start with a concrete use case like a typed identity function, then generalize the concept
Starting with concrete, relatable examples builds intuition before introducing abstract generic theory.
Question 3: A lead developer needs to decide between using 'interface' and 'type alias' as the team's standard for defining object shapes. Which guidance reflects professional TypeScript best practices?
- Prefer interface for object shapes since it supports declaration merging and clearer error messages; use type for unions and intersections (Correct answer)
- Always use type aliases for consistency across all type definitions
- Use interface for classes and type for everything else
- Choose randomly since they are completely interchangeable
Correct answer: Prefer interface for object shapes since it supports declaration merging and clearer error messages; use type for unions and intersections
Interfaces are optimized for object shapes and extensibility, while type aliases excel at expressing complex type relationships.
Question 4: A TypeScript team wants to share types between a frontend React app and a backend Node.js API. What is the most maintainable architectural approach?
- Extract shared types into a dedicated shared package within a monorepo (Correct answer)
- Copy-paste types between projects and update them manually
- Define all types only in the backend and import via HTTP
- Use 'any' on the frontend to avoid type-sharing complexity
Correct answer: Extract shared types into a dedicated shared package within a monorepo
A shared types package in a monorepo creates a single source of truth and eliminates synchronization overhead.
Question 5: During sprint planning, how should a team lead estimate effort for converting a JavaScript module to TypeScript?
- Factor in time for type discovery, handling implicit any errors, and writing tests to validate behavior (Correct answer)
- Estimate based solely on lines of code to be converted
- Assume TypeScript conversion takes the same time as writing new features
- Delegate estimation entirely to the developer doing the work with no guidance
Correct answer: Factor in time for type discovery, handling implicit any errors, and writing tests to validate behavior
TypeScript migrations require time for understanding existing code contracts, not just mechanical syntax changes.
Question 6: A junior developer asks why the team uses 'unknown' instead of 'any' for external API responses. What is the correct explanation?
- 'unknown' requires explicit type narrowing before use, forcing developers to handle type safety consciously (Correct answer)
- 'unknown' is faster at runtime than 'any'
- 'unknown' automatically validates the shape of the data
- 'unknown' allows all operations just like 'any' but with better readability
Correct answer: 'unknown' requires explicit type narrowing before use, forcing developers to handle type safety consciously
Unlike 'any', 'unknown' forces developers to narrow the type before performing operations, maintaining type safety.
Question 7: A TypeScript team lead is reviewing a PR where a developer used a non-null assertion operator (!) extensively. What is the most constructive feedback?
- Replace assertions with proper null checks or type guards, and document cases where the assertion is provably safe (Correct answer)
- Reject the PR and ask for a full rewrite without non-null assertions
- Approve it since non-null assertions are valid TypeScript
- Convert all assertions to 'as' type casts instead
Correct answer: Replace assertions with proper null checks or type guards, and document cases where the assertion is provably safe
Non-null assertions should be replaced with type guards where possible, and documented where they are provably necessary.
TypeScript Leadership & Professional Development 3
A TypeScript team lead is establishing a Definition of Done for pull requests.
Which TypeScript-specific criterion is most critical to include?