Implement MyParameters<T> using conditional types and infer
Tests if you can extract parameter types with infer. A strong answer matches T against a callable signature, uses infer to bind parameters into a tuple, and defaults to never for non-functions. Red flag: using any or indexing without inference.
What's really being asked
This question tests your understanding of conditional types and type inference in TypeScript's type system. Specifically, it checks whether you know how to use the extends keyword to pattern-match against a function shape, and how infer creates a type variable that captures a piece of that shape without explicit generic parameters. It also reveals whether you understand deferred type resolution, where the compiler waits until the checked type is concrete before resolving the inferred variable. Senior candidates should also mention that infer can only appear in the extends clause of a conditional type.
The full answer
First, the exact type definition: type MyParameters<T> = T extends (...args: infer P) => any ? P : never. Second, an explanation that infer P declares a type variable inside the extends clause that binds to the parameters tuple only when T is assignable to a function type. Third, the fallback branch never, which prevents non-function types from producing a valid tuple and maintains strictness. Fourth, a note on deferred resolution: the conditional type is not evaluated immediately for a generic T, but rather distributed or resolved once T is known at the call site, making the utility lazy.
The mistakes people make
A common mistake is writing T extends Function ? T["length"] or trying to index T without inference, which fails because the global Function type has no callable parameter tuple. Another red flag is omitting the never fallback, which can cause unexpected assignability issues when MyParameters is used with union types or non-functions. Some candidates treat infer as a generic parameter, writing <infer P> or similar, which is a syntax error. Others use any as the return type in the function pattern but forget that the pattern itself must be a valid function type signature for the match to succeed.
What usually comes next
An interviewer might ask what happens with overloaded functions, in which case MyParameters would typically infer the parameters from the last overload signature. They might also ask about the distributive behavior of conditional types over unions, leading to MyParameters<(() => void) | ((x: string) => void)> producing never | [x: string]. Another follow-up is implementing ReturnType<T> by inferring the return position instead of the parameters, or asking why the return type in the pattern is any rather than unknown.
A concrete example
Consider type Fn = (name: string, age: number) => void. Applying MyParameters<Fn> resolves as follows: Fn extends (...args: infer P) => any is true, so P is bound to [name: string, age: number]. The result is the tuple [name: string, age: number]. If you instead pass a non-function like string, the condition fails and the result is never, preserving type safety and preventing invalid usage downstream.
Interview question
Which statement accurately describes a constraint on the infer keyword when implementing MyParameters<T>?
- a.infer must appear inside the extends clause of a conditional typeCorrect
- b.infer creates a globally scoped type variable visible outside the conditional
- c.infer can be used anywhere a generic type parameter is declared
- d.infer requires an explicit generic parameter declaration like <infer P>
Why? this is the answer
The card states that infer can only appear in the extends clause of a conditional type. Distractor D is tempting because candidates often confuse infer with generic parameter syntax, but writing <infer P> is a syntax error.
Just read this? Test yourself on what you have been reading.
Read the original → typescriptlang.org
- #typescript
- #conditional-types
- #infer
- #generics
- #utility-types
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on typescript — each one lists the topics its interview covers.
See open roles