Thank you for your remark. It's in fact a questionable technique for developer evaluation. But with everyone learning to code, what's your take on the subject?
From my own experience, far more reliable information can be gleaned from questions like
what libraries and frameworks do you regularly use and [this being the important bit] what do you like and dislike about them, what are their strengths and what are the issues you tends to get when using them?
what are the organisational and process issues you have noticed in different teams in the past? and how have you (and the team) tried to remedy them?
how would you define reliable code? How does reliability relate to things like security, return-on-investment, time-to-production, etc?
What these kind of open-ended questions offer, is that they let you evaluate how your prospective team mate handles problems and to what degree their knowledge goes beyond textbook stuff and relates to the real-world practicalities of software development.
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.
Thank you for your remark. It's in fact a questionable technique for developer evaluation. But with everyone learning to code, what's your take on the subject?
From my own experience, far more reliable information can be gleaned from questions like
What these kind of open-ended questions offer, is that they let you evaluate how your prospective team mate handles problems and to what degree their knowledge goes beyond textbook stuff and relates to the real-world practicalities of software development.