Comment by valeriemettler | Hacker News Reader

Comment by valeriemettler | Hacker News Reader

Parent Full thread

In my experience, closures are a topic that always comes up. It is also important to know how to handle a closure inside of a for loop. I've been asked about "this" binding, coercion, and CSS specificity. I've had to solve problems that required me to know about how to use stacks, trees, and nested for loops. Other topics that have come up are how to architect an app, concurrency, memoization, building out and handling api endpoints, and pass by reference vs. pass by value.

You may not think databases are a front-end topic, but I have been asked about them on more than one occasion. Prepare to talk about sharding, natural primary keys, what your favorite database is and why, etc.

Something that has been extremely useful for me is to have a project that I've built myself to show and talk about during the interview. Although I have had one interview where I was asked to talk in detail about how I built some of my projects that are in my github, I like to respond to general technical questions while referencing something I've built. A lot of times the interviewer will then use my app as a starting point into a discussion for how I would scale it. Here's an example of an app I built quickly and have used for discussion in interviews: http://moviemap.xyz/ More here: http://valeriemettler.com/

> In my experience, closures are a topic that always comes up.

Opinions will differ, but IMHO closure is a great concept to divide those who know JS at a conceptual level (or at least have crammed for the interview) from those who don't.

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.

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

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.

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.

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.

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)

Reply on news.ycombinator.com