Concept questionMedium~7 min

Interview question

How do generics and constraints make a TypeScript API reusable without weakening its contract?

Uses generics to preserve relationships between types and constraints to express the operations an implementation requires.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

A generic lets an API express a relationship between types chosen by the caller. For example, an identity function returns the same type it receives rather than unknown. A constraint states what the implementation needs, such as requiring an id property, while preserving the rest of the caller's more specific type.

Full answer below

Practice focus

Whether the candidate can distinguish meaningful type relationships from decorative generic parameters.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Overview
A useful generic preserves information between inputs and outputs. It should not merely replace a concrete type with a letter.
A generic lets an API express a relationship between types chosen by the caller. For example, an identity function returns the same type it receives rather than unknown. A constraint states what the implementation needs, such as requiring an id property, while preserving the rest of the caller's more specific type.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For a table component, Table<Row> can accept Row[] and column definitions whose keys must belong to Row. That is stronger than accepting arbitrary strings and casting during render. I add the fewest constraints needed by the implementation; if the function never reads a property, constraining the type to include it adds ceremony without safety.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I watch inference and variance at callback boundaries. An API can be technically generic yet infer an unusably broad union or allow an unsafe callback if its types do not reflect input and output direction. I test the public type surface with representative calls, including expected compile failures. When a generic signature becomes harder to explain than the domain operation, overloads or a small explicit contract may be the better design.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using a generic parameter only once where unknown would be clearer.
Replacing a useful relationship with any.
Adding constraints unrelated to implementation needs.
Building a type signature too complex for callers to understand.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

The implementation casts away the guarantees promised by the signature.
Generic inference produces broad or unstable public types unnoticed.
The answer presents complexity itself as stronger typing.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is a generic parameter unnecessary?
How would keyof help a column definition?
When would overloads be clearer?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

2 linked

Next in path

Move forward in the planned practice sequence.

Interface vs type aliasContinue from reusable relationships to naming public contracts.

Prerequisite

Review this first if the current drill feels shaky.

Structural typingUse structural compatibility as the basis for constraints.

Practice route

Read core answer Review checklist Follow-up prompts Track progress

Finished this drill?

Practice freely. Sign in only when you want to save completion, confidence, notes, or bookmarks.

New to Aporeon? Create account

Drill details

Human editorial direction

Aporeon is shaped by Aleksandar Tomovski, a software developer with experience on both sides of technical interviews. Content is reviewed for accuracy, natural spoken delivery, useful depth, and honest trade-offs.

About the creator Editorial standards

Was this drill useful?