TypeScript Interview Questions

TypeScript catches type-related errors during development rather than at runtime, provides much richer autocomplete and inline documentation in code editors, makes code easier to understand and refactor safely since types document what a function expects and returns, and generally makes large codebases easier to maintain as a team and project grow.

A type annotation is added with a colon followed by the type after the variable name. ```typescript let age: number = 25; let name: string = 'Alex'; let isActive: boolean = true; ``` TypeScript then enforces that the variable only holds values of that declared type going forward.

The basic primitive types include string, number, boolean, null, undefined, and symbol, mirroring JavaScript's own primitive types. TypeScript adds static typing on top of these, so the compiler verifies at compile time that operations on a variable match its declared type.

Type inference is TypeScript's ability to automatically determine a variable's type based on its assigned value, without an explicit annotation. ```typescript let count = 5; // inferred as number ``` This means you don't always need to write out every type explicitly, since TypeScript can often figure it out on its own.

The any type opts a variable out of type checking entirely, allowing it to hold any value without TypeScript verifying operations on it. It should generally be avoided except as a last resort or during incremental migration from JavaScript, since overusing it defeats the whole purpose of using TypeScript in the first place.

An interface defines the shape an object should have, specifying required properties and their types. ```typescript interface User { name: string; age: number; } const user: User = { name: 'Alex', age: 30 }; ``` If an object doesn't match the interface's shape, TypeScript flags it as a compile-time error.

Both can describe the shape of an object, and in many everyday cases they're interchangeable. Interfaces can be extended and merged across multiple declarations, which is useful for public APIs, while type aliases can represent a wider range of types beyond just object shapes, including unions, primitives, and tuples, and can't be reopened once declared.

Arrays are typed by specifying the element type followed by square brackets, or using the generic Array syntax. ```typescript let numbers: number[] = [1, 2, 3]; let names: Array<string> = ['Alex', 'Sam']; ``` Both forms are equivalent, and TypeScript enforces that every element in the array matches the declared type.

A tuple is an array with a fixed number of elements where each position has a specific, known type. ```typescript let point: [number, number] = [10, 20]; ``` Unlike a regular array, a tuple's length and the type at each index are fixed and checked, so you can't accidentally add an extra element or mismatch a type at a given position.

An enum defines a set of named constant values. ```typescript enum Status { Active, Inactive, Pending } let current: Status = Status.Active; ``` Enums make code more readable by using descriptive names instead of raw numbers or strings scattered throughout the codebase.

Parameters are annotated individually, and the return type follows the parameter list. ```typescript function add(a: number, b: number): number { return a + b; } ``` TypeScript checks both that the function is called with correctly typed arguments and that it actually returns a value matching the declared return type.

An optional property is marked with a question mark after its name, indicating it doesn't have to be present on every object matching the interface. ```typescript interface User { name: string; age?: number; } ``` Here, age can be omitted entirely when creating a User object, while name is still required.

A union type lets a variable hold one of several specified types, using a pipe symbol between them. ```typescript let id: string | number; id = 'abc123'; id = 42; ``` Both assignments are valid, but attempting to assign a value of any other type would produce a compile-time error.

tsconfig.json is the configuration file that controls how the TypeScript compiler behaves for a project, including which files to include, the target JavaScript version to compile to, strictness settings, and module resolution options. It's typically placed at the root of a TypeScript project.

The TypeScript compiler, tsc, converts .ts files into plain .js files that can run in any JavaScript environment. Running `tsc` in a project with a tsconfig.json compiles all included files according to the configured settings, or `tsc filename.ts` compiles a single file directly.

A TypeScript class extends JavaScript's class syntax with type annotations for properties and methods, access modifiers like public, private, and protected, and features like abstract classes and interfaces implementation. It compiles down to a regular JavaScript class, with the type information stripped out since JavaScript itself has no concept of static types.

