When I interview people, I keep the coding simple. Something like 'write a program to output a 10x10 multiplication table', show me the syntax mistakes in this (awfully written) code', 'Explain what this (obvious design pattern) code does and what's good and bad about it' etc. The aim is twofold: filter out people who can't write or understand basic code (we do actually get some), and provide a talking point for finding out how they think and approach problems. I tend to avoid very specific and/or difficult coding challenges as it can over-emphasise prior experience of that particular problem and we might end up going for the one person who happens to have had a similar question in a previous interview, but who's not a good learner. Being able to talk widely around a simple scenario is a pretty good indicator of experience, curiosity and communication skills.
I'd be looking for things like the following to emerge from the discussion:
- Awareness of more than one way to solve the problem e.g. for, foreach, while.
- Understanding of other issues that would impact on the solution e.g.
- is this a HTML multiplication table, or are we sending results via AJAX as JSON or XML?
- Maybe we need to separate presentation from business logic.
- What if we want to vary the size of the table in future?
- How can this code be unit tested? Why would we want to?
- What steps can be taken to make it robust in the face of inevitable future changes in requirements?
- Knowing why design patterns are used, being able to explain what good OOP principles are encoded in them e.g. separation of concerns, loose coupling, polymorphism, etc. What happens if these principles are not stuck to.
Ideally, these issues will emerge quickly in discussions, with the candidate pointing them out. If not, I'll prompt them and see where things go, so I'd say to expect questions that are open ended, or at least designed to allow you to elaborate and show your skills. Try to keep on-topic in your answers, but show a broader knowledge than just the average person.
Having said all that, we have a lot of diverse projects, so we want flexible generalists. Maybe if the jobs you are going for are very specific to using a particular system or domain, you will find more specific code-based problems.