I've been interviewing a fair bit lately, and I just really struggle with what you say above. To me if you can't write that simple program in some language without looking at an API or consulting Google at every turn, it feels like you haven't used the language enough (either that, or the problem isn't in a domain your familiar with, but you can usually tell which it is pretty quickly).
I don't deduct points for not getting the syntax precisely, but if they don't know the very basics of "open()" and "for line in file" and "int()", but say they have 3 years Python experience, I'm thinking No Hire.
And that's where we disagree. I think this whole "FizzBuzz" craze is as equally stupid as the riddle craze was.
My brain, right now, is working on a way to pop messages off of a RabbitMQ queue onto a clustered pool of Akka workers while minimizing the duplication of work and avoiding race conditions in the output.
My career experience is in Java with a sprinkling of Python. I honestly cannot recall off the top of my head the I/O Api to do that task. Let alone on a whiteboard or in some shared google doc.
Hm, I need to open a file. OK, no problem - new java.io.File(path). Er, wait, I remember there's a FileReader. Probably should use that. Do I need a File first? Or can I just give FileReader the path? Ah, shit - I need to read each line. I think that's a BufferedReader. How do I get from a FileReader to a BufferedReader? Is it constructor param? Wait, maybe FileReader _IS_A_ BufferedReader.
So, I 'fail' the interview with you. Maybe your company has a need for someone who can write a 10 line script that can read a file line by line without having to look at the API while being timed.
In that case, yes, you probably have weeded out a bad candidate.
It's surprisingly easy to make it a long time without needing to read from a file. If you're writing web apps, you almost never read directly from a file; all of the input comes from a database or HTTP requests.
* Libraries for reading arbitrary size integers
* and for computing with arbitrary size integers
* Efficiently handling files larger than RAM
* Error handling when the file is not as promised?
Should an interviewee just have all those APIs memorized in advance? Even in this age when reading an unformatted text file is so far from common?
I don't deduct points for not getting the syntax precisely, but if they don't know the very basics of "open()" and "for line in file" and "int()", but say they have 3 years Python experience, I'm thinking No Hire.