My argument is that if you're choosing people to run in a team for a marathon, its only fair to ask them to walk or jog on the spot first, rather than saying 'Oh he's a nice guy/gal' go through the whole process to onboard them and later find out on practice runs through office gossip that they are actually lame and they'll need a guy in the team to carry them across the finish line. Its only unfair if your tests are, dance the salsa or juggle footballs, as while it shows proficiency in foot use, but not in running.
The issue is not with code tests, but how they're designed. If you're talking about getting asked to whiteboad BST re-ordering or to write a string palindrome without google or what is cyclometric complexity of this project or whatever, then yes you're totally right to walk out of there.
We do them. We had bad experience with a senior getting fired while on probation. Not a story to tell here. Another important reason to do them is to see code and git commit quality.
I designed some of the technical tests for my employer. They're based individual actions we need to be familiar with doing our job. For example backend,to show you can understand OOL, expose a function, commit history, etc. For front end its like heres a form, an api, make it look like this in html and css. 30-60 minute stuff.
We had a guy we really liked who aced the non tech interview until we gave him a 60 min test (reality 15 min test) and with ability to google what to do. Barely did anything, blamed the test, so I did in front of him while explaining what I'm doing. I could have been typing in Sanskrit as he couldn't explain what I did to solve it.
Amount of time working in industry means nothing in software development as its so varied and tech changing all the time.
I'm a Developer Relations Manager at Asurion with over 7+ years of development and industry experience. Love just creating stuff and putting it out there!
That's a good point! I think it's important to not "toss the baby out with the bath water".
Personally, coding tests have never been a good metric to test my competence BUT that doesn't mean it's not a great one for others. At a minimum, if administered correctly, it can give you some insight into the developer and how they code and what is their "technical proficiency" in a subset of skills.
Amount of time working in industry means nothing in software development
as its so varied and tech changing all the time.
Sadly, this is BEYOND the truth. I think an important question to ask any developer (especially senior level) is how their skills have progressed over the years and also to see their technical skills in a demonstrable way.
It's sad to say, but I have worked with people who are much more "seasoned" than me but REFUSE to learn how things like Git works because it's not something they like, or, the worst excuse, because they are "not interested in that technology".
Thanks for sharing your thoughts. Always love to hear different and well-thought our perspectives.
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.
My argument is that if you're choosing people to run in a team for a marathon, its only fair to ask them to walk or jog on the spot first, rather than saying 'Oh he's a nice guy/gal' go through the whole process to onboard them and later find out on practice runs through office gossip that they are actually lame and they'll need a guy in the team to carry them across the finish line. Its only unfair if your tests are, dance the salsa or juggle footballs, as while it shows proficiency in foot use, but not in running.
The issue is not with code tests, but how they're designed. If you're talking about getting asked to whiteboad BST re-ordering or to write a string palindrome without google or what is cyclometric complexity of this project or whatever, then yes you're totally right to walk out of there.
We do them. We had bad experience with a senior getting fired while on probation. Not a story to tell here. Another important reason to do them is to see code and git commit quality.
I designed some of the technical tests for my employer. They're based individual actions we need to be familiar with doing our job. For example backend,to show you can understand OOL, expose a function, commit history, etc. For front end its like heres a form, an api, make it look like this in html and css. 30-60 minute stuff.
We had a guy we really liked who aced the non tech interview until we gave him a 60 min test (reality 15 min test) and with ability to google what to do. Barely did anything, blamed the test, so I did in front of him while explaining what I'm doing. I could have been typing in Sanskrit as he couldn't explain what I did to solve it.
Amount of time working in industry means nothing in software development as its so varied and tech changing all the time.
Amen to that, a voice of reason :)
That's a good point! I think it's important to not "toss the baby out with the bath water".
Personally, coding tests have never been a good metric to test my competence BUT that doesn't mean it's not a great one for others. At a minimum, if administered correctly, it can give you some insight into the developer and how they code and what is their "technical proficiency" in a subset of skills.
Sadly, this is BEYOND the truth. I think an important question to ask any developer (especially senior level) is how their skills have progressed over the years and also to see their technical skills in a demonstrable way.
It's sad to say, but I have worked with people who are much more "seasoned" than me but REFUSE to learn how things like Git works because it's not something they like, or, the worst excuse, because they are "not interested in that technology".
Thanks for sharing your thoughts. Always love to hear different and well-thought our perspectives.