The latest trend for tech interviews: Days of unpaid homework

The hiring market is strongly an employer’s market. There is far more talent out there seeking relatively few jobs, so employers can dictate terms pretty much absolutely. If they require a 5 day homework, then it’s “homework or GTFO”. If they require whiteboard hazing, it’s “whiteboard or GTFO”. The last real employee’s-market we had was in the late 90’s!

I start with a phone screen. Then onto a (relatively short 45 min to an hour and a half) face-to-face. This is a 'let's get to know each other and our expectations' low-stress interview just to make sure we understand each other and what it is we're actually getting into.

Then, a technical discussion. Approaches. Experience. Past projects. Some 'did you lie on your resume' questions but nothing that would require a whiteboard or anything. This culminates in getting a paragraph of requirements that will lead to the take-home test. The requirements are intentionally vague and missing critical information to see if the candidate recognizes this and asks the right questions (I'm convinced that 60% of any job is asking the right questions). Then, when I feel like they've hit a few of the important gaps I pull out the detailed specs that tries to answer all of the questions they might have, serve as a reference sheet, and make it clear what not to do (like turning a two hour task into an over-engineered weekend project just to try to impress -- I've got to review all of this code after all!).

This is not a real world test but it is a somewhat simplified version of a real-world thing they will be expected to do. It shouldn't take more than 2 hours.

I point out that if they have any code they can show me from a real, working project it can act as a substitute. What I am looking for is knowledge, approach to the problem, and code style.

Afterward, I am looking for how they handle constructive criticism.

This has saved me and I think applicants so much time with much higher quality information than a long interview or a nerve-wracking whiteboard session.

I give them five days to a week to finish. Most do it within a day or two. If a busy person can't find the time that they'd normally spend in an interview session essentially any time they can fit it in over the next week or so...well, too bad.

Oh, I also give them explicit permission to post their solution on github so that if we don't end up hiring at least they'll have some code to show the next potential hiring manager.

For instance, one company asked me to do this extract/load to Spark and analyze data thing. I did it because their e-mail said that they would reply to each individual with feedback. Guess what? 3 weeks later I get a canned response!

Another job assignment took me 4 days but landed me an interview that went really well and gave me a chance to talk about my code one-on-one with a real profession (I consider myself a newish developer). After the second interview, I'm told I almost definitely got the job and that the position pays a whopping $15/hour in NYC.

Right now if you offered me coding work for $15/hour, I would probably take it and be quite happy for a while...but if you put me through the wringer like that, make me explain all 500 lines of codes for 3 1/2 hours after I spent the entire work-week bootstrapping your next project, I expect you to at least negotiate around the minimum salary I wrote about on my my resume! And if you're going to flat-out reject me, that's fine but at least offer me feedback on my application or code!

I really enjoyed doing the coding exercises, it forced me to consider things I wouldn't think about when coding for myself. But I have to say, the whole thing is making me a little wary of companies that do this. I'm not saying I should have a job but a little reciprocity and honesty goes a long way.

PS: I'm a contrarian so I upvoted your rant.

I think our contention centers mainly around this word. When I see the word related I envision most standard job offers that have a laundry list of 10+ technologies, not all of them particularly related.

Software engineering is such a wide field with such a huge array of available technology options that if you're limiting to 5+ years in a specific stack you're already massively narrowing down your field to a small percentage of the available workforce. If you aren't offering significant advantages to offset that huge initial filter you're not going to get many candidates you find acceptable.

At the company I work at we hire for "general software engineering ability". You can pick whatever language or tool you want to get through the interview, we don't care. Most strong candidates will ramp up on whatever specific stack way more quickly than you expect.