[nefitty]

The clear requirements of take home tests make them my favorite. They allow me to express how I work: get a list of reqs, walk away and think about them, make some decisions on directions, then let the code lead me.

I strike the style required. I capitalize on opportunities to make decisions I can discuss. "I used tape instead of jest because this example product will be distributed to many developers. The reduced API-surface area keeps us focused on the how's not the what's."

I tone that down if the role seems more rote-work like, at which point I try to highlight my ability to solve problems and learn quickly. For example, a comment above some network call: "// I was getting a cors error and found out I can run my own proxy for this"

[handrous]

Trouble is, unless more of the industry starts doing them so they're unavoidable, I'm going to skip companies that put these anywhere other than at the tail end of their process.

I'm not putting in half a day of work for zero pay to help you with your first-pass weed-out phase before we bother to make sure we align otherwise and this looks like a good fit. Thanks, bye, next (employer) candidate.

[potta_coffee]

I like them because I have a far higher success rate with them. Take home tests cater to my strengths. Of course, I'm selective about the companies I apply for, and sometimes the test itself reveals something about the company, and I've rejected assignments after receiving them.

[nameisname]

I agree and generally say I'm willing to an alternate, live coding approach instead. I'm not putting in hours and hours in some random take home that may or may not be discussed down the line. Been there and done that so many times. Most of the time it didn't even align with the job.

[waynesonfire]

sweet, don't let the door hit you. More opportunities for me.