Access modifiers control the visibility of a class's properties and methods. public (the default) is accessible from anywhere. private is accessible only within the class itself. protected is accessible within the class and any classes that extend it. These help enforce encapsulation, hiding implementation details that code outside the class shouldn't depend on directly.

let and const are block-scoped, meaning they only exist within the nearest enclosing curly braces, while var is function-scoped, which can lead to confusing behavior in loops and conditionals. const additionally prevents the variable from being reassigned after its initial value. TypeScript works with all three, though let and const are strongly preferred in modern code.

You can use an inline object type annotation. ```typescript let user: { name: string; age: number } = { name: 'Alex', age: 30 }; ``` This works fine for a one-off shape, though defining a named interface or type alias is usually preferred when the same shape is used in multiple places.

void represents the absence of a return value, typically used as the return type for functions that don't return anything meaningful. ```typescript function logMessage(message: string): void { console.log(message); } ``` It signals to callers that they shouldn't expect or rely on a return value from that function.

never represents a value that should never occur, typically used as the return type for a function that always throws an error or never finishes executing (like an infinite loop). It's also used by the compiler to represent an unreachable code path, like the default case in an exhaustive switch statement covering every possible value.

A function type describes the shape of a function's parameters and return value, which can be assigned to a variable or used as a type annotation. ```typescript let add: (a: number, b: number) => number; add = (x, y) => x + y; ``` This is useful for typing variables that hold functions, like callbacks or event handlers.

Type assertion tells the compiler to treat a value as a specific type, using the as keyword. ```typescript let value: unknown = 'hello'; let strLength = (value as string).length; ``` Unlike casting in some other languages, a type assertion doesn't perform any runtime conversion. It only affects how TypeScript checks the code at compile time, so an incorrect assertion can still cause a runtime error if the actual value doesn't match.

undefined typically means a variable has been declared but not yet assigned a value. null represents an intentional absence of a value, explicitly assigned. TypeScript treats them as distinct types by default, and with strictNullChecks enabled, neither is assignable to other types unless explicitly included in a union.

You combine an interface or type alias with array syntax. ```typescript interface Product { name: string; price: number; } let products: Product[] = [{ name: 'Pen', price: 2 }]; ``` TypeScript then checks that every object added to the array matches the Product shape.

The spread operator (...) copies the elements or properties of an array or object into a new one. ```typescript const nums = [1, 2, 3]; const moreNums = [...nums, 4, 5]; ``` TypeScript infers the resulting type based on what's being spread, correctly inferring moreNums as number[] here.

A literal type restricts a value to one specific, exact value rather than a broader type category. ```typescript let direction: 'up' | 'down' = 'up'; ``` Here, direction can only ever be the string 'up' or 'down', not any arbitrary string, which is more precise than typing it as a general string.

A default value is assigned directly in the parameter list, and TypeScript infers the parameter's type from that default value if no explicit annotation is given. ```typescript function greet(name: string = 'Guest'): string { return `Hello, ${name}`; } ``` A parameter with a default value also becomes optional for the caller to provide.

An abstract class can include actual implementation for some methods while leaving others abstract (to be implemented by subclasses), and it can't be instantiated directly on its own. An interface only defines a shape or contract, with no implementation at all, and a class can implement multiple interfaces but extend only one class, abstract or otherwise.

A namespace is a way to organize related code under a single named container, helping avoid naming collisions in the global scope. It was more commonly used before ES modules became the standard way to organize TypeScript and JavaScript code, and modules are now generally preferred over namespaces for most modern project structures.

An implicit any occurs when TypeScript can't infer a type and no annotation is provided, silently falling back to any, which the noImplicitAny compiler flag can catch and flag as an error. An explicit any is when a developer deliberately types something as any, which is sometimes necessary but should be a conscious, visible decision rather than something that happens by accident.

