Type a compose function using generics and overloads

WHAT THIS TESTS: This question probes whether you can model dependent type relationships across a variadic higher-order function. Specifically, the interviewer wants to see if you know how to make the return type of each composed function become the parameter type of the next, and how to surface the original input and final output in the resulting function signature. It is a practical test of generic inference, contravariance in parameters, and the limits of TypeScript's type system.

A GOOD ANSWER COVERS: First, state that a single generic signature cannot express the pairwise chaining required for arbitrary compose arity. Second, describe using function overloads: one overload for a single function taking Input and returning FirstArg, another for two functions where the second takes FirstArg and returns SecondArg, and a third for three functions where the third takes SecondArg and returns ThirdArg. Third, note that the actual implementation can be stubbed with any because the overloads provide the public type contract. Fourth, emphasize that this structure lets TypeScript infer the composed function's parameter and return types without manual annotation, and it rejects invalid pipelines at compile time.

COMMON WRONG ANSWERS: A common wrong answer is proposing one generic rest parameter like an array of functions with any which erases all intermediate types and makes the compose function unsafe. Another red flag is trying to use a mapped type or conditional type recursion without explaining why overloads are the pragmatic choice for this library boundary. Some candidates also forget that the implementation signature must be compatible with the overloads, or they omit the Input generic and hardcode unknown for the initial parameter.

LIKELY FOLLOW-UPS: The interviewer might ask how you would extend this to support more than three functions, or whether variadic tuple types could replace overloads in newer TypeScript versions. They might also ask how to type a pipe function versus compose, or how to preserve this-context and generic function identity through the composition.

ONE CONCRETE EXAMPLE: Imagine three functions: addOne takes a number and returns a number, numToString takes a number and returns a string, and stringToNum takes a string and returns a number. With overloads, compose(addOne, numToString, stringToNum) infers a final signature of a function from number to number. If you incorrectly try compose(numToString, addOne), TypeScript errors because addOne expects a number, not the string output by numToString.