TypeScript allows you to specify the types of both the input and output values of functions.
We have a simple utility function function add(a, b) { return a + b; }. How would you add TypeScript annotations so that it only accepts numbers and returns a number?
If you forget to annotate the return type of a function that returns a Promise, what does TypeScript infer, and how would you explicitly annotate it?
You're adding a new API client method fetchUser(id) that can accept either a string ID or a number ID and returns a User object. How would you write the function signature with proper overloads or union types?
During a code review you notice a function that uses any for its parameters to avoid type errors, but the team wants stricter typing. How would you refactor the function to use generics while preserving its flexibility?
Our front‑end library exposes a higher‑order component withLoading that wraps any component and injects loading props. How would you type annotate this HOC to preserve the wrapped component’s props and ensure correct inference for consumers?
We have a performance‑critical data‑processing pipeline where functions are composed at runtime. What trade‑offs do you consider when deciding between explicit function type annotations versus relying on inference, especially regarding bundle size and compile‑time checking?
The company is migrating a large JavaScript codebase to TypeScript. How would you establish a strategy for annotating existing functions, balancing the need for immediate safety with the overhead of writing exhaustive signatures?
Multiple teams share a common utilities package that includes many generic helper functions. What guidelines would you set for function type annotations to keep the API stable, avoid breaking changes, and support future extensions?