> 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/

It’s unrealistic to expect this level of optimization in a generalist whiteboard session. For a specialist, maybe. I’m not specialized in this area.

For an array of 5-10 items the performance hit of foreach is worth it for readability. Maybe an interesting discussion could occur about when to sacrifice readability for performance but you won’t get that by grilling people about minutiae.

> For an array of 5-10 items the performance hit of foreach is worth it for readability

As always it depends, maybe that component is being called 500 times on the page making it actually 5,000 invocations.

I'd FULLY expect a candidate to understand the difference and would ask in a whiteboard session. There is a lot of bloated slow javascript libraries out there and they almost always stem from the fact that most devs don't realize how much overhead function calls introduce.

For the interview, there is no discussion necessary, the correct answer is simply:

"I used a foreach for readability, because performance doesn't matter in this case because X."

or

"I used a for because performance matters in this case because Y"

End of story.

one could argue that it's a job for the compiler to make sure two equivalent language constructs (map and for loop) perform similarly...

Foreach with functions being passed being slower is an implementation detail. You don't see it in Rust, where the block body is inlined like a generic, and it's perfectly feasible for a dynamic runtime to specialize the pattern and inline based on it being a common practice, never mind polymorphic inline caches which in principle permit inlining in this case.

> For an array of 5-10 items the performance hit of foreach is worth it for readability

100% agree. my point is more about OP's example being used to prove that dumb questions get asked. if it's being asked by a good interviewer, it's usually relevant.

Not sure it proves anything in interview context though. It's a language specific trivia you'll quickly learn either from experience or from a good mentor. Proves nothing about your ability to code or to be a successful member in the team. Unless you're actively looking for a candidate that knows all those JS optimization tricks.

Take Rust. For each and map generally are faster because they often allow bound checks to be elided.

100% trivia.

Constant factors don't normally matter in an interview algorithm context. Focus on them often results in ugly code and can be a distraction against bigger improvements.

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.