TypeScript Interview Questions

"TypeScript adds a type checker on top of JavaScript. The big win for a team is that a whole class of mistakes shows up in the editor instead of in production: a typo in a property name, passing a string where a number is expected, forgetting that something can be undefined. It also makes refactoring much safer, because when I rename a field the compiler points at every place that breaks. The honest limit is that all of this happens at compile time. The types are stripped out and what runs is plain JavaScript. So if an API sends back a different shape than my type says, TypeScript won't notice. For anything coming from outside the program I still need runtime checks. The cost is a build step and time spent writing types, which pays off most on bigger codebases and teams."

"For plain object shapes they're nearly interchangeable. Both can describe a user object, both can be extended, an interface with extends and a type with an intersection, and a class can implement either. The real differences are at the edges. An interface can be declared twice and the two declarations merge, which is how libraries let you add fields to things like the global Window. A type alias can't be reopened, but it can name anything: a union like 'loading' | 'done', a tuple, a primitive, or a mapped or conditional type. An interface can only describe an object shape. In practice I follow the team's convention. A common one is interface for object shapes and public APIs, and type for unions and computed types. Being consistent matters more than which one wins."

"All three sit at the edges of the type system. any means stop checking. I can call anything on it, assign it anywhere, and mistakes slip through. Worse, the any leaks into whatever I derive from it. unknown also accepts any value, but it's the safe version: I can't do anything with it until I narrow it with a typeof check, an instanceof or a type guard. That makes it the right type for parsed JSON, caught errors and anything else from outside. never is the other end, a type with no possible values. A function that always throws returns never, and if I narrow a union until nothing is left, what remains is never. I use that on purpose in a switch's default branch, assigning the value to a never variable, so the build fails if someone adds a new case and forgets to handle it."

"A union says the value is one of several types. A status typed as 'idle' | 'loading' | 'error' is a union, and so is a parameter that takes string | number. The catch is that on a union I can only use what every member has, so before calling toUpperCase on string | number I have to check it's a string. An intersection goes the other way: the value has all the properties of both types. I use it to combine shapes, like a User intersected with an object holding a permissions array for an admin view. The trap is conflicts. If one side says id is a string and the other says it's a number, id becomes never and no value can fit. The names feel backwards at first: a union of object types gives you fewer usable properties, an intersection gives you more."

"Structural typing means TypeScript compares shapes, not names. If a function wants a Point with x and y, any object with a numeric x and y is accepted, even if it was declared as a different type and has extra fields. That's unlike Java or C#, where the declared class matters. It surprises people in two ways. First, excess property checks only fire on a fresh object literal. If I pass an object literal with an extra z field straight into the function, I get an error, but if I put that same object in a variable first and pass the variable, it's accepted. Second, two types with the same shape are interchangeable, so a user ID string and an order ID string can be mixed up. When that matters, I use a branded type, so the compiler keeps them apart."

"Normally TypeScript widens literals. If I write const roles equals an array of 'admin' and 'editor', the type is string[], because arrays can change. Adding as const tells the compiler to treat the whole thing as a fixed value: the array becomes a readonly tuple of exactly those strings, and object properties become readonly with their literal values, nested ones included. The pattern I use a lot is to write the list once as a runtime array with as const, then get the type by indexing typeof roles with number, which gives the union 'admin' | 'editor'. Now I can loop over the array to render a dropdown and use the type to check function arguments, and adding a role in one place updates both. It's a nice alternative to an enum. The one thing to remember is that I can't push to that array later."

"An enum is one of the few TypeScript features that isn't only types. It compiles to a real JavaScript object, and a numeric enum also gets a reverse mapping, so you can look up a name from its number. A union of string literals like 'draft' | 'published' is erased completely. My default is the union. The values are plain strings, so they match JSON from an API without converting, and nothing extra ships. With a string enum, even though the value is 'draft', I can't pass the plain string 'draft' where the enum is expected, which gets awkward at API boundaries. If I need the values at runtime, to loop over them, I pair the union with an as const array or object. Enums are fine if the team likes them, but I'd avoid const enums in projects built by tools that compile each file on its own, since those tools can't inline them across files."

"TypeScript follows the flow of the code and narrows the type in each branch. With string | number, after if typeof x equals 'string', it knows x is a string inside the block, and a number after it if that block returns early. typeof works for primitives, with the known trap that typeof null is 'object'. For class instances I use instanceof, like checking whether an error is an HttpError. The in operator checks a property exists, so checking 'swim' in animal narrows to the types that have swim. Equality narrows too: comparing to null removes null, and comparing a status field to a literal picks one member of a discriminated union. Truthiness works but is risky, since if count also drops zero and if name drops an empty string. The compiler also tracks early returns and reassignments, so the order of my checks matters."

