You don't even need a week if you have access to the internet, which as a dev you will. (Or with just Clojure's repl-docs you could probably come up with `(with-open [rdr (reader file-name)] (doseq [line (line-seq rdr)] (let [parsed (.split line ",")] ...)))` fairly quickly, and even if you forgot the specific reader syntax remembering the more memory-intensive `slurp` for a year seems doable and ought to be acceptable in an interview.) If you hadn't been doing Python for a year would you still remember the existence of the CSV module you can import, and then use dir() and help() on if you forgot the exact syntax?

The particular example of reading a csv file is just a bad one to compare C and any dynamic language with, because in C file IO is a pain in the neck with a lot of pitfalls whereas dynamic languages make it lovely and you only have to remember a small amount. I guess it's a decent test to see if one's potential C coder has memorized all the details about C's file IO, maybe the company does a lot of that since they create libraries for others or something. (Did you allocate enough memory on the stack/heap? Are you reading byte-by-byte looking for a newline or in chunks before looking? Are you checking if you need to re-alloc? Do you support "\n", "\r", and "\r\n"? Are you checking for E_NO_MEMORY and E_BAD_SOURCE? Are you using sprintf safely? Are you checking for end-of-file correctly? Are you tokenizing the line properly? Are you faster than Python? Etc.) If the interview is just looking for coders who can "fopen, fread with malloc, and fclose, it's okay if details are forgotten", then it's just a weeder question rather than a skill test and there are better weeder questions.

Personally I have a handful of C programs on hand that I know are correct and that do various IO stuff, I tend to just copy from those on the rare occasion I need to use C to do manual file IO or memmapping (we all remember the subtleties of that right?) because of the reasonably high probability I'll forget one of the many details if I do it from scratch. I much prefer using already existing libraries to read and parse for me; there's too much reinventing-the-dysfunctional-wheel culture in C.

I used Lisp and Python as examples because I don't know C myself. In any case, the point was that when people say they know a technology, they might mean that they can answer any question you can come up with, or they might mean that they once knew it, and can become proficient with it again in a short time. Of course, some people don't actually know anything about it, but I doubt this number is quite as high as 80%.

I can believe the 80% number. I don't know any formal studies (surely there have been some by now?) but I've heard and read a lot of anecdotes (like the one in this thread) from technical interviewers about how a high percentage of their applicants can't write code or are in some other way incompetent for the job; I have yet to hear from one about how almost all their applicants are awesome and they wished they could hire them all. If you haven't seen the accounts about the FizzBuzz problem alone (and the hilarious failures of people online with no stress or time constraints pasting their incorrect solutions in blog comments to prove their skillz) it's worth half an hour of your time to read about it.

What if I promised you gainful employment and gave you as much time as you wanted to prepare ? Yeah most people think "I know C its just like C++/Java". A good 75% of the people who fail don't even invoke malloc once.

It's one thing if you tell them before hand "C, C, it's all about C here!" But every interview I've had has been pretty flexible in letting me choose what language to use.