5 exercises — choose the best-structured answer to common TypeScript Developer interview questions covering advanced types, utility types, conditional types, backend setup, and strict null checking.
Structure for TypeScript Developer answers
Tip 1: Name specific TypeScript features: conditional types, infer, template literals, const assertions
Tip 2: Demonstrate utility type knowledge with concrete use cases (Omit for DTOs, Pick for forms)
Tip 3: For Node.js: mention esbuild/swc for build speed, Prisma/Drizzle for type-safe DB access
Tip 4: For null safety: mention gradual migration, optional chaining, Zod at boundaries
0 / 5 completed
1 / 5
The interviewer asks: "What are the key differences between TypeScript's type system and Flow's?" Which answer demonstrates deep type system knowledge?
Option B is strongest because it identifies the structural typing model both share, highlights TypeScript's type system advanced features, and gives an honest ecosystem comparison. Key concepts: structural typing, conditional types, template literal types, infer, const assertions, type erasure, @types ecosystem. Option A bases the comparison on company affiliation. Option C is incorrect (they are separate tools). Option D makes a simplistic performance claim.
2 / 5
The interviewer asks: "Explain TypeScript's utility types and when you use them." Which answer best demonstrates practical utility type knowledge?
Option B is strongest because it names all major utility types with concrete use cases for each. Key structure: Partial (update payloads) → Required → Readonly (config) → Pick (form state) → Omit (DTOs) → Record (lookup tables) → ReturnType/Parameters (HOFs) → NonNullable (post-null-check narrowing). Option A is too vague. Option C (using `any`) defeats the purpose of TypeScript. Option D is incorrect (utility types are essential in application code).
3 / 5
The interviewer asks: "What are conditional types in TypeScript and how do you use them?" Which answer best demonstrates advanced type system mastery?
Option B is strongest because it explains the syntax, the infer keyword, distributive behaviour, and gives practical use cases. Key structure: T extends U ? X : Y syntax → infer (extract inner type) → distributive (union distribution) → practical: DeepPartial, exhaustiveness → never for dead branches. Option A confuses type-level and value-level conditionals. Option C is incorrect (conditional types are purely at compile time). Option D avoids answering.
4 / 5
The interviewer asks: "How do you use TypeScript with a Node.js backend?" Which answer best demonstrates production TypeScript backend setup?
Option B is strongest because it covers all aspects of a production TS Node.js setup: tsconfig, fast build tools, path aliases, env validation, decorator config, type-safe database access, and CI separation of type checking from building. Key structure: tsconfig (strict/NodeNext) → esbuild/swc for build → path aliases → Zod env validation → Prisma/Drizzle → CI tsc --noEmit. Option A describes a basic setup. Option C is incorrect (TypeScript adds significant value to backends). Option D (ts-node in production) is an anti-pattern due to performance overhead.
5 / 5
The interviewer asks: "How do you handle strict null checking in a large TypeScript codebase?" Which answer demonstrates practical null safety expertise?
Option B is strongest because it addresses the migration strategy, narrowing patterns, safe defaults, boundary validation, and API design. Key structure: strictNullChecks on → gradual migration (ts-strictify) → narrowing patterns → ! with documentation → ?./?? → Zod at boundaries → Option pattern for domain nullability. Option A disables the feature (bad practice). Option C (as any) defeats type safety. Option D is incorrect (strictNullChecks must be explicitly enabled).