As for binary search, I wouldn't necessarily be able to bang it out in two hours in C, but I'd easily be able to bang it out in that time for any language I use regularly. And with sufficient testing I'd take a good stab at converting to C.
Though I agree sometimes it can be a coin toss. Once I was asked to write some code that would take dates as inputs and do something with them, it was supposed to take two hours and run on a bunch of test cases they gave you. I spent much more than two hours on it, nailed all the edge cases and boundary conditions that I could think of (basically nuked it from orbit) and turned in something which ran on their test cases and also a much longer list of much more challenging test cases. I got that job.
I missed one where they wanted something written by TDD. Unfortunately, I only know how to design something that works, I don't know how to fake a bad design that organically grows into a workable design. As above I nuked all the boundary conditions I could think of, but didn't get that job.
(Probably wouldn't have been happy there, my experience is that people who do TDD or automated unit testing have way too much faith in those forms of testing, and they neglect other forms of testing, so their actual net amount of testing is well below my standards. Things like: every single programmer I've ever worked with who claims that automated testing is sufficient has always produced code that when they claim they've finished the task it fails the eyeball test. E.g. you run their code and within 10-30 seconds of looking at the result you can spot something wrong with it.)
