TypeScript Refactoring Interview Questions

The React Systems Newsletter

SubscribeSign in

TypeScript Refactoring Interview Questions How to spot weak TypeScript code, explain the problem, and refactor it into safer, cleaner, more maintainable code.

The React Systems Newsletter May 15, 2026

TypeScript interviews are changing. A few years ago, many interviews focused on syntax: what is a union type, how generics work, what Partial does, or how to type a function parameter. Those questions still appear, but stronger interviews now go further. They test whether a developer can look at code that technically works and still notice where it is fragile. Thanks for reading! Subscribe for free to receive new posts and support my work.

That is the real skill. A good TypeScript developer does not only ask: “Does this compile?” They also ask: “Can this represent invalid data?” “Will this still be safe after the next refactor?” “Does this type describe the real domain?” “Is the compiler helping us, or are we fighting it?” “Will another developer understand this in six months?”

1. Narrow Types When TypeScript Infers Too Broadly

One common interview question sounds like this: “TypeScript inferred a type that is too broad. How would you fix it, and why does it matter?”

This is a great question because it tests whether the candidate understands inference, literal types, generics, and practical safety. Here is a weak version: const ageByUsername = new Map()

ageByUsername.set('nina', 31) ageByUsername.set('mark', 'unknown')TypeScript infers: MapThat means the map accepts anything as a key and anything as a value. The compiler is no longer protecting the code. A safer version: const ageByUsername = new Map()

ageByUsername.set('nina', 31) ageByUsername.set('mark', 42)

// Error: // Argument of type 'string' is not assignable to parameter of type 'number'. ageByUsername.set('alex', 'unknown')Now the type communicates intent: keys must be strings

values must be numbers

incorrect values fail during development

The same issue appears often with React state: import { useState } from 'react'

const [paymentStatus, setPaymentStatus] = useState('idle')At first glance, this looks fine. But in many cases TypeScript may infer a broad string, depending on how the state is used. That allows invalid states: setPaymentStatus('banana') setPaymentStatus('something-went-wrong')A better version: type PaymentStatus = 'idle' | 'processing' | 'paid' | 'failed'

const [paymentStatus, setPaymentStatus] = useState('idle')

setPaymentStatus('processing') setPaymentStatus('paid')

// Error setPaymentStatus('banana')This is not just “more typing.” It prevents impossible UI states. A strong interview answer should explain that explicit types are useful when they narrow the possible values and encode business rules.

2. Do Not Annotate What TypeScript Already Knows

Another common interview question: “When should you write an explicit type annotation, and when should you let TypeScript infer it?”

Beginners often over-annotate everything: const username: string = 'nina' const retryCount: number = 3 const isDialogOpen: boolean = falseThis is not harmful, but it is noisy. TypeScript already knows these types. A cleaner version: const username = 'nina' const retryCount = 3 const isDialogOpen = falseThe important point is this: Use explicit annotations when they add useful information. For example, this annotation is useful: type SubscriptionPlan = 'free' | 'pro' | 'team'

let selectedPlan: SubscriptionPlan = 'free'

selectedPlan = 'team' selectedPlan = 'enterprise' // ErrorWithout the annotation, TypeScript may infer the variable as string in some mutable contexts: let selectedPlan = 'free'

selectedPlan = 'enterprise' // AllowedThat may not be what the application wants. For arrays and maps, inference is often good enough: const productPrices = new Map([ ['keyboard', 129], ['mouse', 79], ])TypeScript infers: MapThere is no need to repeat the type unless the empty initialization loses information: const productPrices = new Map()A good rule: Let TypeScript infer obvious implementation details. Add explicit types when they protect boundaries, narrow values, or document public APIs.

3. Protect Function Inputs with Readonly Types

Interview question: “How can you prevent a function from accidentally mutating its input?”

Bad version: type Customer = { id: string name: string

function removeFirstCustomer(customers: Array) { if (customers.length === 0) { return customers

return customers.splice(1) }The problem is splice. It mutates the original array. const customers = [ { id: 'c1', name: 'Nina' }, { id: 'c2', name: 'Mark' },

const remainingCustomers = removeFirstCustomer(customers)

console.log(customers) // Original array was changedA safer version: type Customer = { id: string name: string

function withoutFirstCustomer( customers: ReadonlyArray, ): Array { return customers.slice(1) }Now two things are improved: The function...

TypeScript Refactoring Interview Questions

Related Articles

Elevated error rates on requests to multiple models

Donald Trump and sons to be 'forever' exempt from tax audits

PopuLoRA: Co-Evolving LLM Populations for Reasoning Self- Play

Old Reddit Is Down

The ultimate female fantasy – A feminist critique of Beauty and the Beast