> 1) you understand best practices

Tests prove no such thing. Best practices aren't about output, they are about inputs. Tests determine if the expected output is the real output.

> 2) you know how to write testable (readable, maintainable, clean and clear) code.

Again, no they don't. I can test unreadable, unmaintainable dirty and unclear code.

> if instead of using factories (or Faker or some other strong dummy data app) they instead decide to hardcode usernames and passwords, it's a huge red flag.

No it doesn't. It shows that it's an arbitrary take home assignment that already took a week and they don't want to use yet another library to generate data for it.

Honestly, you put so much emphasis on testing which is odd, because it's the easiest, most mundane thing to write. It provides nothing but "busy" work and fails to test the most important aspect of any candidate: can they problem solve.

> Tests prove no such thing. Best practices aren't about output, they are about inputs. Tests determine if the expected output is the real output

Testing in and of itself is best practices. Having familiarity with and a strong understanding of how and what to test is extremely important for any modern development cycle.

> Again, no they don't. I can test unreadable, unmaintainable dirty and unclear code.

Except it's significantly more difficult.

> No it doesn't. It shows that it's an arbitrary take home assignment that already took a week and they don't want to use yet another library to generate data for it

If you don't have a strong dummy data suite to test against, then you're not testing properly. This actually justifies exactly what I'm talking about.

> Honestly, you put so much emphasis on testing which is odd, because it's the easiest, most mundane thing to write. It provides nothing but "busy" work and fails to test the most important aspect of any candidate: can they problem solve.

If it's mundane and easy then it should just be done. What I've found is that most can't.

If the candidate pool was small, then I'd take less of an issue to it. But if 50 people come in and they can all problem solve, then I'm going to become more interested in who can solve problems elegantly.

Directed at you and the parent. A better way to structure this is ask for at least one integration test, then tell the candidate that testing strategy and methodology will be discussed in the review.

I had a coding test, not take home, where I was able to code on my own on a simple problem for about 45 minutes for each session then have a code review. We did this three times over three hours on increasingly harder problems.

This exact same format could be done remotely.

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

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.

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.

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

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.

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.

Examples like this are why I think take-home challenges are a better way to assess a candidate's coding skills vs. their problem solving skills/how they think.