The typical sort of "test" for "programmers" would be a sort. As this is a well-baked issue, the test is geared at noting if the applicant knows the different types of sort algorithms and the tradeoffs/execution times of each.
The "red flag" being the applicant who doesn't look for more clarification on the number of items being sorted, their characteristics, the nature of the list *before* the sort, how it will be used *after* the sort, etc.
Because it is a relatively *simple* problem, you don't have to worry about "test averse" applicants "choking" in the process.
Of course, if you are looking for "niche" applications, one might ask the applicant to describe scenarios where deadlock can occur, livelock, priority inversion, etc. Or, issues regarding specific protocol stacks, etc.
And, if the programmer will have to interface to hardware, there are a variety of simple challenges that will tell you if he knows the issues that are pertinent, there (and how reality can defy his code's assumptions -- in delightfully clever ways!)
But, "process" is always paramount. Is he a defensive coder, etc.?