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 they mentioned the fact that React 18 batches updates in concurrent mode which would greatly improve the responsiveness of a dashboard app that's updating lots of small components frequently, or if they suggested the graphs might be better written using GLSL shaders to move the rendering to the GPU so JS only needs to update a uniform array, then I'd pay attention. Potential new ways to approach a problem or changes to architecture to avoid the problem entirely rather than micro-optimizations are much more interesting signals about someone's deeper knowledge of building things.
The question you're asking involves 10k * 3 * 30 = 900,000 data points. If a candidate wants 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/
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.
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.
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.
100% trivia.
Unless you're suggesting that knowing the performance of a loop helps with that?
it always amuses me when people use these seemingly stupid questions (out of context) to prove how broken tech interviews are. but of course, if your job will be write high perf code, then suddenly they question is incredibly relevant.
to be clear, i agree that there are a lot of stupid questions that get asked which are not relevant to the actual job you'll be doing (exceedingly few SWEs will need to implement a merge sort as part of their job)
This ridiculously untrue.
It's also a great example of how dumb current interviews are. Someone like this poster could easily interview you, and now what? Do you just play along or begin to explain how incredibly wrong they are?
But try that in Java and you'll often see a 3x-10x difference, especially if you run into problems with boxing. Streams are known to be notoriously slower than for loops with index. I once have even doubled the speed of a for loop by unrolling it manually (Java 8). Not all compilers are equally strong at optimization.
Anyway, asking such questions in an interview for a junior/regular developer is just a distraction.
at least for JS VMs, this is true today. this answer will certainly vary for other languages/runtimes.
i profile and optimize a lot of JS/TS code that handles datasets with millions of datapoints at my day job. but you don't need to take my word for it; this claim is not exactly difficult to verify.
> Do you just play along or begin to explain how incredibly wrong they are?
in this case, i'd prefer to be proven wrong with code, rather than prose.
1. require a complete rewrite of an existing, massive codebase
2. where the primary task is rendering interactive charts for a React web app
Total nonsense. It is not true of JS today, not has it ever been true.
No modern web app's or website's performance is dominated by the performance of what loops you choose. It isn't even remotely meaningfully impacted by that; by this I mean, any differences are totally unmeasurable beyond some 3 line micro-benchmark.
You have never benchmarked or profiled your code.
Of course, tight inner loops for image processing or ML, etc. yes, this can make a difference. But we're only talking about a handful of loops that matter out of many tens of thousands an application may have, you are almost certainly never writing those loops, and that's a specialized field that basically has nothing to do with the web. And it isn't what you're talking about.
> in this case, i'd prefer to be proven wrong with code, rather than prose.
What absurdity. And this is exactly when interviews suck. Because people have strongly held beliefs that are ungrounded in reality, and since there are no objective measures by which to rate interviews you need to pretend that they're real, because a lot of interviewers are basically just testing "cultural fit".
But hey! I have to say. That if you brought this up in an interview. I would at least know to never take the job!
you should be able to explain why you wrote something the way you did; that's not an absurd ask.
perf characteristics of different iteration styles are often significant to the task at hand.