[crazygringo]

Sorry, but they're crazy if they think halfway decent engineers are going to spend 7.5 hours of their time doing a coding quiz before they even have a personal interview with them.

They seem to be forgetting that potential engineers are interviewing them just as much as they're interviewing the engineers -- and such a crazy up-front time commitment is a sure way to weed out the engineers who have better things to do with their time.

This may be scalable for the company, but it certainly isn't scalable for engineers looking for jobs at multiple companies.

[sjtgraham]

Here is an idea. Why not pay candidates for their time? e.g.

"We are serious about who we hire, so we're careful about who we do hire. However, we realise you're interviewing us as much as we are you, so we're equally as serious about showing respect for your time. We really appreciate it, so we'll pay you $m/hour while you complete this tests. We think these three tests should take a competent engineer around n hours to complete, so we'll pay you a max of $m*n for completing the process.

Good luck!"

As the OP highlighted hiring is an expensive process (expensive engineers interviewing candidates, double whammy of them not working on product while interviewing), it could be a lot cheaper to just automate some of the process, but make it more humane by compensating the interviewee.

There is a definite balance to strike between the humanity and scalability aspects, but I think it's an interesting idea.

[shiftb]

We've actually done this before. Our process has evolved over time. We used to bring candidates in for a day to work with us and have them work on production code. We would pay them for their time.

Unfortunately, it wreaked havoc with the candidate's schedule, especially if they had another job, and took too long to get to a pass/fail for them.

The current process let's the candidate work on a production problem, but at a time of their choosing and on their own schedule. It also gets feedback to them much sooner, within a half hour or 3 hours.

[rabino]

We do that and works really well for us. Because it's not only the technical chops we want to test. We want to know how well integrates with our workflow, the quality of the questions they ask, how well they document what they are doing, etc.

[shiftb]

I understand why you got that impression.

We've automated the technical skills part of it. Hiring at Instacart isn't a completely automated, no personal interaction, process.

In between the candidate applying and the technical challenges is usually a phone call where we talk to the candidate to make sure we're on the same page. We find out what their goals are and if we can help. We explain how we work, and see if they'll like it. We explain the hiring process. We answer questions they have about us.

If we're both happy at the end of the call then we move them into the automated process.

[loteck]

What do you learn in an 8 hour process that you couldn't learn in a 4 hour process?

[dfan]

We have an off-line coding test that probably takes about a day on average. This is after a three-question quiz that takes a couple of hours. I'm pretty surprised that so many people are willing to go through all of that.