A test can be quite long lived. Assume you are looking for 10 software engineers (of same position, but different levels). Then you probably have to interview 100 candidates over the course of several months.
Even if I would design a test for each level (working-student, junior, intermediate, senior, principal ... Too much!) copying is still a possibility, e.g. choise of technology.
An openly constructed test that tests for skills, mindset and approach is much better suited in these situations. You learn much more too and you have an intro into the technical interview as well, as you will start asking about the test a lot – hopefully leading into a meaningful conversation.
This also allows you to actually judge the level of the candidate instead of hoping he applied for the right level.
A good test does not require a specific solution nor a specific level of knowledge but probes and challenges a candidate on all levels. It is also only the foreplay to the technical interview.
Valid points but our tests don't say anything about how to implement it.
I would never say in a test using this lib and this framework.
Usually, the candidate has their freedom. So if someone would come with the exact solution it would be very obvious.
Like for a full stack dev using exactly the stack would be amazing because you have so many stacks, libs, frameworks out there.
Yes its most of the time never about the actual implementation. It about will the candidate fit into the company/team and what is his mindset.
A big point for me is also will he/she function in a team.
We all know the rockstars that write "the best" code but nobody except them understands what is happening because he or she refuses to play well with the team. Also, other things that are more about soft skills than the actual coding skills.
I see the point that for some companies it can be a problem that the solution for the task is somewhere on GitHub.
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.
Interesting. We change the test depending on the level of the candidate.
Do you only interview one per level/position?
A test can be quite long lived. Assume you are looking for 10 software engineers (of same position, but different levels). Then you probably have to interview 100 candidates over the course of several months.
Even if I would design a test for each level (working-student, junior, intermediate, senior, principal ... Too much!) copying is still a possibility, e.g. choise of technology.
An openly constructed test that tests for skills, mindset and approach is much better suited in these situations. You learn much more too and you have an intro into the technical interview as well, as you will start asking about the test a lot – hopefully leading into a meaningful conversation.
This also allows you to actually judge the level of the candidate instead of hoping he applied for the right level.
A good test does not require a specific solution nor a specific level of knowledge but probes and challenges a candidate on all levels. It is also only the foreplay to the technical interview.
Valid points but our tests don't say anything about how to implement it.
I would never say in a test using this lib and this framework.
Usually, the candidate has their freedom. So if someone would come with the exact solution it would be very obvious.
Like for a full stack dev using exactly the stack would be amazing because you have so many stacks, libs, frameworks out there.
Yes its most of the time never about the actual implementation. It about will the candidate fit into the company/team and what is his mindset.
A big point for me is also will he/she function in a team.
We all know the rockstars that write "the best" code but nobody except them understands what is happening because he or she refuses to play well with the team. Also, other things that are more about soft skills than the actual coding skills.
I see the point that for some companies it can be a problem that the solution for the task is somewhere on GitHub.