"A type guard is a function whose return type is a predicate like value is User. When I call it in an if, the compiler narrows the argument to User inside that branch. That's how I turn unknown data into a typed value, and it also works with filter to drop nulls from an array. The risk is that TypeScript takes my word for it. It doesn't check that the body proves what the predicate claims. If my isUser only checks that the value is an object, every caller now believes there's a name and an email, and the bug shows up far away. So I keep guards small, check every field I rely on, and unit test them with bad inputs. There's also an assertion form, asserts value is User, which throws on bad data and narrows everything after the call. That's handy at the top of a request handler."

"A discriminated union is a union of object types that all share one field with a literal value, like kind: 'circle' or kind: 'square'. When I switch on that field, TypeScript narrows to the exact member, so in the circle case I can read radius and it knows there's no side. I use it a lot for request state: idle, loading, success with data, error with a message. Then it's impossible to have data and an error at once, which a bag of optional fields would allow. To make it exhaustive, in the default branch I assign the value to a variable typed never. If every case is handled, nothing is left and that compiles. The day someone adds a triangle and forgets it, the triangle reaches the default, can't be assigned to never, and the build fails right where the fix belongs."

"An annotation checks and then takes over: the value must fit the type, and from then on the variable has the declared type, so the exact keys TypeScript would have inferred are lost. An as assertion is me overruling the compiler. It checks nothing at runtime, and it's only refused when the two types can't possibly overlap, which is why people chain as unknown as something, a big warning sign. The non-null exclamation mark is a smaller version: it strips null and undefined because I say so, and if I'm wrong, it crashes at runtime. satisfies is newer and my favourite for config objects. It checks the value against a type, so typos and missing fields are caught, but the variable keeps its own inferred type. So a routes object that satisfies a Record of routes still gives me autocomplete on its real keys, which an annotation would throw away."

"With any, a function can accept everything, but it throws the information away. If first takes an any array and returns any, the caller gets any back, and a mistake on the result goes unnoticed. A generic keeps the link. If first takes an array of T and returns T or undefined, then passing strings gives back a string or undefined, and passing users gives back a user. The type parameter is like a variable for types, filled in at each call, and callers almost never write it because TypeScript infers it from the argument. Generics are everywhere: arrays, promises, useState, an API helper that returns a promise of T. My test is simple: does the output type depend on the input type? If yes, it's a generic. If the function truly doesn't care about the type, unknown is often better than a type parameter."

"A constraint limits what a type parameter can be. Without one, T could be anything inside a generic function, so I can't even read length on it. If I write T extends an object with a numeric length, I can, and callers can pass strings or arrays but not numbers. The classic example is a getProperty function. I take two type parameters, T for the object and K extends keyof T for the key. Now the compiler rejects a key that doesn't exist on the object, and the return type is T indexed by K, so getting 'age' from a user gives a number and getting 'name' gives a string. That's far better than returning any. Notice that a constraint can refer to another type parameter, which is exactly what K does here. I can also give a default, like T equals unknown, for when nothing is inferred."

"They all build new types from existing ones, so I don't copy shapes by hand. Partial makes every property optional. I use it for an update function where the caller sends only the fields that changed. Pick keeps just the keys I name, like Pick of User with id and name for a list view. Omit is the reverse. A common one is omitting passwordHash for what goes to the client, or omitting id for a create form where the database makes the id. Record builds an object type from a set of keys and a value type, like a Record from Status to string for a label per status, and if Status is a union, it forces every key to be present. One quirk worth knowing: Omit accepts any key, even one that doesn't exist on the type, so a typo there silently does nothing."

"A mapped type loops over the keys of another type and builds a new property for each one. The syntax is K in keyof T, mapped to T indexed by K, which on its own just copies T. To write Partial, I add a question mark after the key, so every property becomes optional. Readonly is the same idea with the readonly modifier in front. You can also remove modifiers with a minus sign: minus question mark makes everything required, which is how Required works, and minus readonly gives a Mutable helper that isn't built in. Two things I'd point out. These are shallow, so a nested address stays fully required inside a Partial user. For deep versions I'd recurse when the property is an object, taking care with arrays and functions. And because the mapping is over keyof T, the original optional and readonly flags carry across unless I change them."

