[milesvp]

What you may be missing is how hard it is to actually create a good take home. Every take home test I’ve seen was rife with potential for the problem to explode in complexity. Even things that seem simple like names and dates have so many potential pitfalls that it can be impossible to tell as an applicant whether they intentionally laid a trap or not. Then there’s the incidentals, should I send them a docker image to increase the odds it’ll work on their machine? Oh, they’re going to want me to extend this in real time, should I include other nice to have services that this problem could dovetail into needing, like redis?

As far as I can tell, any company that isn’t willing to pay contracting rates to solve real problems on their stack is likely being disengenuous with their take homes and largely biasing against experienced devs who aren’t as likely to waste their time. And worse with a take home, is that they have no skin in the game. With an in person interview they lose at least as long as the inverview. With a take home they lose nothing except short email exchanges.

[nthj]

A code comment saying “Here’s a potential pitfall we could discuss addressing” is often more valuable than a solution. Every software project has more problems than it has people-hours available. Every team has the engineer who spends a week fixing an edge case in their ticket that no customer cares about. Demonstrating awareness of this makes you an attractive candidate.

[PragmaticPulp]

Take homes are easy to iterate on. If multiple candidates can’t understand the problem or waste time with over-complicated solutions, you update the instructions.

If you’re constantly worried about “traps” then you might not want to work for those companies anyway. Take homes should be straightforward and similar to solving real problems.

> As far as I can tell, any company that isn’t willing to pay contracting rates to solve real problems on their stack is likely being disengenuous with their take homes

Take homes are contrived problems, not real work. Every candidate receives the same problem so they can be compared.

No company should be giving employees actual unpaid work to do as part of the interview. That’s more of an internet trope than a real problem because no rational company is going to be sending their codebase to applicants to add features to.

[flukus]

> What you may be missing is how hard it is to actually create a good take home

The biggest issue I see are people underestimating the setup time for "simple" projects. You're a big software company that doesn't start new projects regularly, I'm a developer at a big company that doesn't setup new projects regularly, why do you expect me to remember how to setup "professional quality" projects in a couple of hours?

A simple console app might test if I can code, setting up a new MVC project with authentication, unit tests, IoC, etc is testing how well I can google shit I haven't had to setup for years.