5 ms·

I don't do frontend but they all sound fairly easy to me, although 9 is odd (I'm assuming you want people to compute timeouts? To prove they're decent at arithm

I don't do frontend but they all sound fairly easy to me, although 9 is odd (I'm assuming you want people to compute timeouts? To prove they're decent at arithmetic? In which order should the balls animate, row-first or column-first?). 10 is filtering out people who have anxiety about doing things in an interview that they don't yet know how to do -- if your work environment doesn't require learning something brand new while a manager looks over your shoulder, you may be better off having it as a homework assignment. 11 is fine but the people who froze on 9 and 10 because they didn't understand 9, don't like math, had their brain freeze up on them at the "I don't know what async.js is!!!" step, or something else don't get to it. In addition, while I would be able to do this in an hour, the fact that there are 11 points may be pre-emptively stressing some people (some people get anxious at long lists of tasks, time-limited, that don't entirely fit in their working memory), and things like reading through documentation can take a bunch more time if someone is more thorough or less efficient at searching (prefers tutorials to documentation, has trouble googling "async.js" because of e.g. blog posts on ajax hogging up their search results page), if someone's eyes are tired (at this point they have been coding at least half an hour), and so on. My suggestions would be, present the questions 1 by 1 not 11 at once, verbally in addition to having the current question in writing. At the looking up docs steps, have the link to the docs ready, or otherwise give a heads-up to the interviewees before the interview ("you may want to read up on async.js as preparation"). Otherwise, give the same exercise as homework. After questions 1-8, if the candidate is satisfactory, say "great job! I only have a few more questions", thank them for their patience, generally validate their good answers. Make them feel like you're asking for their help vs. just evaluating them.

yeldarb 8y ago
Sorry, I probably wasn't as clear on the format as I should have been. I didn't present them all 11 tasks up front, I walked them through them 1 by 1 verbally. The questions flow pretty naturally from one to the next since it's mostly building on the previous step each time. And yeah, I tried to make them feel comfortable and less like this was a test and more like a collaborative coding exercise. Wanted to try to make it as low stress as possible but I know that's hard given the interview environment. Re 9 - I was expecting people to use callbacks to do it rather than computing timeouts (but a couple people did try to compute the timeouts and that was a fine solution as well -- asking people about why they chose what they chose led to helpful discussions). Something like this is what I would have done: var circles = $('.circle').toArray(); var current = 0; var animateNext = function() { if(current >= circles.length) return; $(circles[current++]).animate({backgroundColor: 'black'}, animateNext); }; animateNext();
- arandr0x 8y ago
  It's not how I would code it but it sounds straightforward for someone who's done any jQuery, frankly. How did your candidates fail on this one? Did they just freeze up and not try?
  - yeldarb 8y ago
    They seemed to just not be able to grasp the asynchronous nature. Mostly confusion between calling a function and passing the result as a parameter and passing a reference to that function. But also struggling with the recursive nature of calling a function from inside of itself. I should also say it wasn't the syntax or JS/jQuery-specific aspects of it that were the problem. Most couldn't explain in English/pseudocode what their strategy for solving the problem would be.
    - arandr0x 8y ago
      You may be filtering your pipeline according to the wrong criteria, and rejecting candidates strong in algorithms but weak(er) in JS specific or framework-specific stuff at a stage that's too early. Or those candidates may be unicorns -- usually the early-career people who like thinking about recursion don't jump into applying to frontend roles, which they see (wrongly IMO) as a lower tech, design-oriented kind of role. If it's an entry-level role and you don't have good signals for the steps prior to the interview, maybe consider a pre-interview assignment that includes some asynchronous concepts, and administer it much earlier in the pipeline. That's a slightly lesser investment but should be as good a signal. If it's a senior role, then your questions are way too easy, but also you should go on Linkedin and ask individual people with good experience to apply, that's what everyone else is doing. Edited to add: Well, I saw in your other answers that you are filtering candidates based on "really wanting" the job very early in the process... I work in a region that is not the hottest job market wise and even here no one could afford to do this. Software devs are just too in demand... you're going to get pretty mercenary candidates unless you go with personal referrals. If the non-technical aspects of the candidates are more important, which with your ordering of the hiring pipeline it sounds like they are, then you need to consider hiring fewer people and growing less fast, pr hiring for fit first and training the recursion skills later.

yeldarb 8y ago

Sorry, I probably wasn't as clear on the format as I should have been. I didn't present them all 11 tasks up front, I walked them through them 1 by 1 verbally. The questions flow pretty naturally from one to the next since it's mostly building on the previous step each time. And yeah, I tried to make them feel comfortable and less like this was a test and more like a collaborative coding exercise. Wanted to try to make it as low stress as possible but I know that's hard given the interview environment. Re 9 - I was expecting people to use callbacks to do it rather than computing timeouts (but a couple people did try to compute the timeouts and that was a fine solution as well -- asking people about why they chose what they chose led to helpful discussions). Something like this is what I would have done: var circles = $('.circle').toArray(); var current = 0; var animateNext = function() { if(current >= circles.length) return; $(circles[current++]).animate({backgroundColor: 'black'}, animateNext); }; animateNext();

arandr0x 8y ago
It's not how I would code it but it sounds straightforward for someone who's done any jQuery, frankly. How did your candidates fail on this one? Did they just freeze up and not try?
- yeldarb 8y ago
  They seemed to just not be able to grasp the asynchronous nature. Mostly confusion between calling a function and passing the result as a parameter and passing a reference to that function. But also struggling with the recursive nature of calling a function from inside of itself. I should also say it wasn't the syntax or JS/jQuery-specific aspects of it that were the problem. Most couldn't explain in English/pseudocode what their strategy for solving the problem would be.
  - arandr0x 8y ago
    You may be filtering your pipeline according to the wrong criteria, and rejecting candidates strong in algorithms but weak(er) in JS specific or framework-specific stuff at a stage that's too early. Or those candidates may be unicorns -- usually the early-career people who like thinking about recursion don't jump into applying to frontend roles, which they see (wrongly IMO) as a lower tech, design-oriented kind of role. If it's an entry-level role and you don't have good signals for the steps prior to the interview, maybe consider a pre-interview assignment that includes some asynchronous concepts, and administer it much earlier in the pipeline. That's a slightly lesser investment but should be as good a signal. If it's a senior role, then your questions are way too easy, but also you should go on Linkedin and ask individual people with good experience to apply, that's what everyone else is doing. Edited to add: Well, I saw in your other answers that you are filtering candidates based on "really wanting" the job very early in the process... I work in a region that is not the hottest job market wise and even here no one could afford to do this. Software devs are just too in demand... you're going to get pretty mercenary candidates unless you go with personal referrals. If the non-technical aspects of the candidates are more important, which with your ordering of the hiring pipeline it sounds like they are, then you need to consider hiring fewer people and growing less fast, pr hiring for fit first and training the recursion skills later.