Either that or the candidates you passed on simply didn't want to spend several hours making enterprise-grade software for a take-home test that they're not getting paid for.
Everyone thinks they can interpret their tests perfectly. Ultimately, the candidates are likely better off. The coded message here is not that they didn't use obvious design patterns but that they didn't code in the way the employer wanted. Which...I suppose is a perfectly fine reason to pass on a candidate.
Design patterns? This is a red flag for me. How do you know you're not actually a bunch of unproductive cargo-culters? Those applicants might've dodged a bullet with you there.
> We lamented not being able to hire otherwise smart and personable candidates, but at the end of the day we only had headcount for 1 employee and we went with a different smart and personable candidate who had better early career opportunities.
I see. Did you ever actually ship anything, though?
I just had a similar situation. Was sort of stunned at the number and quality of candidates who applied. One I had to cut loose was just so good I couldn't help but offer to have a follow-up discussion about things she could work on. Curious, is this an HR no-no?
We have a take-home assignment as part of our interview process and they were able to get a working solution, but missed on design patterns that would make their code more maintainable and extensible, things that are usually learned from code-reviews by people who have had the experience of working with bad code.
This was more common in candidates who came to us from the tech departments of non-tech focused companies.
We lamented not being able to hire otherwise smart and personable candidates, but at the end of the day we only had headcount for 1 employee and we went with a different smart and personable candidate who had better early career opportunities.