Communicate
No one likes a surprise test. Least of all when at an interview. So let him know there'll be a test. Even let him know the topics that will be covered in the test.
For example you might say the test will cover:
- Creating tables in a MySQL database
- Populating those tables
- Writing a Perl script to query the tables.
Enough for a basic test and enough information for him to brush up if needed. But not enough that he can start work on it before he arrive.
Be Fair
In order to be fair you need to recreate the conditions that he would be working under.
So you're going to need:
- A meeting room
- A computer
- Any programming reference books you have
- An internet connection
- Possibly a development environment (maybe set up Apache to be looking in a cgi-bin for the script he will write)
Setup a computer in the meeting room to have internet access and any books that would be available if they were actually doing the job. Nobody knows everything off the top of their head. So don't expect them to on an interview.
This doesn't mean they can cheat, because you'll set a very specific task, which won't be available to download on the internet.
Set A Task
Prepare a brief for the test broken down into a number of tasks. Each task should give enough detail that the he knows what to do without having to ask you. But it's also good to leave a little room for him to add something extra to show of his skills and knowledge. So for example:
- Create table in MySQL for book and author. Where authors can have one or more books.
- Populate the tables with several records.
- Create one or more CGI scripts to display
- All books
- All authors
- All books written by an author
Set a time limit, but let him know that it doesn't matter if he finished or not as he will be able to talk you through what he's done after. An hour is normally a good amount of time.
Analyse The Results
So you've interviewed and tested a hopeful candidate, now how do you tell if he passed the test? Well, if he successfully completed the tasks, he passed. But the real question is how did he pass?
Much can be learned from they way he completed the tasks. In the example above enough room is left him to decide things like:
- What the database schema looks like.
- Which fields were created for book and author.
- What field types were used. Were they indexed, etc.
- How the code is written.
- Is it modular, is it object oriented.
- Is it commented.
- What are the pages like.
- There could be a separate perl script per page or just one.
- Has the UI been given consideration.
- What about the page source, is it valid (X)HTML.
So a lot can be learned from this style of test.
The details can be easily varied to keep it fresh. The complexity can be increased by choosing a model with more relationships. For example you could add a category, with a many-to-many relationship, to the example above. Or you could base it on more abstract concepts simply by giving the tables different names and clarifying the relationships. e.g. You could have said "Create table in MySQL for node and joints. Where a node can have one or more joints." Which just helps to test his grasp of abstract concepts.
