6 ms·

> or asking obnoxious questions ("Why did you use a foreach and not a for loop?") you should be able to explain why you wrote something the way you did; that's

> or asking obnoxious questions ("Why did you use a foreach and not a for loop?") 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.

light_hue_1 4y ago
> perf characteristics of different iteration styles are often significant to the task at hand. 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?
- leeoniya 4y ago
  > This ridiculously untrue. 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.
  - vorpalhex 4y ago
    It's probably time to move into a faster language if you're getting caught up in language specifics on loop execution.
    - leeoniya 4y ago
      quite impossible to move into a faster language when it would 1. require a complete rewrite of an existing, massive codebase 2. where the primary task is rendering interactive charts for a React web app
  - light_hue_1 4y ago
    > at least for JS VMs, this is true today. this answer will certainly vary for other languages/runtimes. 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!
    - leeoniya 4y ago
- pkolaczk 4y ago
  This is untrue in languages with proper optimizing compilers, designed for performance, e.g. C++, Rust, Zig. A functional iterator transformation chain is often just the same performance as a "traditional" for loop. 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.
  - Dayshine 4y ago
    Even in java/c#: what kind of application has its performance dominated by a control structure? If you're doing so little work inside the loop then you should probably look at using fancy cpu instructions like SIMD
tshaddox 4y ago
If the choice is relevant to the task, then sure. If it’s an arbitrary choice then the question is meaningless. It’s like asking “why are you wearing a blue shirt?” when you would have asked “why are you wearing a black shirt?” had they been wearing a black shirt.
- leeoniya 4y ago
  i'm not claiming that this is a good question for every case. but there are many times where the choice of loop makes a significant difference. asking this question for a task that only requires iterating 3 elements every 1000ms would indeed be quite stupid on the interviewer's part. 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)
vorpalhex 4y ago
Your problem has gone off the rails if that level of performance difference is important.
- leeoniya 4y ago
  try rendering a dynamic React dashboard with 30 line, scatter, and heatmap charts, each containing 3 series of 10k points each, several times per second. welcome to what Grafana can do :)
  - thaneross 4y ago
    Yes, a regular for loop is a bit faster at iterating over a large list of elements than foreach in Javascript, but why on earth would you care about that kind of optimization minutia in a coding interview? 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.
    - leeoniya 4y ago
      > 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/ https://jsfiddle.net/3ho6f5k1/
      - drewrv 4y ago
        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.

light_hue_1 4y ago

> perf characteristics of different iteration styles are often significant to the task at hand. 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?

leeoniya 4y ago
> This ridiculously untrue. 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.
- vorpalhex 4y ago
  It's probably time to move into a faster language if you're getting caught up in language specifics on loop execution.
  - leeoniya 4y ago
    quite impossible to move into a faster language when it would 1. require a complete rewrite of an existing, massive codebase 2. where the primary task is rendering interactive charts for a React web app
- light_hue_1 4y ago
  > at least for JS VMs, this is true today. this answer will certainly vary for other languages/runtimes. 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!
  - leeoniya 4y ago
pkolaczk 4y ago
This is untrue in languages with proper optimizing compilers, designed for performance, e.g. C++, Rust, Zig. A functional iterator transformation chain is often just the same performance as a "traditional" for loop. 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.
- Dayshine 4y ago
  Even in java/c#: what kind of application has its performance dominated by a control structure? If you're doing so little work inside the loop then you should probably look at using fancy cpu instructions like SIMD

tshaddox 4y ago

If the choice is relevant to the task, then sure. If it’s an arbitrary choice then the question is meaningless. It’s like asking “why are you wearing a blue shirt?” when you would have asked “why are you wearing a black shirt?” had they been wearing a black shirt.

leeoniya 4y ago
i'm not claiming that this is a good question for every case. but there are many times where the choice of loop makes a significant difference. asking this question for a task that only requires iterating 3 elements every 1000ms would indeed be quite stupid on the interviewer's part. 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)

vorpalhex 4y ago

Your problem has gone off the rails if that level of performance difference is important.

leeoniya 4y ago
try rendering a dynamic React dashboard with 30 line, scatter, and heatmap charts, each containing 3 series of 10k points each, several times per second. welcome to what Grafana can do :)
- thaneross 4y ago
  Yes, a regular for loop is a bit faster at iterating over a large list of elements than foreach in Javascript, but why on earth would you care about that kind of optimization minutia in a coding interview? 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.
  - leeoniya 4y ago
    > 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/ https://jsfiddle.net/3ho6f5k1/
    - drewrv 4y ago
      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.