"These three let me derive types instead of writing them twice. typeof in a type position takes a runtime value, say a config object, and gives me its type. keyof takes an object type and gives the union of its keys, so keyof Config might be 'port' | 'host' | 'debug'. Indexed access reads a property's type the way brackets read a value: Config of 'port' is number. Put together, Config indexed by keyof Config is the union of all the value types. A real case: I have a const object of API endpoints. I use typeof to get its type, keyof on that to get the valid endpoint names, and a function that only accepts one of those names. Now adding an endpoint to the object makes it valid everywhere without touching a type. Indexing an array type with number works the same way and gives the element type."

"A conditional type is an if statement for types: T extends U, question mark, X, colon, Y. If T is assignable to U you get X, otherwise Y. infer lets me capture part of a type while matching. For ReturnType, I check whether T is a function type with a return type I call infer R, and if it is, the result is R, otherwise never. The same trick unwraps an array's element type or a promise's value. The subtle part is distribution. When the checked type is a bare type parameter and you pass in a union, the condition runs on each member separately and the results are joined. So ToArray of string | number gives string[] | number[], not one mixed array. That's usually what you want, it's how Exclude works, but when it isn't, wrapping both sides in square brackets turns distribution off."

"I'd write a mapped type over keyof T with an as clause, which lets me rename each key as I go. The new name is a template literal type: the word get followed by the key with its first letter capitalised, using the built-in Capitalize helper. The value becomes a function with no arguments that returns T indexed by K. One detail: keyof T can include number and symbol keys, and Capitalize only takes strings, so I intersect K with string, which quietly drops the others. For a Person with name and age, I get getName returning string and getAge returning number. The same as clause is handy for filtering: if I remap a key to never, it disappears. That's how I'd build a type with only the data fields of an object and none of its methods."

"A .d.ts file is a declaration file. It holds only types, no implementation, and tells the compiler what a piece of JavaScript looks like. When I publish a TypeScript library, the compiler generates them with the declaration option, so the JavaScript ships alongside its types. When I install a package, types come from one of two places: the package includes its own, usually listed in its package.json, or there's a community package under the @types scope that I add as a dev dependency. If neither exists, I don't spread any across the codebase. I write a small declaration file with declare module and the package name, and describe just the functions I actually use. The quick escape hatch is a one-line declare module with no body, which types the whole package as any. That's fine for a spike, but I'd flag it to replace."

"It works through declaration merging. Interfaces with the same name merge, so I can reopen an interface someone else declared and add fields. For the global Window, I create a declaration file, make it a module by adding an empty export, and inside declare global I declare interface Window with the new property. For a library, it's module augmentation: declare module with the package's name, then reopen the interface it exports, like a request or theme type. What trips people up is usually the file not being picked up. If it isn't a module, declare global is an error. If it isn't inside the include paths in tsconfig, nothing happens and the property is just missing. And I have to reopen an interface, because type aliases don't merge. Augmentation can extend what's there, but it can't add brand new top-level declarations to someone else's module."

"strict isn't one check, it's a switch for a family of them. The main ones are noImplicitAny, which stops parameters quietly becoming any, strictNullChecks, strictFunctionTypes for safer checks on function parameters, strictPropertyInitialization, which makes class fields get a value where they're declared or in the constructor, and useUnknownInCatchVariables, which types caught errors as unknown. The one that matters most to me is strictNullChecks. Without it, null and undefined are allowed everywhere, so the compiler never warns that a find call might return nothing, and that's one of the most common crashes in JavaScript. With it on, I have to handle the missing case. New compiler versions can add flags to the strict family, so an upgrade can surface new errors. And some useful checks aren't included: noUncheckedIndexedAccess, which adds undefined when reading an array or record by index, is one I turn on in new projects."

"I write a props type and annotate the destructured parameter with it. Optional props get a question mark, and I set defaults right in the destructuring, so variant defaults to primary and the rest of the component never sees undefined. For children I use React.ReactNode, which covers text, elements, arrays and null. For event handlers I use React's event types: an input's change handler gets a ChangeEvent of HTMLInputElement, so event.target.value is typed as a string. When I wrap a native element, like a custom Button, I extend the button's component props so callers can pass type, disabled and aria attributes without me listing them. I rarely use React.FC now. In current type definitions it no longer adds children for you, and a plain function with typed props is simpler. For state, useState infers from the initial value, and I pass a type when it starts as null."

