TypeScript Enums — Complete Interview Guide

Numeric Enums

Numeric enums auto-increment from 0 by default. Each member maps to a number, and TypeScript generates a bidirectional mapping object:

enum Direction {
  North,  // 0
  South,  // 1
  East,   // 2
  West,   // 3
}

// Compiled JavaScript (note bidirectional mapping):
// var Direction;
// (function (Direction) {
//   Direction[Direction["North"] = 0] = "North";
//   Direction[Direction["South"] = 1] = "South";
//   Direction[Direction["East"]  = 2] = "East";
//   Direction[Direction["West"]  = 3] = "West";
// })(Direction || (Direction = {}));

Direction.North;     // 0
Direction[0];        // "North" — reverse mapping
Direction["North"];  // 0

// Custom starting values
enum HttpStatus {
  OK          = 200,
  NotFound    = 404,
  ServerError = 500,
}

// Computed members — evaluated at runtime
enum FileAccess {
  None,
  Read    = 1 << 1,  // 2
  Write   = 1 << 2,  // 4
  ReadWrite = Read | Write, // 6
}

String Enums

String enums have no reverse mapping and produce more readable serialized values — preferred for any value that may appear in logs, API payloads, or URLs:

enum Status {
  Active   = "ACTIVE",
  Inactive = "INACTIVE",
  Pending  = "PENDING",
  Deleted  = "DELETED",
}

// Compiled JavaScript:
// var Status;
// (function (Status) {
//   Status["Active"]   = "ACTIVE";
//   Status["Inactive"] = "INACTIVE";
//   Status["Pending"]  = "PENDING";
//   Status["Deleted"]  = "DELETED";
// })(Status || (Status = {}));

// Usage — the value in API responses is readable
const user = { status: Status.Active }; // { status: "ACTIVE" }
Status.Active === "ACTIVE"; // true
Status["ACTIVE"]; // undefined — no reverse mapping for string enums

Const Enums — Inlined at Compile Time

Const enums are erased entirely — every reference is replaced with its literal value during compilation:

const enum Direction {
  North = "NORTH",
  South = "SOUTH",
  East  = "EAST",
  West  = "WEST",
}

// Usage in code:
const dir = Direction.North;

// Compiled JavaScript — no enum object, value is inlined:
// const dir = "NORTH"; // Direct substitution

// Benefits: zero runtime overhead, smaller bundle
// Drawbacks:
//   - Cannot iterate over const enum members at runtime
//   - Breaks when used across module boundaries (isolatedModules: true disallows them)
//   - Incompatible with Babel and esbuild (they don't do full semantic analysis)

Enums vs Union Literal Types

The most debated TypeScript topic for beginners. Union literals achieve the same compile-time safety with fewer surprises:

// Enum approach
enum Status { Active = "ACTIVE", Inactive = "INACTIVE" }
function setStatus(status: Status) { /* ... */ }
setStatus(Status.Active);  // OK
setStatus("ACTIVE");       // Error — string literal not assignable to Status!

// Union literal approach
type Status = "ACTIVE" | "INACTIVE";
function setStatus(status: Status) { /* ... */ }
setStatus("ACTIVE");   // OK — plain strings work
setStatus("INVALID");  // Error — not in the union

// The enum version rejects plain strings — even "ACTIVE" is invalid!
// This is intentional for strict enum usage, but surprises many developers
// Union literals interop naturally with JSON, APIs, and external strings

// When to still use enums:
// 1. Numeric bit-flag collections (FileAccess.Read | FileAccess.Write)
// 2. Large sets of related constants that benefit from a namespace
// 3. Legacy codebases where consistency matters more than strict mode
// 4. When reverse mapping (Direction[0] === "North") is genuinely needed

Ambient Enums — Declaration Only

// In a .d.ts file or declare block — no code emitted
declare enum ExternalStatus {
  Active = 0,
  Inactive = 1,
}

// Tells TypeScript about an enum defined in another file/library
// without re-creating the runtime object