We didn't really. They, respectively, didn't finish the entire test, over-engineered a few of the other questions and failed the comprehension test (we test the ability to understand requirements as well).
The thing is clearly marked "pragmatic solutions" rather than most interesting as well.
>>1 person wrote a proper state machine driven parser that worked.
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.
We pay people for robust solutions, not to write code. It's a whole lot more complicated than "just programming". In fact we'd rather they wrote less code and did more thinking.
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.
In my mind the bigger issue is that something like CSV parsing is so common, and so old that it just should be part of every higher level language's standard library these days, as common as split() is. That way people learning the language learn that you just do it with the library and get on with it.
(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).
I thought for coding tests implementations are supposed to be done from scratch on. Or at least the guy who wrote the working parser should be on top of the list.
Not really. We want people to solve the problem, not invent something that needs maintenance. In some cases, from scratch is important, but for most it's not.
No we don't want competent people showboating and pissing cash up the wall reinventing wheels that have a high maintenance cost because it's fun.
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?
The thing is clearly marked "pragmatic solutions" rather than most interesting as well.