Tell HN: Unpaid home assignments are not ok

Real life example:

- how much would you rate your knowledge of C++ on a scale to 10?

- 9/10

- Can you explain "pointers"?

- blank stare

>unreasonable amount of time to complete said assignments

One problem is that take home assignments are, barring some sort of time-gated online tool, open-ended in terms of time spent. Sure, maybe you can "meet the requirements" in a couple hours. But someone else will handle all the edge cases and optimize the code by spending a weekend on it.

I do a lot of writing and if you ask me to write 1,000 words on $TOPIC, I can probably do so in a couple hours. It will almost certainly be better if I work on it over a couple of days.

ADDED: Having said that, while I tend not to be a fan of take home assignments, if I'm hiring someone whose job is going to be, to any significant degree, writing for external consumption, I'm going to need a writing sample. And, if they don't have anything suitable, they're going to have to create one on the topic of their choosing.

I would call that a successful interview (succeeds in detecting a candidate who would likely fail at their duties). Interviews are important. But would any random programming or whiteboarding task add anything of value to this?

Sorry you got ghosted like that - it happens way too often and it sucks. But I think you're using your understandable frustration with this company to dismiss a highly-effective interview technique.

Programming is largely solo work punctuated by a high-bandwidth communication (presenting your solution to the team, review, etc.) A take home assignment with a follow up simulates the actual job environment, especially for remote work. No other coding interview technique comes close - portfolio review doesn't show how you worked only that you've worked, in-person coding challenges and whiteboard interviews are so far removed from the daily experience.

2kloc / 6hrs does seem excessive though. My advice to interviewers - keep the exercise time-boxed to 2 hours (And actually have some developers work through it internally to confirm this!) "How far can this candidate get on the problem in 2 hours" is a better signal than "Can they build the perfect solution with unlimited time". And time boxing the assignment gives you lots to talk about - "If you have more time, what would you add or change?" is a prompt that should yield another high-value signal.

The thing is that interviewing is hard; it is a full-time job, really, and one that could make or break the company. At the same time, interviewing is not something that current employees are remunerated for, materially or even in terms of time. It is very rare for deadlines to move because half the team is conducting interviews.

So, what ends up happening is that nearly everyone in the interviewing process ends up half-arsing it - from the recruiters who prefer to contact nearly everyone eligible based on some keyword searches - to the engineers who have no time to be thorough - to the hiring manager who usually has a bunch of fires to extinguish.

A few companies do tend to put quantifiable metrics around their processes but they're usually too reactive and inconsequential.

The interviewers have a vested interest in being more productive by hiring the best people, but at the same time, there is personal friction against hiring someone good/better when your own promotion is hanging barely by the 'meets expectations' thread.

Now the assignments - they're almost always totally useless. Like, build a new app based on a third party API and then make sure to test it. Useless because of multiple reasons - the API is nothing like what you use at work; your current product team has coalesced around some archaic architecture that no Greenfield app would use; it's the take home assignment of the month (like the favorite 'build a movie app using the OMDb API'). A better alternative would be to open up your own API and perhaps a module of your current production app and add something to it, create a PR, or even just fix a bug or two. I actually think asking candidates to document a module is much more useful than asking them to write code you would never use, even if you pay for such an assignment.

Onsite interviews are even more useless - it's usually the most vocal people asking esoteric questions about older technology or algorithms that they've had success with candidates stumbling upon. Again, almost none of the whiteboard exercises or questions are from real-world scenarios.

You could pay candidates for the interview process, but that doesn't even address why interviewing is so fundamentally broken. I bet we would have amazing software products if we just interviewed better, especially when companies have been able to lobby for right to work laws nearly everywhere.