First, give them complete responsibility for a section of code. If they can't make it work after several sprints adding significant new features, they can't code and cannot work effectively work with the team to complete tasks. Developers that cannot code will start something then will give reasons why they cannot work on it then another developer has to complete it for them. Many times they mention best practices and other management speak to cover the fact that they can't code.
Second, after they finish a feature, review their code, structures, and variable names. Bad names, structure, and messy code is a red flag. If they copy code from stack overflow but don't rename variables to match the repo they are coding in, another red flag. Proper indention is also important.
Third, Developers that are good typically type fast once they have worked in a block of code for a while. They can explain what they setup and why. They can diagram what was built.
Fourth, passion isn't a good indicator, but persistence is. The best developers never give up. Have developers explain their most difficult technical issues they faced during the interview. Determine when and why they give up.
Fifth, It is okay if a developer doesn't know something, but if they make the same mistake over and over, be careful. Developers must be able to learn and learn fast. If they don't, they will fall behind and quit/get let go. Most of what we know will be obsolete in 3 years.
Sixth, they can debug and know the debug tools inside and out. They want to know why something works the way it does. Working together with them debugging a few issues is one way to measure their debug skills but it doesn't always work depending on personality.
Seventh, they work well with the team and help wherever and whenever needed. They can joke about the development process. Ask them what was something fun that happened on their last project.
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.
First, give them complete responsibility for a section of code. If they can't make it work after several sprints adding significant new features, they can't code and cannot work effectively work with the team to complete tasks. Developers that cannot code will start something then will give reasons why they cannot work on it then another developer has to complete it for them. Many times they mention best practices and other management speak to cover the fact that they can't code.
Second, after they finish a feature, review their code, structures, and variable names. Bad names, structure, and messy code is a red flag. If they copy code from stack overflow but don't rename variables to match the repo they are coding in, another red flag. Proper indention is also important.
Third, Developers that are good typically type fast once they have worked in a block of code for a while. They can explain what they setup and why. They can diagram what was built.
Fourth, passion isn't a good indicator, but persistence is. The best developers never give up. Have developers explain their most difficult technical issues they faced during the interview. Determine when and why they give up.
Fifth, It is okay if a developer doesn't know something, but if they make the same mistake over and over, be careful. Developers must be able to learn and learn fast. If they don't, they will fall behind and quit/get let go. Most of what we know will be obsolete in 3 years.
Sixth, they can debug and know the debug tools inside and out. They want to know why something works the way it does. Working together with them debugging a few issues is one way to measure their debug skills but it doesn't always work depending on personality.
Seventh, they work well with the team and help wherever and whenever needed. They can joke about the development process. Ask them what was something fun that happened on their last project.