Hacker News Reader

Comment by ShellfishMeme | Hacker News Reader

I agree. We always put the little 'for loop that creates a list of functions that spit out the current number of the iteration' exercise first in all of our interviews. Generally, when people solved that one fast, they also did well in the rest of the interview and if they struggled there, they also had a hard time coming up with an elegant solution for most of the other tasks.

What I also like about it is that a closure isn't the only way to solve it. You can use `let` for example to make sure the variables are block scoped, or use `bind` to partially apply a function with the number.

So in the end it's a conceptually very simple exercise that can give you a very good insight into how much the candidate knows about how JS actually works.

View on HN

Would that exercise be the following? I'm not sure I understand what's being tested.

  const f = (k) => {
    const funcs = [];
    for(let i = 0; i < k; i++) {
      funcs.push(() => i);
    }
    return funcs;
  }

  const test = f(4);
  console.log(test[0]()); // 0
  console.log(test[1]()); // 1
  console.log(test[2]()); // 2
  console.log(test[3]()); // 3

Try writing that same thing without ES6.

I'm also in the process of interviewing for a front-end engineer position, so thank you for replying and providing feedback. I'm assuming it has to be written this way because the function being pushed was referencing i, which was within the scope of the closure. Turning it into an IIFE breaks out of that. Thoughts?

  // Assuming pre-ES6
  function iterate(k) {
    var funcs = [];
    for(var i = 0; i < k; i++) {
      (function(num) {
        funcs.push(function() {
          return num;
        });
      })(i);
    }
    return funcs;
  }

  var itTest = iterate(4);
  console.log(itTest[0]()); // 0
  console.log(itTest[1]()); // 1
  console.log(itTest[2]()); // 2
  console.log(itTest[3]()); // 3

I'd probably ask you to do the printouts from within the function itself.

If you haven't already read them, I highly recommend the You Don't Know JS series of books. One of them covers this exact question.

neat series of books. thanks for the tip

https://github.com/getify/You-Dont-Know-JS

If you can figure that out during an interview, you're solid on the question. That's the gist of it, and knowing that you can use `let` to make it work is good too.

Yup, that's what I was thinking of. As others have mentioned, if you can show this, and explain why `let` solves it too, you're good to go.

Try writing the same thing without a computer why don't ya.

As an interviewer I can see why you would want to force someone to jump through arbitrary hoops like that but if someone can show me `() => i` and explain why that works, that would be good enough for me.

No need for the snark. There is still way more ES5 code being written than ES6. The point is demonstrating knowledge of closures and variable lifecycle, the how is irrelevant. I replied specifically because he said "I don't see the problem" - if you start with ES6 I can imagine it doesn't look like a problem at all.

If you can explain why that ES6 code doesn't share the problem, that's as good at demonstrating the knowledge you're looking for as restricting the candidate to an older subset of the language. I would accept "okay, now explain what distinguishes arrow functions from regular functions" as a follow-up question, but "now do it in ES5" seems arbitrary.

In fact I would argue it's important that if the candidate shows practical knowledge of ES6 you need to make sure they also grasp the actual semantics (i.e. they won't rely on implementation details of Babel and run into errors in native ES6 environments).

That said, if you are hiring for a dedicated frontend developer role, the majority of JS you write will have a build step. If it has a build step, you should use modern tooling. If you use modern tooling, you might as well include Babel to make the developers' lives less of a pain.

If you did that without first asking about what Ecmascript version you should support I would prompt the question myself, and if you didn't find a different way then I would consider it a very bad sign.

Tip: You can stick to `const` when declaring `i` in the loop header (at least as far as the ES spec is concerned -- mileage may vary on current implementations / transpilers).

If you set `i` as a constant it can't be changed, so it'll always remain 0. (the loop will end immediately after the first iteration with an error so no infinite loop)

We usually start out with a non working version, using `var` and just returning `i` from the function and then ask what that would print out and why.

Reply on news.ycombinator.com