Modifying or extending built-in object prototypes is generally not recommended, as it can lead to compatibility issues and unexpected behaviour in code that uses those objects. It's better to create utility functions instead.

Difficulty: 5/10

Topics: prototype inheritance, global namespace pollution, maintainability

Scenario Questions

0-2 years experience

1
How would you add a custom method to all arrays in a small script? Show the code you’d write.
2
If you added a method named flatten to Array.prototype but later discovered JavaScript added its own flatten method, what would happen to existing code?

2-5 years experience

1
We have a legacy codebase where someone patched Array.prototype with a sum method. A new library you’re using now throws an error. How would you debug and fix the issue?
2
When you need a reusable array operation for a new feature, would you extend Array.prototype or create a helper function? Explain the trade‑offs.

5-8 years experience

1
In a large web app, performance regressions appeared after several teams added methods to built‑in prototypes. How would you measure the impact and decide whether to refactor those extensions?
2
Design a strategy to prevent prototype pollution across multiple micro‑frontends that share the same global JavaScript environment.

8+ years experience

1
Your organization is moving from a monolithic front‑end to a modular architecture with isolated runtimes. How would you handle existing code that monkey‑patches built‑in prototypes to avoid breaking other teams?
2
What company‑wide policies or tooling would you introduce to enforce safe usage of prototype extensions across many projects?

Follow-up Questions

❓What problems have you seen in production because of prototype changes?
❓How would you test code that relies on a patched prototype?
❓Can you think of a scenario where extending a prototype is justified?