I hear the opposite. They are stressing a technical opinion here, but for the sake of rationality and efficiency. These are usually not the same people that are overly concerned with "correctness" when communicating with others.
But it is only 'rational and efficient' if you are being obtuse... they aren't asking you to code a CSV parser because they actually need a CSV parser, they are asking because they want to see you code. The 'rational' thing to do is satisfy THAT requirement, which is the real one, not try to bypass the purpose by insisting on using a CSV library.
The ability to understand the underlying need behind a request is important to being a good employee. If a candidate fails completely to understand the purpose of a question during an interview, and in fact continues to argue against you as you explain it, they aren't a good candidate at all.
> The ability to understand the underlying need behind a request is important to being a good employee. If a candidate fails completely to understand the purpose of a question during an interview, and in fact continues to argue against you as you explain it, they aren't a good candidate at all.
I agree with everything you've said, but that still makes it a bad and equally obtuse question. If they don't actually need a CSV parser, they don't need to know that you can parse CSVs, either (if you can - which is the other point - you might be a pretty good programmer if you can quickly parse a CSV, but there are tons of excellent programmers who can't).
I recently couldn't use a built-in CSV parser and had to roll my own because one of our clients couldn't be arsed to send us consistently formatted CSV files so we had to include a bunch of edge cases in there to still correctly format the damn things. (sometimes pipe-delimited, other times comma delimited, sometimes fields surrounded by quotes, other times no quotes except one column (that has a LASTNAME, FIRSTNAME" in it), yet still other times has quotes in the data itself, fields usually have no commas, but sometimes this one field will have it in the middle of it, typos in header names, not including the end of file checksum that others include, etc). The built-in CSV reader you had to specify if the fields had surrounding quotes or not for the entire document, it didn't detect it on its own, for example.
And that was when I found out parsing something that should be as stupid simple as CSV file can actually be pretty complicated.
I'll argue that a one-liner IS code. That's what I put into production systems.
I understood the "purpose" of the question and I self-selected myself out of a role I would've been bored, micromanaged at, and probably not challenged at.
