3 ms·

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.

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.

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.