You change a function's parameter annotation in TypeScript from `items: Item[]` to `items: readonly Item[]`. What does that annotation actually guarantee, and what does it not?

## The guarantee, stated precisely Annotating a parameter `readonly Item[]` changes exactly one thing: the type the body sees. That type is `ReadonlyArray<Item>`, which lacks the mutating members, so the compiler rejects them: ```typescript function summarize(items: readonly Item[]) { // items.push(x); // error: push does not exist on 'readonly Item[]' // items.sort(); // error: sort does not exist // items[0] = other; // error: index signature is readonly return items.map(i => i.name).join(', '); // reading is untouched } ``` That is a real and useful guarantee. The classic bug it prevents is a helper that calls `sort()` or `reverse()` on a parameter, mutating the caller's array as a side effect nobody documented. With the readonly annotation, the mistake is caught at the point of writing rather than in a bug report about a list that reordered itself. ## Limit 1: it is shallow `readonly Item[]` protects the array's own slots — which object each index holds — and nothing inside those objects: ```typescript function normalize(items: readonly Item[]) { for (const item of items) { item.name = item.name.trim(); // compiles: the elements are mutable } } ``` If the elements must be immutable too, that has to be expressed in the element type — a type whose properties are readonly, or `readonly (readonly number[])[]` for nested arrays. There is no single modifier that makes a type deeply immutable; depth is opt-in at every level, and forgetting that is the most common way a readonly annotation gives false confidence. ## Limit 2: nothing exists at runtime The entire type layer is erased during compilation. The emitted JavaScript for a `readonly Item[]` parameter is identical to that for `Item[]` — no check, no wrapper, no cost. Consequences worth naming in an interview: - A caller written in plain JavaScript, or one that reaches your function through an `any`, is unconstrained. - A type assertion (`items as Item[]`) silences the checker without copying, restoring full mutability with no runtime signal. - Data crossing a boundary — parsed JSON, a message from a worker — arrives with whatever type you claimed for it, not whatever the annotation implies. If you need enforcement rather than a claim, `Object.freeze` is the runtime mechanism; the type annotation and the runtime freeze are independent and you can have either without the other. ## Limit 3: it binds the callee, not the caller The annotation is a promise this function makes about what it will do, not a constraint on the array. The caller usually still holds an `Item[]` pointing at the same object and may mutate it at any time — including while your function is mid-iteration, if you have handed control back through a callback or an `await`. Readonly parameters buy you "I will not corrupt your data", not "this data will not change". ## The cost: interop friction Because assignability runs only from mutable to readonly, a `readonly Item[]` value cannot be passed to anything typed `Item[]`: ```typescript declare function persist(items: Item[]): void; function handle(items: readonly Item[]) { // persist(items); // error persist([...items]); // copy, at the cost of an allocation } ``` The same friction shows up with older library signatures and with in-place methods you actually wanted — sorting a readonly array requires copying first (`[...items].sort()`), unless your `lib` setting includes ES2023, whose `toSorted`, `toReversed` and `with` are declared on readonly arrays as well and return a new array. This is why readonly array parameters tend to be adopted at chosen boundaries — public module APIs, shared domain helpers — rather than sprayed everywhere: each one is a small immutability guarantee bought with a little friction for its callers. ## How to answer the interview version Lead with the precise guarantee, then the three limits in order of how often they burn people: shallow, erased, callee-only. Finish with the interop cost and the boundary-level adoption strategy. That sequence demonstrates you have used the feature in a real codebase rather than reading its documentation, which is the whole point of asking a senior candidate a question whose surface answer is one sentence long.