Mock interview

They're the three special types at the edges of the type system.

• unknown is the top type: every value is assignable to it, but you can't do anything with it until you narrow it. It's what you use at boundaries: JSON.parse results, catch variables, untrusted input.
• never is the bottom type: no value has it, and it's assignable to everything. It appears as the return type of functions that throw, as an empty union, and in exhaustiveness checks.
• any isn't really part of the lattice: it opts out of checking. It's assignable to and from everything, and it spreads, because every operation on any produces any.

function parse(json: string): unknown {
  return JSON.parse(json);
}
 
const value = parse("42");
// @ts-expect-error -- 'value' is of type 'unknown'.
value.toFixed();
if (typeof value === "number") value.toFixed(); // fine after narrowing
 
function fail(message: string): never {
  throw new Error(message);
}

The one-liner to end on: "unknown is the safe any: use it whenever you don't know the type yet, and narrow."

For plain object shapes they're mostly interchangeable. The real differences:

Declaration merging is why library authors use interfaces for things users augment (like Window or a plugin registry). A common team rule: interface for object shapes, type for everything else, or just be consistent. Interfaces used to be faster for the compiler in large extends hierarchies, since their relationships are cached.

Start from a map of event names to payload types, then make on and emit generic over the event name so the payload is looked up with an indexed access type:

type Listener<T> = (payload: T) => void;
 
class Emitter<Events extends Record<string, unknown>> {
  private listeners: { [E in keyof Events]?: Listener<Events[E]>[] } = {};
 
  on<E extends keyof Events>(event: E, listener: Listener<Events[E]>): () => void {
    const list = (this.listeners[event] ??= []);
    list.push(listener);
    return () => {
      this.listeners[event] = list.filter((l) => l !== listener);
    };
  }
 
  emit<E extends keyof Events>(event: E, payload: Events[E]): void {
    this.listeners[event]?.forEach((listener) => listener(payload));
  }
}
 
type AppEvents = {
  login: { userId: string };
  logout: undefined;
};
 
const emitter = new Emitter<AppEvents>();
emitter.on("login", ({ userId }) => console.log(userId));
emitter.emit("login", { userId: "u1" });
// @ts-expect-error -- Argument of type '"signup"' is not assignable to parameter of type 'keyof AppEvents'.
emitter.emit("signup", {});

Points to mention: the listener's parameter type is inferred from the event name, so callers never annotate; on returns an unsubscribe function; and the next refinement is making the payload optional for events whose payload is undefined (with a conditional rest parameter like ...args: Events[E] extends undefined ? [] : [Events[E]]).

strict: true turns on a family of flags, and any flag added to the family later turns on automatically when you upgrade:

• strictNullChecks: null and undefined are separate types. The most valuable one.
• noImplicitAny: untyped parameters are errors instead of silent any.
• strictFunctionTypes: function-typed parameters are checked contravariantly.
• strictBindCallApply: bind, call and apply are type-checked.
• strictPropertyInitialization: class fields must be initialised in the constructor.
• noImplicitThis, alwaysStrict, useUnknownInCatchVariables (catch variables are unknown), and strictBuiltinIteratorReturn.

What I'd add on top, and why: noUncheckedIndexedAccess (array and record reads include undefined), exactOptionalPropertyTypes (? means "may be missing", not "may be undefined"), noImplicitOverride, noFallthroughCasesInSwitch, and for modern build setups verbatimModuleSyntax or isolatedModules. On an existing codebase, I'd turn flags on one at a time and fix errors per flag rather than flipping strict in one go.