I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
Hiring the wrong person because they happened to know exactly the subset of information needed to pass the coding test part of the interview is arguably even more expensive of a mistake, especially when six months down the road you switch to a different platform and they aren't able to learn it in time to be a contributing member of the team.
Learning is a skill. Especially so when it's on-the-job with a deadline. I'd much rather have someone who knows hos to find the correct answer than someone who just knows it, because being able to find the correct answer is quite simpy much more useful long-term.
If I'm in an interviewing position, I'd let the interviewee search (and use an actual development system with proper tools), but I'd be making a point to pay attention to how they're going about completing the test, how they're searching, what they're searching for, whether or not they're cross-validating information, etc. From that, you can get a rather good idea not just of how knowledgeable they are about the subject area, but also how well they work in general, and how confident they are in their own knowledge (hiring someone who's overconfident in their knowledge of something is arguably worse than hiring someone who has no knowledge of it whatsoever).
This is a good reply, I guess I didn’t think about how much you can learn from seeing someone’s workflow. I wonder why more companies (correct me if I’m wrong) don’t do pair programming or something similar to help evaluate that.
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.
Hiring the wrong person because they happened to know exactly the subset of information needed to pass the coding test part of the interview is arguably even more expensive of a mistake, especially when six months down the road you switch to a different platform and they aren't able to learn it in time to be a contributing member of the team.
Learning is a skill. Especially so when it's on-the-job with a deadline. I'd much rather have someone who knows hos to find the correct answer than someone who just knows it, because being able to find the correct answer is quite simpy much more useful long-term.
If I'm in an interviewing position, I'd let the interviewee search (and use an actual development system with proper tools), but I'd be making a point to pay attention to how they're going about completing the test, how they're searching, what they're searching for, whether or not they're cross-validating information, etc. From that, you can get a rather good idea not just of how knowledgeable they are about the subject area, but also how well they work in general, and how confident they are in their own knowledge (hiring someone who's overconfident in their knowledge of something is arguably worse than hiring someone who has no knowledge of it whatsoever).
This is a good reply, I guess I didn’t think about how much you can learn from seeing someone’s workflow. I wonder why more companies (correct me if I’m wrong) don’t do pair programming or something similar to help evaluate that.