A union type combining multiple interfaces or object types works well here. ```typescript interface Dog { bark(): void; } interface Cat { meow(): void; } let pet: Dog | Cat; ``` TypeScript then requires narrowing (checking which specific shape the value actually has) before you can call a method that's only available on one of the possible types.

The strict flag enables a bundle of stricter type-checking options all at once, including strictNullChecks, noImplicitAny, and several others, rather than needing to enable each one individually. It's widely recommended to enable strict mode, especially on a new project, since it catches significantly more potential bugs at compile time.

An async function's return type is automatically wrapped in a Promise, so a function returning a string is typed as returning Promise<string>. ```typescript async function fetchName(): Promise<string> { return 'Alex'; } ``` TypeScript checks that the function's actual return values match the type wrapped inside that Promise.

TypeScript's type checking happens entirely at compile time and produces no runtime code or overhead, but it also can't catch errors from data that doesn't match its expected shape at runtime, like malformed data from an external API. Runtime validation libraries actually check data shapes while the program is running, which TypeScript alone can't guarantee, so the two approaches are often used together rather than as substitutes for each other.

any disables type checking entirely, letting you do anything with the value without the compiler complaining. unknown also accepts any value, but requires you to narrow its type (through a type check or assertion) before you can perform most operations on it, making unknown a much safer choice when a value's type genuinely isn't known in advance.

A type guard is a check that lets TypeScript narrow a variable's type within a conditional block, based on runtime checks like typeof, instanceof, or a custom function. ```typescript function printLength(value: string | number) { if (typeof value === 'string') { console.log(value.length); } } ``` Inside the if block, TypeScript knows value is specifically a string.

A discriminated union combines several types sharing a common literal property (the discriminant) that distinguishes which specific type a value is. ```typescript type Shape = | { kind: 'circle'; radius: number } | { kind: 'square'; side: number }; ``` Checking the kind property lets TypeScript narrow which specific shape variant you're working with, enabling exhaustive, type-safe handling of each case.

Interfaces extend other interfaces using the extends keyword, combining their members into a single new interface. Type aliases achieve a similar effect using an intersection type with the & operator, combining multiple types into one that has all their combined properties. Both approaches ultimately produce a type requiring all the combined members.

Utility types are built-in generic types that transform existing types in common, useful ways. Partial<T> makes all properties optional. Pick<T, K> selects a subset of properties. Omit<T, K> excludes specific properties. Readonly<T> makes all properties immutable. Record<K, V> builds an object type with specified keys and value types.

A mapped type creates a new type by transforming each property of an existing type according to a rule. ```typescript type Readonly<T> = { readonly [K in keyof T]: T[K]; }; ``` Many of TypeScript's built-in utility types, like Partial and Readonly, are themselves implemented as mapped types.

keyof produces a union type of all the property names (keys) of a given type. ```typescript interface User { name: string; age: number; } type UserKeys = keyof User; // 'name' | 'age' ``` It's commonly used alongside generics to write functions that operate safely on a specific object's properties.

A conditional type selects between two types based on a condition, using syntax similar to a ternary expression. ```typescript type IsString<T> = T extends string ? true : false; ``` They're a powerful tool for building flexible, reusable type utilities that adapt their output type based on the input type provided.

const prevents a variable binding from being reassigned, but if that variable holds an object, the object's properties can still be mutated. readonly, applied to a property in an interface or class, prevents that specific property from being reassigned after the object is created, offering property-level immutability rather than variable-level immutability.

Decorators are a special kind of declaration that can be attached to a class, method, property, or parameter to modify its behavior, using an @ prefix syntax. ```typescript @Component({ selector: 'app-root' }) class AppComponent {} ``` They're heavily used in frameworks like Angular and NestJS for metadata and dependency injection, though they remain an experimental TypeScript feature requiring a compiler flag to enable.

Module augmentation lets you add new properties or methods to an existing module or type declaration, often used to extend a third-party library's types when the library doesn't natively support something a project needs, without modifying the library's own source code directly.

