> a ton of unpaid work for companies they're applying to Okay, that's a logistical objection to work-sample tests, which is easily rebutted with, "Simply don't

> a ton of unpaid work for companies they're applying to Okay, that's a logistical objection to work-sample tests, which is easily rebutted with, "Simply don't assign _a ton_ of unpaid work" to your candidates. The process we use for hiring software developers at my current employer: 1. Clone this git repository. 2. Build a trivial feature (e.g. adding a search feature to an existing blog platform). 3. Send a patch or pull request. Everyone who's being considered gets the same task, and we base our decision off of several factors: Did they implement a working solution? How much new code did they need to create (knowing that the framework does 99% of this already, and is documented)? If so, did they write unit-testable code? Did they write unit tests? Did they find any of the intentional vulnerabilities? It should, realistically, take most people 2-3 hours at most to complete this task successfully. If they're familiar with PHP development, probably 15-20 minutes. Furthermore, it can be completed at their leisure. If that seems unreasonable, contrast it with the cost of taking a day off work to get dressed up and perform an in-person interview during business hours with complete strangers who are scrutinizing you for fitness, with a very high chance of not getting accepted. The burden of work-sample tests shouldn't be on candidates; the burden should lie with the company to ensure they're collecting objective facts about candidates rather than making subjective decisions.