Hacker News Reader

Comment by tdeck | Hacker News Reader

Love the idea of paying people. That's great. However, consider the perspective of someone who already has a job in the industry. If every company did this, I wouldn't be able to interview at more than one per week. Not only that, but the Friday and Monday onsites mean I miss work on TWO separate days. This would be a non-starter for me if I had any decent pool of interest from other companies, although it's great for people trying to break into the industry.

Another problem, depending on your philosophy. Specifying the exact technologies someone has to use means that you've closed yourself off to generalists, unless they have time to learn a whole new stack that weekend. Not that it's rocket science to do so, but that turns a two hour project for me in say Angular into an eight hour project in your favored stack. I can always learn your stack on the job, as any good engineer can.

View on HN

Yeah, it makes sense to me as a sort of moneyball approach, to cheaply hire skilled candidates who are not as good at the standard evaluation process, are likely to have few competing offers, and who are willing to do extra work on nights/weekends.

Agreed with this. I wouldn't take a 4-day weekend to do interviews and a homework assignment unless I was desperate or already out of a job.

From the perspective of someone who already has a job in the industry, I'm really not going to want to do more than one interview per week anyway.

This format also doesn't appear to want full days: it should be an hour or two Friday afternoon, plus a half of Monday. Two part-days isn't really that worse than a full day off (Mileage may obviously vary; particularly the mileage to get to the interview). The initial interview could also very easily be done remotely.

Even if it is a bit higher-impact, I would still prefer it simply for the greater quality of experience, and that's before throwing in the payment.

I feel like it's in the best interest of the employer to leave the choice of tools fairly open and see what the potential employee elects to use. For the example given in the article (a basic web application), I'd be very interested in whether the interviewee decides to go with a heavy stack, does it completely in vanilla JS, or something in-between.

I wonder about this. I'm pretty new to js frameworks and I see the advantage when things need to scale or get very complex, and I get that companies use these things. But for a simple assignment like this, is it better to use vanilla js and maybe handlebars, or "show off" that you can implement all the routes and whatnot in Angular, even though that's overkill? Or maybe the interviewee's justification of their choice teaches you that they understand the trade offs.

Reply on news.ycombinator.com