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.
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.
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.
* 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?