I'm a big supporter of the take home challenge (as opposed to timed, on-the-spot coding tests, which I think are idiotic, tell you nothing about developer skills, and paint you and your company as fostering a culture of micromanagement), precisely because some candidates are too busy working on proprietary stuff (or just had a college/boot camp experience that didn't emphasize GitHub/portfolio) to stand out without it. If a candidate does have a rich GitHub/portfolio, I may just skip the take-home challenge and do a code review interview over their prior code instead. Either way, I need them to defend their decisions in that follow-up interview (even if some of the solution came from Stack Overflow/other GitHub projects).
My issue with the take home challenge is that I feel like we are constantly being forced to prove ourselves. If you know that your skills match the job description then you should not have to keep being tested it's just another roadblock to deny you employment. Doing one take home challenge might not be too bad. But it's typical for a job seeker to be interviewing at multiple companies at the same time so you might have a combination of take home challenges and timed exams in addition to general interview preparation.
Thats a lot of work and stress and its very easy to not do too well on a test despite having the skills because of the added pressure and your busy diary. Plus you have to take into account the time that it takes for the company to give you feedback on the test. That requires more waiting and if you end up being rejected or ghosted which happens all the time then your confidence takes a hit and you start to get imposter syndrome. This leads to periods where you decide to take a break from looking for work because it feels like the bar is being set too high for something as trivial as HTML, CSS and javascript.
And the code you write for any new take home tests might not be at your best as you are feeling in a low state. Giving companies the impression that you are not the right fit when really you have just become exhausted of doing tests and having recruiters and hiring managers play mind games with you.
As you can see in my top level comment, I'm with you on almost everything you mention here - and I absolutely despise both the timed, on-the-spot challenge (as I said here and elsewhere, it's not going to tell me anything useful about you anyway, because that's not how devs work), and the way companies expect you to be perfect and do so much, but then can't so much as send a rejection email (even automated is better than nothing), is despicable.
And as for trying to complete a code challenge while you have a job (and a life), that's why I feel it should be limited to no more than a few hours of work max, and given ~1 week to complete. That way you can take your time working on it, reason about it as you go, and go at it in larger chunks on the weekend (or whatever your days off are) if you want/need to. And any candidate who meets (or comes close to meeting) the requirements of my code challenge will get a follow-up code review interview. It's only fair that I give them my time, even if only to give constructive advice for improving. I also check in every few days (just an email here and there to see how they're doing and ask if I can clarify anything, and if they may need more time), and let them know that I'm available to answer their questions at any time during the timeframe.
What sticks out to me in your last comment is:
I feel like we are being constantly forced to prove ourselves.
That's never going to change. You have to make the case to any prospective employer that not only is your code up to snuff, but that you can meet requirements and do so both in a reasonable timeframe (again, not an hour, on-the-spot, while they're looking over your shoulder) and with a personality that isn't going to be a detriment to others involved.
If you know that your skills match the job description then you should not have to keep being tested
You may know that, but the one trying to give you money (and not an insignificant amount, comparatively speaking) may not. That's the point of testing.
As I said before: There's a case to be made, if you have an outstanding portfolio and GitHub (I do not, due to lots of proprietary work, and I'm architect/CTO level), that you should be fast tracked through to an interview that is basically a code review of what you've already written, skipping the code challenge; however, you're still going to have to shine in your explanations and prove that you won't just rest on your laurels as having already proven yourself. You may have to others. That doesn't mean you've proven it to me.
Well fair enough I guess I can agree with that. I just think that the whole interview process is broken in general. Having to spend hours doing a take home challenge just to get ghosted with no feedback is soul destroying. It leads straight to imposter syndrome and self doubt you start to second guess the code that you write.
If all take home challenges had constructive feedback and no ghosting then it would feel like time well spent. And what I said about having to constantly prove yourself I just meant that occurs when you get burned out from a long and exhausting job search which has led to no job offers. It's fine for the first month or so but any longer and the imposter syndrome makes an appearance and that is destructive for any job seeker.
It was fun reading your discussion. But as we can all see — while some things we agree on, others we do not, and we all have different expectations of different perceived experience for a candidate whether it is ourselves or of others. Every tool has a scenario that it cannot cover. I’ve come to think that it’s reductionist to think that the entire industry and hiring in tech is just broken.
It’s just not perfect and there is something to be said about how much the bar has been raised with regard to algo problems at big companies. Don’t get me wrong, a healthy understanding and knowing what tools are available and being able to talk through a problem and how one might tackle it should lend a lot of insight already. The expectation of a working and near optimal solution is a little absurd.
I think a stupendous point was made about “not resting on laurels”. I’m a little shocked that we don’t do the following — 1. baseline capability of understanding and knowledge around some topics, 2. Evaluate quality of existing works, and 3. The desire to learn. I want to really emphasize that last point, because we used to be able to say that it isn’t measurable. But it is! For someone with experience, there is likely activity on their GitHub with a history of things they’ve dabbled in and a record of projects they’ve engaged with either by contribution, questions, or bug reports. Sure, there are stints where a particular person works on only proprietary software or even a completely different VCS, but as one of you had stated, such opacity lends itself to deeper inquiry
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm a big supporter of the take home challenge (as opposed to timed, on-the-spot coding tests, which I think are idiotic, tell you nothing about developer skills, and paint you and your company as fostering a culture of micromanagement), precisely because some candidates are too busy working on proprietary stuff (or just had a college/boot camp experience that didn't emphasize GitHub/portfolio) to stand out without it. If a candidate does have a rich GitHub/portfolio, I may just skip the take-home challenge and do a code review interview over their prior code instead. Either way, I need them to defend their decisions in that follow-up interview (even if some of the solution came from Stack Overflow/other GitHub projects).
My issue with the take home challenge is that I feel like we are constantly being forced to prove ourselves. If you know that your skills match the job description then you should not have to keep being tested it's just another roadblock to deny you employment. Doing one take home challenge might not be too bad. But it's typical for a job seeker to be interviewing at multiple companies at the same time so you might have a combination of take home challenges and timed exams in addition to general interview preparation.
Thats a lot of work and stress and its very easy to not do too well on a test despite having the skills because of the added pressure and your busy diary. Plus you have to take into account the time that it takes for the company to give you feedback on the test. That requires more waiting and if you end up being rejected or ghosted which happens all the time then your confidence takes a hit and you start to get imposter syndrome. This leads to periods where you decide to take a break from looking for work because it feels like the bar is being set too high for something as trivial as HTML, CSS and javascript.
And the code you write for any new take home tests might not be at your best as you are feeling in a low state. Giving companies the impression that you are not the right fit when really you have just become exhausted of doing tests and having recruiters and hiring managers play mind games with you.
As you can see in my top level comment, I'm with you on almost everything you mention here - and I absolutely despise both the timed, on-the-spot challenge (as I said here and elsewhere, it's not going to tell me anything useful about you anyway, because that's not how devs work), and the way companies expect you to be perfect and do so much, but then can't so much as send a rejection email (even automated is better than nothing), is despicable.
And as for trying to complete a code challenge while you have a job (and a life), that's why I feel it should be limited to no more than a few hours of work max, and given ~1 week to complete. That way you can take your time working on it, reason about it as you go, and go at it in larger chunks on the weekend (or whatever your days off are) if you want/need to. And any candidate who meets (or comes close to meeting) the requirements of my code challenge will get a follow-up code review interview. It's only fair that I give them my time, even if only to give constructive advice for improving. I also check in every few days (just an email here and there to see how they're doing and ask if I can clarify anything, and if they may need more time), and let them know that I'm available to answer their questions at any time during the timeframe.
What sticks out to me in your last comment is:
That's never going to change. You have to make the case to any prospective employer that not only is your code up to snuff, but that you can meet requirements and do so both in a reasonable timeframe (again, not an hour, on-the-spot, while they're looking over your shoulder) and with a personality that isn't going to be a detriment to others involved.
You may know that, but the one trying to give you money (and not an insignificant amount, comparatively speaking) may not. That's the point of testing.
As I said before: There's a case to be made, if you have an outstanding portfolio and GitHub (I do not, due to lots of proprietary work, and I'm architect/CTO level), that you should be fast tracked through to an interview that is basically a code review of what you've already written, skipping the code challenge; however, you're still going to have to shine in your explanations and prove that you won't just rest on your laurels as having already proven yourself. You may have to others. That doesn't mean you've proven it to me.
Well fair enough I guess I can agree with that. I just think that the whole interview process is broken in general. Having to spend hours doing a take home challenge just to get ghosted with no feedback is soul destroying. It leads straight to imposter syndrome and self doubt you start to second guess the code that you write.
If all take home challenges had constructive feedback and no ghosting then it would feel like time well spent. And what I said about having to constantly prove yourself I just meant that occurs when you get burned out from a long and exhausting job search which has led to no job offers. It's fine for the first month or so but any longer and the imposter syndrome makes an appearance and that is destructive for any job seeker.
It was fun reading your discussion. But as we can all see — while some things we agree on, others we do not, and we all have different expectations of different perceived experience for a candidate whether it is ourselves or of others. Every tool has a scenario that it cannot cover. I’ve come to think that it’s reductionist to think that the entire industry and hiring in tech is just broken.
It’s just not perfect and there is something to be said about how much the bar has been raised with regard to algo problems at big companies. Don’t get me wrong, a healthy understanding and knowing what tools are available and being able to talk through a problem and how one might tackle it should lend a lot of insight already. The expectation of a working and near optimal solution is a little absurd.
I think a stupendous point was made about “not resting on laurels”. I’m a little shocked that we don’t do the following — 1. baseline capability of understanding and knowledge around some topics, 2. Evaluate quality of existing works, and 3. The desire to learn. I want to really emphasize that last point, because we used to be able to say that it isn’t measurable. But it is! For someone with experience, there is likely activity on their GitHub with a history of things they’ve dabbled in and a record of projects they’ve engaged with either by contribution, questions, or bug reports. Sure, there are stints where a particular person works on only proprietary software or even a completely different VCS, but as one of you had stated, such opacity lends itself to deeper inquiry