Hacker News Reader

Comment by jar_cup_bowl | Hacker News Reader

Anecdote: My company has recently passed on a few early career candidates who pretty clearly hadn't been mentored.

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.

View on HN

> Anecdote: My company has recently passed on a few early career candidates who pretty clearly hadn't been mentored.

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.

This. This. This.

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.

Also, I would love to see the quantitative evidence that the value of the design patterns in maintenence are. My guess is that in fact this is a random assertion made by a single engineer.

I'm just sharing my experience as it relates to the article, no need to be inflammatory. Take home assignments are a pretty common assessment tool and many candidates prefer it to getting grilled on DS/Algos on a whiteboard.

> 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

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?

> we went with a different smart and personable candidate who had better early career opportunities

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?

So you allocated scarce resources to the best available candidate you could find? ...or there's something I'm missing...?

The parent is pointing out that they continued the pattern of the setback by denying a candidate the opportunity to learn the skills whose absence resulted in their denial. It's a catch-22 which for them started with their first job out of school.

Reading it, there's at least a 50% chance that learning at this company would've made them worse developers that focus too much on stuff that doesn't really matter.

Reply on news.ycombinator.com