The callback parameter is typed as a function signature describing its own parameters and return type. ```typescript function fetchData(callback: (data: string) => void): void { callback('result'); } ``` This ensures both that fetchData is called with a correctly shaped callback and that the callback itself receives correctly typed arguments.

An index signature (`[key: string]: T`) directly on an interface or type allows any string key mapping to a value of type T, defined inline. Record<K, V> achieves a similar result as a utility type, often used when you want to reuse the pattern generically or constrain the keys to a specific union of string literals rather than any string.

A non-null assertion, written with an exclamation mark after an expression, tells the compiler to treat a value as definitely not null or undefined, even if its type would normally allow for that possibility. ```typescript const el = document.getElementById('app')!; ``` It should be used carefully, since it bypasses a safety check rather than actually verifying the value isn't null at runtime.

Declaration merging is TypeScript's ability to combine multiple declarations with the same name into a single definition, most commonly used with interfaces, where declaring the same interface name twice merges their members into one combined interface, rather than causing a naming conflict error.

You can install community-maintained type definitions from DefinitelyTyped, typically via a package like @types/library-name, or write your own .d.ts declaration file describing the library's shape if no community types exist. This lets TypeScript type-check code using the library even though the library itself was written in plain JavaScript.

`age?: number` means the property can be entirely absent from the object. `age: number | undefined` requires the property to be present, but its value can explicitly be undefined. This distinction matters when strict property checking is relevant, since the two aren't always interchangeable depending on how an object is constructed or accessed.

A generic constraint restricts what types are allowed to be used for a generic type parameter, using the extends keyword. ```typescript function getLength<T extends { length: number }>(item: T): number { return item.length; } ``` This lets the function work with any type having a length property, like a string or an array, while still being caught at compile time if called with something that doesn't have one.

Function overloading defines multiple distinct call signatures for the same function, each potentially returning a different type based on the arguments provided. Default parameters simply provide a fallback value for a parameter when the caller omits it, without changing the function's overall signature or return type based on which arguments were passed.

You'd define the expected event object's shape directly, or use a generic type parameter if the handler needs to work with different event types. ```typescript type ClickHandler = (event: { target: EventTarget }) => void; ``` In practice within a real React or DOM project, you'd typically use the library's or the DOM's own provided event types rather than redefining them from scratch.

as const tells TypeScript to infer the narrowest, most literal possible type for a value, rather than widening it to a more general type. ```typescript const colors = ['red', 'green', 'blue'] as const; ``` Here, colors is typed as a readonly tuple of the exact literal strings, rather than the broader string[] it would otherwise infer, which is useful when you want to preserve exact values for later type-level use.

An index signature lets you type an object with keys that follow a consistent pattern but aren't individually enumerated. ```typescript interface Scores { [studentName: string]: number; } ``` This allows any string key mapping to a number value, useful for genuinely dynamic data, though a more specific type like Record<K, V> or a defined interface is usually preferable when the keys are actually known ahead of time.

A type predicate is a function whose return type explicitly tells TypeScript what type a value has been narrowed to when the function returns true, using the `value is Type` syntax. ```typescript function isString(value: unknown): value is string { return typeof value === 'string'; } ``` Unlike a regular function returning a plain boolean, using a type predicate inside a conditional actually narrows the variable's type for TypeScript within that block.

infer lets you extract and capture a type from within a conditional type's structure for reuse elsewhere in that type. ```typescript type ReturnTypeOf<T> = T extends (...args: any[]) => infer R ? R : never; ``` This pattern underlies several of TypeScript's built-in utility types, like the actual ReturnType utility, letting you pull a specific piece of type information out of a more complex type.

I'd enable TypeScript with relatively loose strictness settings initially, renaming files from .js to .ts gradually rather than all at once, using allowJs to let TypeScript and JavaScript files coexist during the transition. I'd tighten strictness settings progressively as more of the codebase gets typed, and prioritize converting the most critical or frequently modified modules first, since those benefit most from type safety.

