The goal of simple on-paper coding tests is to evaluate whether a candidate's programming experience meets a certain threshold. The difficulty of that test will depend on the level of the position and how technical it is. Unless otherwise specified, it's assumed that you'll write out your solution in pseudocode.
You could categorize these tests as follows:
- Basic competence: a Fizz buzz test involves simple looping and tracking of variable state. Any student should be able to ace this a few weeks into a a programming course (but a surprising number of developers can't).
- Practical working experience: slightly more advanced tests that you'd expect a graduate to have no trouble with. Examples are simple CRUD or IO logic or rough sketches of board game implementations.
- Theoretical experience or insight: writing a linked-list or sorting algorithm implementation and similar high-level programming and data constructs. These are still popular to evaluate entry-level candidates straight out of college. Their merit has always been a subject of debate.
- Technology-specific: any test that is designed to identify basic competency with a particular technology (Perl, C++) or framework (MVC, OOP design principles). In practice these kinds of tests shouldn't be done on paper as they can be difficult to work out in basic pseudocode. Ideally this kind of knowledge would instead be checked by having the candidate create a simple demo application with access to a real IDE and reference material.
In all cases, the goal is not to produce workable code, even if you were to translate it to an actual language and correct the syntax. It's to demonstrate that you meet the baseline experience and skill requirements for the position the company is hoping to fill. In general, it's more important that you explain what you're doing as you're writing down your implementation. Usually the hiring manager is also looking at your communication and reasoning skills in these kinds of tests.
Managers that hire graduates for instance expect that they'll require significant adjustment time and training before they can work independently as their programming knowledge is mainly academic but they do not want to hire candidates who interview well but have no actual programming experience. If a manager is instead hiring a mid-level full-stack developer he wants to be sure that the candidate has experience with the languages or frameworks that he'll be using daily.
Note to hiring managers: don't subject experienced developers to these kinds of tests. Their track record should speak to their experience and skill and really good developers will usually balk at being subjected to these kinds of tests.