Yes most of the questions are HR
The code that I ask them to bring in and to have them explain it to our developers and I get to ask them about how the solved challenges and illustrate their code solutions; my developers will ask them demonstrate code prowess.
Generally I avoid and ask my developers to be careful to not too much 'put the developer on the spot' as not all good even great developers are comfortable not in their IDE setup, programming resources etc., so I get the developers to discuss thing like preferred or experience in different layer abstraction like MVC, SLA, ... experience working with other developers and how the potential hire describes things the do well in teams and things that have potentially frustrated them in previous team environments.
We may ask them to:
- demonstrate CRC cards
- read UML models
- describe the best 'pattern(s)' fit for a number of common code situations
- understanding of Unit Testing and testing frameworks
- talk about their working knowledge in frameworks and/or libraries
- describe the value of refactoring?
- to sketch a sequence diagram for a number of simple classes
- use of GIT from the command line: add, status, diff, commit, reset, rv, mv, push and remote
- describe the practices of BDD (Behaviour Drive Development)
I have a fairly in-depth discussion with my developers to ensure that the hire is a good fit, what type of 'feeling' did they get, did they spot any 'Warning Signs'.
Based on these processes we use the three month 'grace' period to ensure that they adapt and act the way they described in their interview. We also suss out team dynamics to ensure that they are good and that this new person isn't throwing a monkey wrench into the mix.
Code is just one of many different things a developer needs to do. Too often that is what most employers focus on, so you are lucky if you get someone like wonshikee. By understanding how a developer has invested in their craft you can understand the value they bring to your team.