TypeScript uses structural typing, meaning two types are considered compatible if they have the same shape, regardless of their declared name. Nominal typing, used in languages like Java, considers types compatible only if they're explicitly declared as related. TypeScript's structural approach gives more flexibility but means accidentally compatible shapes can pass type checks even when they represent conceptually different things, which sometimes calls for deliberate techniques like branded types to enforce nominal-style distinctions where it matters.

Branded types simulate nominal typing within TypeScript's structurally typed system, typically by adding a unique, unused property to distinguish otherwise structurally identical types. ```typescript type UserId = string & { readonly __brand: 'UserId' }; ``` This prevents accidentally passing a plain string where a specifically validated UserId is expected, catching a class of logic errors that structural typing alone wouldn't catch.

The strict flag enables a bundle of stricter checks at once, including strictNullChecks (null and undefined aren't assignable to other types unless explicitly included), noImplicitAny (variables without an inferred or annotated type raise an error), and strictFunctionTypes (stricter checking of function parameter compatibility). I'd generally recommend enabling strict mode from the start of a new project, since retrofitting it onto a large, loosely typed codebase later is considerably more work.

I'd define interfaces or types matching each endpoint's expected request and response shapes, ideally generated automatically from an API schema like OpenAPI to avoid manually keeping types in sync with the actual API. Wrapping fetch or Axios calls in typed functions that return the correctly typed response, rather than typing the response as any at the call site, keeps type safety flowing through the whole application rather than stopping at the network boundary.

The satisfies operator checks that a value matches a given type without widening the value's own inferred type the way a direct annotation would, preserving more specific literal types for later use while still validating the value against the constraint. ```typescript const config = { mode: 'dark' } satisfies Config; ``` This is particularly useful when you want both type safety and to retain the most specific inferred type for downstream usage, like autocomplete on a literal value.

TypeScript generally handles circular type references between interfaces and types without issue, since types are resolved lazily. Circular value imports (actual runtime code, beyond just types) are more problematic and can cause runtime errors, so I'd look at restructuring the module boundaries, sometimes extracting shared types into a separate module both sides can import from, to break a genuinely problematic circular dependency.

I'd look at project references to split a large monorepo into smaller, independently compiled projects that TypeScript can build incrementally rather than recompiling everything on every change. Reviewing overly complex generic types that are expensive for the compiler to resolve, and making sure incremental compilation and appropriate excludes are configured in tsconfig.json, are also common levers for improving compile times.

Function overloads let you declare multiple valid call signatures for the same function name, each with different parameter and return types, giving precise type checking for each specific way the function can be called. ```typescript function getValue(key: string): string; function getValue(key: string, fallback: number): number; function getValue(key: string, fallback?: number) { /* implementation */ } ``` This gives callers accurate autocomplete and type checking depending on exactly how they call the function.

I'd define a mapping type associating each event name with its specific payload type, then use generics constrained by that mapping so the emit and subscribe functions are checked against the correct payload shape for whichever event name is used. ```typescript interface Events { login: { userId: string }; logout: undefined; } function emit<K extends keyof Events>(event: K, payload: Events[K]) {} ``` This catches mismatched event names or payload shapes at compile time rather than only discovering the mismatch at runtime.

I'd establish a shared base tsconfig.json that individual project configs extend, covering the strictness settings and compiler options that matter most for consistency and safety, while leaving room for project-specific overrides where genuinely needed. A shared ESLint configuration enforcing TypeScript-specific best practices, paired with documentation explaining the reasoning behind key decisions, keeps standards consistent without feeling arbitrarily imposed.

I'd version the shared types package carefully using semantic versioning, since a breaking change to a widely shared type can ripple across every consumer simultaneously. Automating generation of these types from a single source of truth, like an API schema or a shared data model, where possible, reduces the risk of the shared package drifting out of sync with what it's supposed to represent.

I'd weigh the genuine type-safety benefit against the cost to the team's ability to read, understand, and maintain that code, since deeply clever type-level code can become a bottleneck if only its original author can confidently modify it. I generally favor the simplest type that solves the actual problem, reserving more advanced techniques for cases where the safety or ergonomics genuinely justify the added complexity.

I'd first distinguish whether the friction comes from genuinely necessary type safety catching real bugs, or from type definitions that are more rigid or complex than the actual problem calls for. Simplifying overly restrictive types, introducing better utility types or helper functions to reduce repetitive type annotations, or adjusting specific strictness settings for a well-justified reason are all reasonable responses, rather than treating every point of friction as something the team just needs to push through.

Structural typing's flexibility is generally a strength for rapid development, but at scale it can let subtly incompatible types pass checks simply because they share a similar shape, which sometimes only becomes apparent well after the code has shipped. I'd encourage deliberate use of branded types or more explicit domain modeling for the identifiers and values where that kind of accidental structural compatibility would actually be dangerous, without over-applying that discipline everywhere it isn't needed.

I'd look past whether teams are simply using .ts file extensions and check for signals like widespread use of any, loose strictness settings, or types that are so permissive they don't actually catch meaningful errors. Auditing a sample of codebases for real type coverage and strictness configuration gives a much more honest picture than assuming TypeScript adoption alone means type safety is genuinely being realized.

I'd weigh the frequency of API changes and the number of consumers who'd otherwise need to manually keep their types in sync against the setup and maintenance cost of a code generation pipeline. For an API that changes frequently and has many internal consumers, automated generation pays for itself quickly by eliminating a whole category of drift bugs, while a small, rarely changing API might not justify the tooling investment.

I'd evaluate each area on its own merits, TypeScript's benefits are strongest where a team is already JavaScript-centric and getting cross-stack type sharing, versus areas where a different language is genuinely better suited to the problem, like heavy numerical computation. Forcing TypeScript everywhere purely for consistency, when it's a poor fit for a specific domain, tends to create more friction than the consistency is worth.

I'd avoid trying to fix it all at once and instead prioritize the highest-risk or highest-traffic parts of the codebase first, using tools that can measure and track any usage or type coverage over time to show visible progress. Making stricter settings the default for new code while grandfathering existing code under a migration plan tends to be more sustainable than a disruptive, all-at-once cleanup effort.

I look for evidence that types are actually catching real bugs and shaping better API design, rather than being treated as a formality developers write to satisfy the compiler with minimal thought. Reviewing whether types are precise and meaningful, versus loosely typed with any scattered throughout, gives a much clearer signal than simply confirming a codebase uses TypeScript at all.

I'd pair the inherently hard-to-quantify prevented-bugs argument with concrete, visible signals that are easier to point to, faster onboarding for new engineers, fewer production incidents traced back to type mismatches, better refactoring confidence measured by how often large changes ship without unexpected regressions. Grounding the case in specific before-and-after examples from the organization's own history tends to be more persuasive than an abstract argument about type safety's general value.

I'd track TypeScript's release notes and roadmap as part of ongoing technical risk management, and maintain a deliberate, tested upgrade cadence rather than either freezing on an old version indefinitely or upgrading immediately on every release without validation. A codebase that falls too far behind current TypeScript versions eventually faces a much harder, riskier upgrade than one that's kept reasonably current through smaller, regular version bumps.

I'd benchmark less against the mere fact of TypeScript adoption, which is now fairly standard, and more against how deeply and effectively it's actually used, type coverage, strictness discipline, shared tooling maturity, compared to peer organizations. Genuine advantage tends to come from disciplined, well-supported usage rather than the adoption decision itself, so I'd focus improvement efforts there rather than treating the initial adoption as the finish line.

I'd weigh the current cost of the problem it solves, type drift between services, manual synchronization errors, developer time spent hand-writing types that could be generated, against the ongoing maintenance burden of building and running that tooling itself. A pilot on one or two high-friction integration points gives real data on the tooling's actual value before committing to a broader organizational rollout.

I try to get them reasoning about types the same way they'd reason about any other design decision, weighing the cost of writing and maintaining a more elaborate type against the actual risk or ambiguity it protects against. Reviewing real production bugs that a stronger type would have caught, alongside examples of overly complex types that added maintenance burden without proportional benefit, builds that judgment faster than abstract guidelines alone.

I'd push for a small, contained pilot rather than a binding upfront decision, letting the team gather real evidence on maintainability and developer experience before committing broadly. Framing the discussion around what concrete evidence would change each person's mind tends to move things forward faster than a purely principled argument grounded in preference.

Early on, I'm comfortable with looser strictness settings and some deliberate type-safety shortcuts to validate product direction quickly, as long as the team is honest with itself about what's a shortcut versus a considered decision. As the codebase and team mature, I shift the balance toward stronger typing discipline, since the cost of loose typing compounds much faster once a codebase has real scale and more engineers touching it.

I'd point to the compounding cost of every engineer individually fighting friction that a shared investment could solve once, slow compile times, inconsistent type quality across services, repeated onboarding confusion about typing conventions. That investment tends to pay for itself once an organization crosses a meaningful size, and I'd frame the case around engineering velocity and consistency rather than technical elegance alone.

I watch for signals that a standard has become a source of friction disproportionate to the value it still provides, teams routinely requesting exceptions, or the standard clearly reflecting assumptions from an earlier, different stage of the organization's growth. Revisiting a standard periodically with the teams who actually live under it, rather than treating it as permanently fixed, keeps standards serving the organization rather than the other way around.

I weigh how someone reasons about type design tradeoffs, when a stronger type is worth the complexity versus when it's overkill, over how many advanced type-level tricks they can demonstrate. Walking through a real typing problem they solved, and the reasoning behind the approach they chose over alternatives, tells me far more about their judgment than a quiz on obscure type system trivia.

I focus on concrete, business-relevant outcomes, fewer production incidents traced to type mismatches, faster and safer refactoring, better onboarding for new engineers joining an unfamiliar codebase, rather than describing the type system in purely technical terms. Grounding the case in the organization's own past incidents that stronger typing would have caught tends to land better than an abstract argument about type safety's general merits.

I push for that knowledge to become documentation, shared tooling, and broader team familiarity well before it becomes urgent, rather than staying locked in one or two people's heads. Pairing a senior engineer with someone earlier in their career on the trickiest typing problems, rather than always having the expert handle it solo, spreads the knowledge naturally instead of relying on a single point of failure remaining available indefinitely.

Standardization earns its place where inconsistency creates genuine risk or cost, core strictness settings, shared type definitions for cross-team data. Beyond that, I'd rather let teams exercise their own judgment on typing style within their own codebases than impose uniformity that mostly serves aesthetic consistency. The test I use is whether a given standard is protecting something concrete or just making the codebase look tidier.

I try to lead with specific, observable consequences rather than a general critique, pointing to the maintainability or onboarding cost the current approach is actually producing rather than framing it as a judgment on the original decision. Most engineers respond well to being shown a concrete problem and invited to help solve it together, rather than being told after the fact that their design was wrong.

The work shifts from personally writing the cleverest types to multiplying the organization's effectiveness, through better shared standards, mentoring, and tooling that makes strong typing the easy default rather than something every engineer has to reason through from scratch. I measure my own impact less by types I've personally written and more by whether the broader codebase and the engineers working in it are genuinely healthier than before I got involved.

I'd start by understanding specifically what went wrong the first time, rushed timelines, inadequate tooling, insufficient buy-in, rather than assuming skepticism is simply resistance to change. Demonstrating a different, better-executed approach on a small, contained scope first, with visible success, tends to rebuild trust far more effectively than arguing in the abstract that this time will be different.