> Had to look at the javadoc for those two classes too. Well, I'm a little surprised, but I wouldn't begrudge an interviewee a peek at the javadocs. You should

> Had to look at the javadoc for those two classes too. Well, I'm a little surprised, but I wouldn't begrudge an interviewee a peek at the javadocs. You should be pretty familiar with the API's and how to use them correctly though. > read() returns byte[] Actually, it returns an int. You're thinking of read(byte[]) I think... but it also returns an int. > print() accepts only char[], so you'd need to cast or use write() which accepts byte[], but you need to pass it an offset and the length too: write(byte[] buf, int off, int len). Eh, that's just stupid. I'm happy eclipse tells me that stuff... Eclipse won't tell you that a) you shouldn't use print(char) because you aren't trying to format a character. The offset & length is a pretty common Java idiom, and actually important for getting this right. > If I had to do this at an interview in Java, from the top of my head I'd probably ask if it's okay if I use Apache Commons IOUtils and try to IOUtils.copy(). That's perfectly legit.. if you remember to flush the output stream. > But again, the article talks about language of your choice. I was just a bit shocked when I was able to write this in C and perl without autocomplete even if I practically never use C or perl. The C code is fine enough, though doesn't correctly detect when an error occurs. The perl code is going to potentially chew up a lot of RAM with that input. I agree though that Perl & C make this pretty easy to do right, and Java (along with a surprising number of higher level languages) doesn't.