[jhall1468]

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

[stevenjohns]

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

[sitkack]

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.