A TypeScript function can take in parameters of multiple, predefined types using union types.
We have a utility function formatValue that should accept either a string or a number and return a string. How would you write its TypeScript signature?
If you call formatValue(true), what error does TypeScript give and why?
You need to implement a parseInput function that can take either a JSON string, a Buffer, or an object conforming to an interface User. How would you type its parameter and ensure correct handling inside the function?
During a code review you notice that a function overloaded to accept Date | string is failing when a null value is passed. Explain why the current overloads don't cover this case and how you'd fix it.
Our team is building a shared SDK that exposes several functions which accept configuration objects that can be of different shapes (e.g., HttpConfig or WebSocketConfig). How would you design the type definitions to allow future extensions without breaking existing callers, and what trade‑offs does your approach have?
We observed a performance regression after adding a generic helper that uses conditional types to narrow parameter types. Explain potential compile‑time vs runtime impacts and how you would mitigate them.
The company is migrating a monolith to micro‑services and wants a common TypeScript contract for API request payloads that can be one of many predefined types. Describe how you'd structure the type system (e.g., discriminated unions, branded types) to support versioning, backward compatibility, and tooling integration across teams.
Several teams have independently added overloads to a core fetchData function, leading to conflicting signatures. As a staff engineer, how would you refactor the API to provide a single, extensible type definition while minimizing breaking changes?