How would you use an enum to represent API statuses?

WHAT THIS TESTS: This question evaluates whether you understand that TypeScript enums have runtime consequences, not just compile-time types. The interviewer cares about your ability to choose between string and numeric enums when the value crosses an API boundary, and whether you can articulate serialization, debugging, and maintenance trade-offs.

A GOOD ANSWER COVERS: First, declare a string enum where each member is explicitly initialized to the exact string returned by the API, such as PENDING = PENDING. Second, explain that string enums serialize well because the runtime value is human-readable and matches the wire format exactly, which makes debugging logs and network traces straightforward. Third, contrast this with numeric enums, which auto-increment from zero or an explicit seed and produce opaque integers at runtime; if the API instead sends strings, numeric enums force you to maintain a separate mapping layer. Fourth, mention that numeric enums provide reverse mapping, meaning you can go from value to name, but that benefit is usually irrelevant for external API contracts and can introduce bugs if member order changes and values shift.

COMMON WRONG ANSWERS: A red flag is recommending a numeric enum for the API status field without acknowledging that the runtime values would be zero, one, and two, which do not match the strings PENDING, FULFILLED, and REJECTED. Another mistake is claiming that string enums have auto-incrementing behavior; only numeric enums do. Some candidates also confuse enums with const assertions on string unions and fail to mention the runtime object that TypeScript enums generate.

LIKELY FOLLOW-UPS: The interviewer might ask how you would handle an unexpected status string returned by the API, which opens a discussion on exhaustiveness checking and discriminated unions. They might also ask why you would choose a string enum over a string literal union type, leading to a conversation about the runtime enum object, iterability, and whether you need to map over statuses at runtime. A third follow-up could be how to keep the enum in sync with the backend, touching on code generation from OpenAPI schemas.

ONE CONCRETE EXAMPLE: Suppose the backend sends status PENDING. With a string enum like enum Status { PENDING = PENDING, FULFILLED = FULFILLED, REJECTED = REJECTED }, you can assign response.status directly to a Status typed variable. If you used a numeric enum, response.status would be the string PENDING while your enum value is zero, so a direct assignment would fail type checking and you would need an explicit lookup table. In a logging scenario, seeing Status.PENDING in a crash report is immediately meaningful, whereas seeing Status equal to zero requires you to look up the enum definition.