I primarily do contract software development so interviews are pretty common for me.
I’ve seen a huge variety of ways people perform technical testing, ranging from multi-choice questions (terrible) to simple chats on what you’ve done.
Over the last few months I’ve had the opportunity to be on the other side of the fence and actually interview developers. This was really exciting because I could put into practice some of the things I thought would make for a good technical test.
By far my favourite tests have been project style ones. You give a candidate a short project spec and let them go to town and use what they needed to get it done.
We sent the test out to anyone that applied. This acts as a good candidate filter.
From these types of tests, you can infer a variety of things about developer which provides an insight into how they could perform in a real world scenario.
I found the following information:
- Ability to use computers.
eg: not being able to send a copy of the test to us in some way is a fail. Yes this has happened more than once.
- Ability to read the instructions.
- Do they use the design pattern (State Pattern) I asked them to implement. <- !!! Very few people actually did this
- How they comment the code. If at all
- Ability to find stuff. ie, use google. This is hugely important.
If they don’t what the pattern I asked them to implement is, did they look it up?
Can they find a third party library to perform certain tasks?
- Did they implement the entire thing?
At the bottom of the instructions it says you only need to implement 2 of the 5 states.
This is the Van Halen brown m&m’s test.
Yes you could consider this almost like a trick question. I don’t mind if they implement the whole thing but I do look for some comments mentioning they recognized this request.
- Does the code work?
- The WTF level of the code.
- Can they pull the code from bitbucket? It’s not a fail if they ask for instructions but it is really simple to figure out. This provides insight into their ability to figure things out.
- Do they write good comments? Comments should be concise and describe what is trying to be done as opposed to stating each step of the code (that’s what code is for!!)
- Can they write code? I look out for things like deep copying of objects
- Is their code pretty? Good developers write beautiful code. If they have, they probably have read at least 1 of two books that I consider kind of mandatory: Code Complete or maybe Beautiful Code
- Project structure. Has the solution been laid out nicely?
- What excuses they make in the email they send to us.
- Do they ask us questions to help clarify the project. This is a good thing and it shows that communication and understanding is important and also that they aren’t afraid of asking questions.
- Cleverness. Can they find the example code that is hidden somewhere in plain sight?