You are designing a library function that accepts a user-supplied callback. What contract must you fix and document before shipping it, and why is inconsistent invocation timing the dangerous one?

## Taking a callback is publishing an API When your function accepts a function, you are not just reading an argument — you are promising to call it. Everything about *how* you call it becomes a contract users depend on, usually without reading any documentation. Four commitments deserve an explicit decision. ## 1. The argument list What you pass is frozen the moment anyone writes `onItem(handler)` point-free. Adding a second argument later is a breaking change for every callback that already declares an optional second parameter meaning something else. Keep callback signatures narrow, and prefer passing a single object when the set of things you might want to pass is likely to grow: `cb({ item, index })` can gain a field without disturbing anyone. ## 2. Count and order Exactly once? Zero-or-more? Once per item, in array order, or in completion order? Callers write very different code for each. If a callback may fire more than once, say so, and consider whether users need a way to stop — returning `false` to break, or accepting an abort mechanism. ## 3. Timing — the sharp one Consider: ```js function load(key, cb) { if (cache.has(key)) { cb(null, cache.get(key)); // synchronous on a hit return; } fetchFromDisk(key, cb); // asynchronous on a miss } ``` The API now behaves in two incompatible ways depending on runtime state the caller cannot see. Caller code like this breaks: ```js let handle; load('a', (err, value) => { use(handle, value); }); handle = createHandle(); ``` On a cache miss, `handle` is assigned before the callback runs and everything works. On a hit, the callback runs *before* the next line, and `handle` is `undefined`. Now the bug appears only after the cache warms, which is to say in production and not in tests. This is what Isaac Schlueter memorably called "releasing Zalgo": an API whose ordering is nondeterministic from the caller's point of view. The rule is to pick one timing and hold it for every path. If any path is asynchronous, make all of them asynchronous by deferring the fast path: ```js function load(key, cb) { if (cache.has(key)) { const value = cache.get(key); queueMicrotask(() => cb(null, value)); // always after the current job finishes return; } fetchFromDisk(key, cb); } ``` The opposite choice is equally valid when nothing can be async: `Array.prototype.map` and `forEach` are unconditionally synchronous and callers rely on that completely. What is not valid is "usually async, sometimes sync". State which one you are in the documentation, in one sentence, near the top. ## 4. Errors and reentrancy If the user's callback throws, what happens? Three defensible policies: let it propagate to your caller (simple, and it surfaces bugs loudly); catch it and abort the remaining work; catch it, report it through your own error channel, and continue with the other callbacks. Any of these is fine — silently swallowing is not, and neither is leaving your internal state half-updated because the throw unwound you mid-mutation. Do your own state changes before invoking the callback, so a throw cannot leave an inconsistent structure behind. Reentrancy is the second-order version of the same concern. A callback invoked while you are iterating your own list may call back into your API and add or remove entries from the list you are walking. Decide the policy — iterate over a copy, defer mutations until the pass completes, or explicitly document that mutation during iteration is unsupported — and enforce it, because "whatever the code happens to do" is a policy that changes silently in the next refactor. ## Why this is a lead-level question All four commitments are cheap to make on day one and expensive to change afterwards, because every caller's code is shaped around them and the compiler cannot tell you who depends on what. The interviewer is checking that you think of a callback parameter as an interface with a compatibility surface, not as a convenient hook — and that you can name the timing hazard concretely rather than gesturing at "async is hard". A strong answer also says when *not* to take a callback at all: if the extension point is really configuration, take data; if it is really a sequence of results, hand back an iterable; a callback is right when the caller genuinely needs to run code at a moment you control.