It's easy to come up with questions they can't prepare for - example, for a C++/SQL database job:
1) Present them with your database schema, give them time to read and (at least partially) understand it. Allow questions. Give them a workstation.
2) Get them to write a SELECT statement to pull stuff out of two or three tables.
3) Get them to integrate the query into a small C++ program. Have the program write data out to a text file.
You can do this fairly realistic stuff for any technologies. Or, for C++, you could use my favourite interview question: "Tell me about the copy constructor".
I'd really rather not tell you our database schema.
Instead of expecting businesses to tell you domain specific things and then answer questions about them, please just understand some basic principles behind a large class of algorithms.
Almost all algorithm questions boil down to a simple principle, can you take a problem and break it down into its simplest form; the simplest linked list to reverse is the empty linked list or a linked list with 1 node.
Can you then build upon the simplest case to solve the next simplest case; reverse a multi-node linked list by reversing the tail and then appending the head to the result.
It really is unfortunate how many people, instead of trying to understand concepts, want to just memorize a bunch of hardcoded facts or trivia about programming languages or libraries. If you understand the basic principles, you can easily pick up minutia about C++ copy constructors or move constructors... but someone who has memorized a great deal of minutiae about C++ may never be able to understand some of the basic principles that broadly cover a multitude of data structures and algorithms.
> you can easily pick up minutia about C++ copy constructors
Hollow laughter. And if it were true (which it isn't) how well can you explain those "minutia"?
That means you tell someone who you might not hire what your database schema is. Probably not something you want them to know. You also assume they know SQL - many C++ jobs only need minimal SQL knowledge and so you are fine with hiring someone who can write a select only with the help of google - but someone at that level wouldn't be able to solve your problem. I've spent a lot of time working in a language that was custom to the one company I worked for at the time - I can learn your language quickly (even C++ is not that hard - the dark corners means it takes years to become great but to be productive doesn't take very long), as such I don't want to force any particular language on the interview, I want something that proves they can write code.
> Probably not something you want them to know
Why not? But if your schema is so secret, come up with a simple one for use in interviews.
> You also assume they know SQL
I specifically said this was for a c++/sql job.
> so you are fine with hiring someone who can write a select only with the help of google
No, I'm not fine with that, even if it were do-able.
> I can learn your language quickly (even C++ is not that hard - the dark corners means it takes years to become great but to be productive doesn't take very long)
Wrongo. And not just for C++.
> I don't want to force any particular language on the interview, I want something that proves they can write code.
Obviously, we want very different things.