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.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.