[imiric]

The solution is simple: pay candidates for the estimated time the assignment should take, based on the median rate of the role they're applying for. Pay them regardless if they pass or fail the test. You should be able to avoid grifters looking for handouts if your screening process is any good.

But I don't think this type of evaluation is a valuable signal anymore in the age of AI. Anyone could nowadays finish your take home assignment in a fraction of the effort it would take them without AI. This might not be relevant after they're hired, since they would likely also use AI assistants, but for evaluation purposes you want to assess how someone thinks about problem solving, not how they generate the solution, and then confidently walk you through it.

The best interview style for software developers IMO is the code review challenge. Show them a piece of code from a hypothetical PR of a junior developer, and ask them to a) describe what the code does, b) point out any issues they see, and c) fix the issues. You can have several difficulty levels depending on the role and expected candidate experience, or you can cherry pick these from your own codebase. The benefits of this approach are that it's a simulation of a real-world task they would be doing on a daily basis, it's a collaborative effort and showcases their communication skills, while also allowing them to evaluate yours, it's much less stressful than white boarding and quizzing sessions though still involves some coding, and unlike take home assignments, it can be completed in an hour or 90 minutes at most.

[abathur]

I've yet to go through one of these, but I've at least imagined it would be a decent format.

(For me, at least. I don't parallel-task very well in the first place, and being under the magnifying glass makes it significantly worse. I have trouble, say, even making sense of the words someone else says when I'm already focused on coding/reading/writing something. If the interviewer interjects a thought or question about what I'm doing, I often have to stop, struggle to ~park my train of thought, and then ask them to repeat what they said. If I make the mistake of asking them to repeat before the train's parked, I may have to ask them to repeat it again.)

I think I'd also look pretty favorably on an interviewing process that gives a few format choices and lets me choose what I'm most comfortable with.

[throwway120385]

This is exactly what I do. It's rare that someone is required to create something entirely from scratch. Most of what we do as developers is altering an existing system. I want to select for people who can figure out how to do that.

Also it completely eliminates the tool selection and test system portions of the exercise because I pick all of that stuff and make sure anything I don't care about is automated or is out of scope of the solution.

Done correctly you can usually get through it in less than an hour, leaving about 10 or 15 minutes for the candidate to ask me some questions.

[aiauthoritydev]

+1

I am totally surprised that "reading code" is not really appreciated even at FAANG companies though very likely that is one of the most important things they will end up doing.

[benji-york]

I really like the PR-role-play interview, too. I do worry that it can devolve into the classic mind-reading interview—i.e., there is an extremely subtle bug (or perceived deficiency) in the code that a candidate is dinged for not seeing.