[nmjohn]

> they instead decide to hardcode usernames and passwords, it's a huge red flag.

Why? That seems like an oddly specific thing to be a _huge_ red flag. Are you expecting random data to actually surface bugs - ie: making your tests non-deterministic? Or is there some other benefit you are looking for to make it such an important criteria?

[stevenjohns]

It shows a lack of familiarity with the tooling. It's actually quicker to write something that prototypes the model you're testing -- as little as a few lines of code -- that eventually saves a lot of repetition.

That prototyping later becomes extremely useful for building local databases -- a strong factory suite means I can rebuild my local database and have it completely populated with randomized dummy data. Changing locales on some packages means I can have a local environment populated with data tailored for a completely different country and language, for example.

Re: surfacing bugs -- in a lot of cases yes. And a lot of bugs have been found this way.

[simplify]

It looks like you're mistaking "good programming" for "programming the same way I do".

If a developer can test, that's a good fundamental skill. If they don't use a factory, that says nothing about their fundamentals – it's something you can easily tell someone who knows how to test to go learn & do once they're on the job.

[Clubber]

Especially for something as throw away as a take home coding challenge.

[stevenjohns]

It may be a throwaway for the candidate, for the employer it's $XXX,000 a year and potentially ending the search for better, more suited candidates.

If taking an extra an hour of time to sell your work is "throwaway" then that person is either shotgun applying to jobs (and not being hired for a reason) or they're not taking their application seriously.

[Clubber]

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.

[ThrowawayR2]

> 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.

[Clubber]

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

[ThrowawayR2]

> 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.

[pkaye]

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