Here's a general style of problem that I've asked a few different ways and have been happy with: 1.) I provide an API (some function signatures and documentati

Here's a general style of problem that I've asked a few different ways and have been happy with: 1.) I provide an API (some function signatures and documentation) that will be used for the problem. In one case it was some functions for iterating through search results from a search service. Ideally the API is unintuitive in a few places (as legacy code often is), but I make the documentation unambiguous. Ideally it's inspired by something I actually did at work. 2.) I provide some problematic code that tries to use the API. It has correctness issues, style issues, and performance issues. I ask the candidate to point out any problems they find and fix them as they see them. We keep going until all of the issues are solved, and we have a short discussion of the new code at the end. 3.) If that goes well, I provide a small extension to the API and ask the candidate to write some new code against the API that solves a particular task. Ideally it uses the code from the previous part as a helper function. The format is nice in that it simulates a lot of the nitty-gritty things you do in software engineering (code review, bug fixes, refactoring, dealing with legacy code, reading documentation), and it's always specific enough that they definitely haven't seen it before. It's also standardized enough that it's easier to compare across candidates without bias. One downside is you need to prepare it for each language in advance (assuming you're willing to allow multiple languages).