"I make the props generic, ListProps of T, with items as an array of T, renderItem as a function from T to a React node, and getKey as a function from T to a string for React's keys. Then the component itself is a generic function taking ListProps of T. The nice part is on the calling side. When someone renders List with an array of users, TypeScript infers T as User from the items prop, so inside renderItem the parameter is already a User, with autocomplete and an error if they reach for a field that doesn't exist. Nobody writes a type argument by hand. One gotcha: as an arrow function in a .tsx file, angle bracket T looks like a JSX tag, so I write T followed by a comma or use a function declaration. And wrapping it in memo can lose the type parameter, so that needs a little extra typing."

"The body from fetch comes back as any. If I write as User, I've told the compiler something it can't check, and when the backend renames a field, my code compiles fine and breaks in production with undefined everywhere. So at the boundary I treat the response as unknown and validate it. For small cases, a type guard. For anything bigger, a schema library, where I describe the shape once, parse the response against it and get the TypeScript type from the schema, so the check and the type can't drift. If the backend publishes an OpenAPI spec, I'd rather generate types from it in the build. I also wrap calls so they return a discriminated union, either ok with data or not ok with an error, so every caller has to handle failure instead of assuming the happy path."

"At my last company we had a mid-sized JavaScript front end, and most production bugs were undefined errors from API data. A rewrite was out of the question, so I proposed a gradual move. We turned on allowJs so TypeScript and JavaScript could live side by side, started with loose settings, and set one rule: new files are TypeScript. Then we converted from the leaves up, utilities and the API client first, because typed API responses paid off everywhere else. Each sprint we took a few folders. Once most files were converted, we turned on strictNullChecks and fixed it area by area, and later full strict. I added a lint rule that flagged new explicit any, so that count only went down. Over a few months the null crashes in our error tracker dropped sharply. I'd generate the API types from a spec from day one next time."

"In one project, a billing dashboard started showing strange totals for some customers, numbers that looked stuck together, while TypeScript was completely happy. I traced it to the API client. The response was cast with as Invoice, and the backend had started sending the amount as a string for some older records. Our type said number, so nothing flagged it, and adding a string to a number just joined them as text. The quick fix was converting the amount. The real fix was stopping the lie at the boundary: we replaced the cast with runtime validation on that endpoint, so a bad shape now logs a clear error instead of flowing through the app. Then I searched for other as casts on fetched data and listed them to fix. My lesson: the compiler is only as honest as the edges where data comes in."

"I once built a typed form helper for our team with deep conditional and mapped types, so every field path like address.city was checked and inferred. It worked and I was proud of it, but a few weeks later teammates were complaining. Error messages ran to pages that nobody could read, and the editor got sluggish in big forms. I ran the compiler with its extended diagnostics and saw type checking time had jumped on those files. So I simplified. I capped how deep the path types went, added explicit return types on the public functions so the compiler didn't recompute them everywhere, and swapped one clever inferred type for a plain interface people could read. We lost a little precision and gained a lot of trust. My rule now: a type is for the people using it, and if its error can't be understood, it isn't finished."

"I'd start by reading what the suppressed errors actually say, because ts-ignore hides the message, not the problem. Often one or two are real bugs, a value that can be undefined or a wrong argument, and those I'd want fixed before merging, deadline or not. For the ones that are just awkward typing, like a library with poor types, I'd suggest swapping ts-ignore for ts-expect-error with a short reason. The difference matters: ts-expect-error fails the build once the error goes away, so it can't linger forever, while ts-ignore also silences any new error on that line. Then I'd agree a follow-up ticket to remove the casts, and propose a lint rule that requires a description on these comments. I'd have the conversation on a call, framed as protecting the release, not as a lecture."

"I wouldn't flip it on for everyone at once. First I'd measure: turn on each strict flag separately and count errors per flag and per folder. Usually a couple of flags and a few folders account for most of it. Then I'd go one flag at a time, starting with the one that catches the most real bugs, usually strictNullChecks. Because even one flag can mean thousands of errors, I'd use a ratchet: record the current errors as a baseline and make CI fail if any file gets new ones. New code is clean from day one and the old count can only go down. I'd start with the code that matters most, like payments and API handling, and ask each team to clean one area per sprint rather than hold a big cleanup week. The goal is steady progress, with a date when the old settings go away."

"First I'd make sure it's really the types and not my understanding, by checking the docs and logging what the function actually returns. If the types are wrong, I keep the workaround in one place. Usually that's a small wrapper module that calls the library and exposes correct types, with a single cast inside and a comment explaining why. If it's just a missing field on an interface, a module augmentation in a declaration file can add it cleanly. What I avoid is casting at every call site, because then nobody can tell which casts are workarounds and which are hiding bugs. Then I'd fix it at the source: open an issue or pull request on the library or its community types package, and link it in the comment so whoever reads the workaround knows when it can go."