That's fine, just understand that is a technique for finding "growing" developers, and still not a great one for that. If that's what you are looking for, that's fine. If you want tops, this isn't the way to go. Unless you've already hired someone that knows a top, you probably won't get them anyway.

Think about it this way. It takes about 2 hours to learn how to write unit tests for someone who has never done it. Why make something as trivial so important in your interview process? I understand unit tests are important, but they aren't difficult.

> It takes about 2 hours to learn how to write unit tests for someone who has never done it.

If it's really that trivial, the developer should be doing it so routinely that it should take less than 15 minutes to write unit tests for the take home exercise. Your statement literally demolishes any excuse for not doing it.

Good unit tests themselves, if you have good coverage, usually take longer than writing the code. But you knew that right?

> Good unit tests themselves, if you have good coverage, usually take longer than writing the code. But you knew that right?

All too well, my friend. That is why the employer is justified in asking for a demonstration of the ability to write good unit tests, as you have demonstrated by your own admission.

He said if the user didn't use factories for test data, it would be a huge red flag.

According to him, if I didn't setup a factory, when doing a take home assignment, then I'm not competent to write unit tests. I disagree.

So many people interview poorly. It's gotten worse every time I read about it. They're pushing away talent that way. I know people are stuck in their ways, but it's a bad idea unless you are are just looking for juniors and people desperate enough to go through that. I'm neither.

I mean don't people realize it's a seller's market?

Then maybe communicate that salary amount to the candidate before so they can also decide if it is worth their time or not.