In Java 7 you can use Files.readAllLines to read file to string, also there is a built-in CSV parsing library, it's called String.split() :)
It's best to use a library for this like SuperCSV: http://supercsv.sourceforge.net
22 people failed the test entirely, complaining about quotes and line ending inconsistency.
2 people wrote a proper state machine driven parser that didn't work.
1 person wrote a proper state machine driven parser that worked.
1 person imported commons-csv and wrapped stuff.
The last person got the job.
You probably missed three really good candidates here.
We hire engineers.
An analogy: would you hire the electrical engineer who knocks up an ASIC for every task or the one who designs in a COTS part for a predictable unit cost and manufacturing lead time?
Look, the fact is, based on the replies below, this guy is probably better off working somewhere else.
Not to go off on this particular person, the preoccupation with "Library Knowledge(tm)" in the enterprise (so, Java) world has become an epidemic. I have seen libraries used for all the wrong reasons, pulling in great gobs of someone elses code to do a bloody string copy!
Damn, you are hiring coders. Let them fricken code, for God's sake.
Please, I know all of the counter arguments (I've been harangued by them for years), but I really think that there is a middle ground here. Some things are truly worth bringing into a project via library. Big things, things that are really hard things that you may not have the staff to handle. But if we are afraid to let coders code some stuff, even trivial stuff, then we have killed the one true joy that we had in the first place: coding!
One thing to remember about libraries is that they have bugs too! Just because someones got an apache page, doesn't mean that there are no bugs in there lurking. You WILL most probably need to understand the problem/solution well enough to use the library in the first place.
Gosh, rant off.
(I agree with the rest, anybody can more or less learn their way around a library with a little time, but learning to actually code well is a much more valuable skill and much more rare).
Experienced engineers will trade off a COTS solution against build. Inexperienced engineers will machine 2000 M3x12 screws by hand.
Just because you're an engineer doesn't mean we want you to sit in front of a lathe/mill all day.
Libraries wouldn't exist if we didn't want to reuse work. With respect to more bugs in libraries, this is rarely the case for established products. In fact by writing our own code with similar intent will almost certainly incur more test effort, more odd edge cases and more $$$.
Final point: I wrote some code a few years ago in Java that spoke to .doc files, databases, a SOAP API and a service bus. It was (excluding blank lines and bracketed lines) 2900 lines of code with 850 unit tests. It handles over a million insurance contracts a year. This would have not been possible if I'd written ANY component myself.
I was paid to solve the problem, not write those libraries again.
The thing is clearly marked "pragmatic solutions" rather than most interesting as well.
Geez, I think I've already reimplemented that half a dozen times. Of course it would be buried in the Files class and not one of the 30 dozen buffer reader whatever classes I have to piece together.
> String.split()
Yeah yeah, that's what all the Java books say ;)