I bet a higher percentage of people would have been able to do things like that in the days of batch processing. I'm getting middle aged, and I grew up with interactive microcomputers. So from the very beginning I was used to typing something into the computer and getting instant feedback. I'm even a bit superstitious when a program compiles/executes with no syntax errors, because I feel like it bodes ill for deeper bugs. So while it seems like very simple coding problems should be a good way to weed out useless programmers in interviews, the fact is, people like me are not very good at programming on a whiteboard, and don't have to do it, because there are employers who don't use such tests. I will say that implementing a binary search is something I have found useful in "real life" - in a SQL database I dealt with a table that had an index on a synthetic key while I wanted to look it up by a non-indexed date. For a simple query, the optimizer couldn't do that efficiently because it didn't know the columns were in the same order. But an explicit binary search could exploit the index to find a date. I didn't do it correctly the first time, nor could I do it quickly enough for an interview. But I got the job done.