> No doubt there are situations where hugely optimized code is necessary. An interview isn't one of them unless you're hiring someone to write exactly that code. Most companies aren't.

knowing the difference, and consciously deciding that it doesn't matter for a given task is often a strong positive signal. hopefully a good interviewer will not actually ask you this question if it doesnt matter for the given task.

> If a candidate want to simply loop over all of them multiple times a second, I'd say that's a much bigger problem.

unless the task is to animate them in a rAF loop (which runs at ~60Hz), right? the task matters. in some cases the question is stupid & irrelevant, and in the other case it means getting the job done, or not.

the difference between the brain-dead way and the fast way is literally 30x (53ms vs 1.8ms on my machine): https://jsfiddle.net/3ho6f5k1/

I would care about the reading optimization. So if someone tells me "I chose a forEach instead of a for because it provides almost the same performance, but is more readable, and my code does not need the index", that's a very good sign of someone making conscious choices.

Also a ton of important software was written as a giant mess of spaghetti code, or with horrible security vulnerabilities.

Parent commenter asked for little o, not for big O. So to be safe, better say n^o(n^2).

“So you want to put code into production without having a better estimation of its time complexity than O(n!)?”