A TypeScript service reads `const rate = rates[currency]` from a value typed `Record<string, number>` and then crashes on `rate.toFixed(2)`. Why did the compiler allow that, and how would you type the lookup table so it cannot happen?

## Why the compiler said nothing `Record<string, number>` is the mapped type `{ [P in string]: number }`, which collapses to a string index signature: ```ts type Rates = Record<string, number>; // { [x: string]: number } declare const rates: Rates; declare const currency: string; const rate = rates[currency]; // typed number rate.toFixed(2); // compiles; throws if the key was absent ``` An index signature is a statement about the keys the type *permits*, not the keys the value *has*. There is no finite key list to compare against, so the checker has two options: treat every read as possibly missing, or trust the declaration. By default it trusts it. That is one of the type system's known, deliberate unsoundnesses — the same family as a type assertion or a non-null `!`. The reasoning is ergonomic: if every dictionary read produced `T | undefined`, ordinary code that just built the map three lines earlier would be full of guards. The consequence is that a `Record<string, T>` is only as honest as the code that populated it. Data from `JSON.parse`, a query string, a database row, or user input has whatever keys it has; the annotation asserts a shape nobody verified. ## Fix 1: put `undefined` in the value type The most local and most portable fix — it needs no compiler setting and it documents intent at the declaration: ```ts type Rates = Record<string, number | undefined>; declare const rates: Rates; const rate = rates[currency]; // number | undefined rate.toFixed(2); // Error: 'rate' is possibly 'undefined' if (rate !== undefined) { rate.toFixed(2); // narrowed to number } ``` Every consumer now has to make a decision — guard, default with `??`, or throw. The cost is that writing the map also allows `undefined` as a stored value, which is usually acceptable for a lookup table. ## Fix 2: stop using `string` as the key Often the real defect is upstream: the key set is not actually open. If currencies are a known set, say so: ```ts type CurrencyCode = 'USD' | 'EUR' | 'GBP'; // The table must be complete — a missing member is a compile error const rates: Record<CurrencyCode, number> = { USD: 1, EUR: 0.92, GBP: 0.79 }; declare const code: CurrencyCode; rates[code].toFixed(2); // genuinely safe: every member has an entry ``` Here the type is telling the truth, because the finite key union makes every entry required and a new member breaks the build until the table is filled in. Note that this only holds while the key variable is typed `CurrencyCode` — the burden moves to validating the incoming string once, at the boundary: ```ts const CODES = ['USD', 'EUR', 'GBP'] as const; function isCurrencyCode(x: string): x is CurrencyCode { return (CODES as readonly string[]).includes(x); } ``` That guard is the runtime check the index signature never performed. Do it once at the edge instead of guarding at every read. ## Fix 3: `Partial<Record<K, V>>` when the map is legitimately sparse An overrides table, a cache, a per-tenant customisation — these really do have missing entries. Say that: ```ts type Overrides = Partial<Record<CurrencyCode, number>>; declare const overrides: Overrides; const o = overrides.USD; // number | undefined const v = o ?? defaultRate; ``` This keeps the key set closed (a typo is still an error) while making absence explicit. It is the right choice far more often than people reach for it, because the common instinct is to widen the key to `string` the moment the map is not complete — which throws away both guarantees at once. ## Fix 4: the project-wide flag TypeScript's `noUncheckedIndexedAccess` makes index-signature and array element reads yield `T | undefined` everywhere, so the original `Record<string, number>` starts reporting the bug without any declaration change. Two things to say about it in an interview: it is not part of `strict`, so it must be enabled explicitly, and it applies to *index* access, not to the named properties a literal-keyed `Record` generates — `Record<CurrencyCode, number>` keeps reading as `number` because those are ordinary required properties, which is exactly right. Turning it on in a mature codebase produces a large one-time wave of errors, most of them real. ## A related trap: iterating the keys Even with a narrow key type, the standard library types `Object.keys(rec)` as `string[]`, because an object can carry more keys at runtime than its type admits. So `Object.keys(rates).forEach(k => rates[k])` will not hand you `CurrencyCode` for free. Iterate the key list you already control (`CODES.forEach(...)`) or write a helper whose assertion is confined to one place, rather than sprinkling casts through the loop body. ## What to say out loud The short version an interviewer wants: an index signature promises permitted keys, not present ones; the compiler trusts that promise by default; and the cure is to make the type match reality — narrow the key set when it is finite, add `| undefined` when it is not, and validate the string once at the boundary rather than asserting at every read.