[_odey]

Now take that list, throw it in the rubbish bin and wash your hands thoroughly.

Take home challenges are simply an absurd waste of time and a huge disrespect towards your candidates personal time. You ask them to spend 4 or more hour of their free time on a useless, throwaway excersise that you "review" in 5 minutes and you conclude they're good enough because they laid out code the way you like it... You never see the really important things that you should be screening for: how they explain their approach, their though process, how well they communicate, the compromises they had to make to fit within the timeframe, and why they'd made those compromises, how they react and adapt to changing requirements and feedback...

It's just flawed on so many levels...

As a new Engineering Manager I've eliminated the take home challenge in my new company in favour of this process:

- You have open source code or closed code that you can show? Walk me through it. Our best engineers passed the interview this way.

- You don't have code to show, 1 hour live coding challenge, focus on communication, search want you want online, ask us any questions, and explain what you're doing.

We had about 40 such interviewes this year, one person refused the live challenge, 11 passed this stage, and we ended up with 7 hires accepting the offer.

If you lack inspiration, use this: https://github.com/guardian/coding-exercises

[matthewmacleod]

Your process seems equally flawed. Many excellent candidates have no open-source code, and if they show you any closed-source code that's an immediate signal against hiring them.

So now you've put candidates through a silly "live coding challenge" – offering an advantage to the sort of person who is chatty and communicative with strangers in a stressful environment and the expense of people who may be better engineers but slower to warm up.

I really wish folks would be way less dogmatic about this stuff. Every single time I see someone say "take-home exercises are bad", their proposed alternative is also critically flawed.

[_odey]

It might be flawed in terms of filtering out the type of person that does not do well in live pairing scenarios.

But I disagree it's _equally_ flawed. The time investment from a candidate is significantly smaller at the cost of more time investment from the employer's side (aka my side). Personally I consider this a reasonable trade-off.

[time_to_smile]

Another huge problem with take home challenges is that they are one time use. At least if you're grinding leet code questions you're spending time that is useful at multiple companies.

I have a big folder on my computer of homeworks I've finished for various companies over the years. If I recall I passed all of them, it's sort of annoying that I can't simply hand over this list of other projects I've passed and say "here, all of these companies thought this was good".

What I like about your proposal is that if many other companies did it, the result would be every few years I should take a month of evenings and build out a cool project for myself demoing my ability to write code. If life gets to busy, it's fine if the project ages a bit.

This way you can scratch a personal itch and prep for interviews all the same time.

[alexyang21]

Did the companies tell you no when you asked them if you could share a previous project instead of completing theirs? From talking to many hiring managers, they also don't want to waste your time, and most will be happy to accept an alternative if it show similar skills to the ones they're looking for. I'm even seeing more teams offering this as an explicit option now.

There will always be a few who say no (IMO this could be a warning sign), but it doesn't hurt to ask :)

[_odey]

> it's sort of annoying that I can't simply hand over this list of other projects I've passed and say "here, all of these companies thought this was good".

Why not?

Put them in a repository, and in your cover letter when applying to a new company paste a link to it, and say exactly that.

It's your code after all.

[m0llusk]

As a software engineer with significant experience I think the option to explain some existing code is valuable. This option allows me to show my skill with something that is typically more interesting and demonstrative than a quick coding test. As a professional I also value my time and find explaining how I know I can help with what needs to be done takes far less time and effort than going through a coding test and then discussing that.