I'll agree that take away coding challenges do not work. However some form of coding/technical assessment is necessary in my opinion.
An approach that I think works better is an in-interview coding challenge. Difficult to pose the right problem that you can glean enough from in a short period of time, or that can differentiate great developers from ok ones. Works well if you have some ambiguities in the problem - you can see if they're comfortable asking questions and whether they ask the right ones.
It's good for filtering out people who just can't write code - which is surprisingly common unfortunately. I've done this exercise with people with 10+ years experience at big companies who can't write a line of code.
The carpenter analogy someone else made doesn't work here. You can't be a mediocre carpenter and hide in a big team - your output is much more tangible and measurable in a profession like that.
That can work but I would argue it depends on the personality.
Some people would feel very uncomfortable having someone watch them code over their shoulders and would program 5 times worse than in their preferred settings.
I think you need a variety of way to evaluate candidates, which will include in-interview coding challenge, looking at their GitHub project, refactoring a pull request, whatever, and pick one that is a fair assesment of the candidate depending on who she is.
Strongly agree that if there is a coding challenge then it shouldn't be during the interview. That kind of pressure will skew the result and won't be representative of their skill.
Absolutely, that makes a lot of sense!
I was at a competitive programming night at a company this week, and in this context, freely accepted, free of pressure for your financial survival, the challenge is totally OK.
yh it does require the interviewer to make the candidate feel at ease. It can work like pair programming and I will give more guidance to more junior candidates. I will also encourage them to use Google or whatever else they need - I'm looking at how they approach the problem not their ability to remember basic syntax.
Sadly very view CVs that I see have GitHub profiles linked. The candidates that do certainly stand out. Refactoring a pull request is a good idea.
Coding challenges don't work. They're either so easy an AI can do them, or so hard they eliminate all their candidates and most likely half of their currently employed devs for that matter. They're going to become even more ridiculous now, with over-achieving people trying to come up with coding challenges to fool AI. It's easy to validate whether a candidate can do what they say they can. Just look at their resume. If they worked somewhere for longer than a month, they probably weren't fired on the spot for pretending to be able to do something they couldn't do. Not to mention most devs will have public github profiles that yo can look at. You can literally see exactly what kind of code they committed.
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'll agree that take away coding challenges do not work. However some form of coding/technical assessment is necessary in my opinion.
An approach that I think works better is an in-interview coding challenge. Difficult to pose the right problem that you can glean enough from in a short period of time, or that can differentiate great developers from ok ones. Works well if you have some ambiguities in the problem - you can see if they're comfortable asking questions and whether they ask the right ones.
It's good for filtering out people who just can't write code - which is surprisingly common unfortunately. I've done this exercise with people with 10+ years experience at big companies who can't write a line of code.
The carpenter analogy someone else made doesn't work here. You can't be a mediocre carpenter and hide in a big team - your output is much more tangible and measurable in a profession like that.
That can work but I would argue it depends on the personality.
Some people would feel very uncomfortable having someone watch them code over their shoulders and would program 5 times worse than in their preferred settings.
I think you need a variety of way to evaluate candidates, which will include in-interview coding challenge, looking at their GitHub project, refactoring a pull request, whatever, and pick one that is a fair assesment of the candidate depending on who she is.
Strongly agree that if there is a coding challenge then it shouldn't be during the interview. That kind of pressure will skew the result and won't be representative of their skill.
Absolutely, that makes a lot of sense!
I was at a competitive programming night at a company this week, and in this context, freely accepted, free of pressure for your financial survival, the challenge is totally OK.
yh it does require the interviewer to make the candidate feel at ease. It can work like pair programming and I will give more guidance to more junior candidates. I will also encourage them to use Google or whatever else they need - I'm looking at how they approach the problem not their ability to remember basic syntax.
Sadly very view CVs that I see have GitHub profiles linked. The candidates that do certainly stand out. Refactoring a pull request is a good idea.
Coding challenges don't work. They're either so easy an AI can do them, or so hard they eliminate all their candidates and most likely half of their currently employed devs for that matter. They're going to become even more ridiculous now, with over-achieving people trying to come up with coding challenges to fool AI. It's easy to validate whether a candidate can do what they say they can. Just look at their resume. If they worked somewhere for longer than a month, they probably weren't fired on the spot for pretending to be able to do something they couldn't do. Not to mention most devs will have public github profiles that yo can look at. You can literally see exactly what kind of code they committed.