4 ms·

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. welcom

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.
    - leeoniya 4y ago
      > 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.
    - zepolen 4y ago
      > 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.
      - aulin 4y ago
        one could argue that it's a job for the compiler to make sure two equivalent language constructs (map and for loop) perform similarly...
      - barrkel 4y ago
        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.
  - aulin 4y ago
    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.
    - Gwypaas 4y ago
      Take Rust. For each and map generally are faster because they often allow bound checks to be elided. 100% trivia.
  - barrkel 4y ago
    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.
- bluepizza 4y ago
  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.
onion2k 4y ago
If someone suggested that I ought to be able to solve a problem like that in an interview, rather than solving it over the course of several years with a team of developers (like Grafana did) then I'd stop the interview and remove myself from the hiring process. 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.
- deleted 4y ago
  [deleted]
- leeoniya 4y ago
  > 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.
  - onion2k 4y ago
    I don't agree. If someone brought that up in an interview I'd just think "oh, they know a bit of JS trivia that won't impact any of the code they'd write here." and ignore it. It's not a signal at all, let alone a strong one. 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.

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.
  - leeoniya 4y ago
    > 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.
  - zepolen 4y ago
    > 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.
    - aulin 4y ago
      one could argue that it's a job for the compiler to make sure two equivalent language constructs (map and for loop) perform similarly...
    - barrkel 4y ago
      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.
- aulin 4y ago
  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.
  - Gwypaas 4y ago
    Take Rust. For each and map generally are faster because they often allow bound checks to be elided. 100% trivia.
- barrkel 4y ago
  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.
bluepizza 4y ago
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.

onion2k 4y ago

If someone suggested that I ought to be able to solve a problem like that in an interview, rather than solving it over the course of several years with a team of developers (like Grafana did) then I'd stop the interview and remove myself from the hiring process. 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.

deleted 4y ago
[deleted]
leeoniya 4y ago
> 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.
- onion2k 4y ago
  I don't agree. If someone brought that up in an interview I'd just think "oh, they know a bit of JS trivia that won't impact any of the code they'd write here." and ignore it. It's not a signal at all, let alone a strong one. 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.