They work within problem domains they know about and use libraries, frameworks and other useful abstractions. They edit existing code, they architect apps, they think about stuff for a long time, working things over in their mind or in code. Being a fast coder is more about memorization and making every problem a nail for tools like memoization and big O analysis, then about long term sustained development skills. Real skills are not solving the problem in front of you asap. It's solving that problem and five other potential future problems using the same abstraction. It's not knowing the fastest solution, it's knowing several solutions and applying the best one.
Real code tests would be like what engineers do everyday.: Here's some code we want to push to production, or plan to refactor for speed, write unit tests on the computer so we know it won't break.
Here's a design problem, how would you set up a db schema or object oriented design? Okay, now we need to add this feature, how would your design change?
Here's a problem involving calculating something based on a db call and returning it over the network... what's the solution you use if network latency is an issue? What about disk io in the db? What about if it's cpu bound? What about it uses too much ram? What about if at some point this may need to be asynchronous code? What if it's distributed code? What if you need to catch every edge case? What if things are breaking in production and you need to solve 80% of the problem now and worry about edge cases later?
Okay... here's an api, write code to use it to solve the problem, even though the api isn't meant to be used this way.
Here's super complicated code... figure out what it does and document it.
These are all things a software developer may do... I guess I'm advocating testing their ability to work by using stuff as close to work as you can.