Answer

A polyfill that works for a simple example may still behave differently from the native API. Interviewers often test whether a candidate considers edge cases and specification behavior.

Important considerations

1. Nullish receivers: Methods such as map() and call() must handle invalid receivers according to the specification.
2. Callback validation: Array iteration methods should throw a TypeError if the callback is not callable.
3. Sparse arrays: Some methods skip holes, while methods such as find() visit them as undefined.
4. Initial values: reduce() behaves differently when no initial accumulator is provided.
5. Callback arguments: Array iteration callbacks generally receive the value, index, and original object.
6. thisArg: Methods that accept a thisArg must preserve its specified behavior.
7. Short-circuiting: some(), every(), and find() stop when their result is determined.
8. Promise ordering: Promise combinators preserve input order in their results, even when inputs settle in another order.
9. Symbols and descriptors: Object utilities may need to account for symbol keys and property enumerability.
10. Iterables and array-like objects: These are distinct concepts and should not be treated interchangeably.
11. Native method semantics: Strict mode, constructor calls, coercion, exceptions, and exotic objects can affect behavior.
12. Prototype pollution: Adding properties to built-in prototypes can conflict with other code. Prefer a separate utility function when prototype modification is not required.

Best practice

Use feature detection when a polyfill must provide missing browser functionality. Avoid overwriting an existing native method without a compelling reason. For learning exercises, use names such as myMap or myBind so the native methods remain available for comparison.

For production use, prefer established polyfill libraries or thoroughly tested implementations when exact compatibility matters.