Evaluating TypeScript proficiency requires going beyond simple JavaScript algorithms with added type annotations. Strong candidates demonstrate type-safe design patterns, zero unnecessary any usage, and proper generic constraints.
Problem 1: Strongly Typed Event Emitter
Implement a type-safe event emitter where event names map to expected payload argument types.
type EventMap = Record<string, any>;
class TypedEventEmitter<Events extends EventMap> {
private listeners: { [K in keyof Events]?: Array<(payload: Events[K]) => void> } = {};
on<K extends keyof Events>(event: K, listener: (payload: Events[K]) => void): void {
if (!this.listeners[event]) {
this.listeners[event] = [];
}
this.listeners[event]!.push(listener);
}
emit<K extends keyof Events>(event: K, payload: Events[K]): void {
const callbacks = this.listeners[event];
if (callbacks) {
callbacks.forEach(cb => cb(payload));
}
}
}
// Usage Example:
interface AppEvents {
userLogin: { userId: string; timestamp: number };
error: { message: string };
}
const emitter = new TypedEventEmitter<AppEvents>();
emitter.on("userLogin", (data) => console.log(data.userId));
// emitter.emit("userLogin", { userId: 123 }); // Error: Type number is not assignable to string*Try the Event Emitter exercise live on Pairlet.*
Problem 2: Type-Safe Result Union (Result<T, E>)
Model success and error outcomes without relying on thrown exceptions.
type Result<T, E = Error> =
| { ok: true; value: T }
| { ok: false; error: E };
function ok<T>(value: T): Result<T, never> {
return { ok: true, value };
}
function err<E>(error: E): Result<never, E> {
return { ok: false, error };
}Problem 3: DeepReadonly<T> Utility Type
type DeepReadonly<T> = T extends Function
? T
: T extends object
? { readonly [K in keyof T]: DeepReadonly<T[K]> }
: T;Problem 4: TypeScript Code Review Challenge
Spot the anti-patterns in the following snippet:
// Flawed implementation:
async function fetchUser(id: any): Promise<any> {
const res = await fetch(`/users/${id}`);
const data = await res.json();
return data as any;
}Issues: Heavy reliance on any, lack of error boundary check on res.ok, and unsafe type assertions.
*Explore the Bad TypeScript Design code review problem on Pairlet.*
Practice TypeScript Interviews
Frequently Asked Questions
Why test TypeScript specific problems instead of plain JavaScript?
TypeScript coding problems evaluate how candidates construct maintainable type contracts, avoid 'any' escape hatches, handle nullability, and model domain data accurately at compile time.
Conduct Live Coding Interviews in the Browser
No candidate sign-up required. Create a room, share the link, and code together in real time with shared code execution.