Point 11 of the Joel Test asks: “Do new candidates write code during their interview?”
But how do you do that? I find most tips on the internet aren’t really helpful or realistic.

Trivia questions about programming might be ok to filter out some candidates. But those at HR usually can’t know if the answer is correct. And just knowing the answers doesn’t really prove anything. So let them write code. But what kind of code? These are some of my opinions.

I am fully aware that this is just yet another online rant by someone who isn’t even qualified to talk about this. This is in no way a guide on how to find good programmers. It’s just my humble opinion.

Nobody actually uses Fibonacci numbers!

So why let candidates write algorithms to find F₁₀₀ or solve any other unrealistic task? Do something realistic and also explain what it is supposed to be used for. You could give some code that will use the components to be built, or provide unit tests that simply need to be green, or let them implement some given interface. Just let them do something that is like the actual work you do in your company.  Unless your company actually specializes on Fibonacci numbers, of course.

Specifications must be realistic

Specs are never perfect. But those for the interview programming test must be good enough so that the candidate can at least write some code to show her or his skills. I’ve seen tasks in blogs that are not nearly clear enough to be solvable. Remember that in real projects you often have to ask the client to clarify some details. But you probably want to hire some junior programmer, not en expert for requirements engineering. So for the test everything must be absolutely clear.

Recursion is Fun but not very realistic

Unless you need a Haskell programmer you probably do not want to test recursion. Java isn’t a functional language so don’t test concepts of functional programming. However, you could provide a recursive function and let them replace it with a non-recursive version. Just tell them there’s a problem where you sometimes get a StackOverflowException even though the results are always correct when the methods terminates. Anyone who can do that is probably a good programmer.

Time Limits aren’t very realistic

They already have tests with time limits at university. So just check out their grades. But if you want to test how they work under realistic conditions then make the test realistic.

How often does a client demand that something is programmed in one hour? It simply takes as long as it takes until it’s written, documented, tested and delivered. So do not pressure the candidate to do something in one hour that would take days to really finish.

Programming isn’t Everything

Is it really enough if the candidate can write algorithms in a short time? What about writing tests? What about using your versioning system? What about database design? What about documentation? Frameworks? Security? Continuous Integration? Dependency Management? Make sure you actually test what is needed to be a productive member of your team.

Test what you wouldn’t want to teach them

So programming isn’t everything, but you could easily show them how to use Maven if they have never used it. Test what you wouldn’t want to teach them.

What I would do

I’m not in charge of testing candidates. But here’s what I would do. I’d would let them write two single code units (two files with “.java” extension) that could actually be used in some project. I’d provide an interface that already has all specs as javadoc. One code unit is the implementation of that interface. The other is the JUnit test. If they do not know JUnit I’d quickly explain it and give them a template (or show them how to generate it in the given IDE) and show how to run the tests.

The task could be anything needed for a small project. Here are some ideas:

• Create adapter for some given Interface
  • Class A implements B → Make adapter for A that implements C
• Implement some Data Structure that doesn’t already exist in JCF
  • Multi Set / Multi Map
  • Immutable Linked List / Immutable Enum Set
  • Map with weak Values (instead of weak Key as in WeakHashMap)
• Let the candidate rewrite some existing Unit
  • Pure Refactoring of smelly Code
  • Adapt it to different Requirements
  • Extend it so additional Requirements are met
  • Make it thread-safe (mutable or immutable)
• Create Interface for some existing Library
  (note: this can’t be tested with JUnit)
  • as a Command Line Tool
  • as a simple GUI Tool (e.g. JavaFX)
  • as a Web Service (SOAP, REST)
• Add a cache to an existing algorithm.

How I would rate the Code

This is in no way complete, just some ideas. Make sure all candidates are judged by the same standards.

• How good is the Javadoc?
• Correctness
  • Does it meet the Requirements?
  • Is it complete?
• How much do the Tests cover?
  • Null Pointers?
  • Fail-Fast?
  • Out Of Bounds?
• Coding Style
  • Proper Naming?
  • Use of Generics?
  • Common Code Smells?
• Performance
  • Time Complexity?
  • Memory Complexity?
• Code Manageability
  • Unnecessary Code?
  • Helpful Comments?
  • Overall Class Design?