When a developer starts applying for jobs again one of the first things he or she will do is google for “Java Interview Questions”. The internet is packed with fodder for them; top 150 java questions, 30 questions on Threading, the most amazing questions on design patterns. When a company starts hiring again they do the exact same search, standardise on a set of questions for candidates and hiring begins. The battle of who can remember the answer to niche java questions begins, and those with the best memory are rewarded.
There may be some slight exaggeration here, but from experience and anecdotal evidence it is surprisingly commonplace. Fundamentally by taking this approach to hiring you are only testing that people have (a) done their reading before coming to the interview, and (b) they have a good memory. Whilst both of these are good facets, they are not the exemplary features that we should be looking for from top tier candidates.
Which brings forth the questions: What does a good programmer look like and what interview can we put together that helps us identify them?
What does a good programmer look like?
There is no simple answer to the question and fundamentally it is a very bias question. What a good developer looks like to me will very likely differ to what it looks like to you. I am a big fan of Test Driven Development and that will influence my view on someone, but there’s inevitably a ton of developers who are actually really good that don’t do TDD who I will rule out. You on the other hand may absolutely love Spring developers, or people who have experience in multiple languages, or people who have project outside of work. You’re naturally going to have your own criteria, and it’s important that you write these down up front so you can figure out how to find it.
If you boil these opinions down they generally fall into two categories; code and design. So when you bring your fresh faced candidate in to interview him, you need to ask the important questions: can they code, and can they design?
Can they code?
One overriding theme that has consistently baffled me is that through all of the interviews I have personally been to, almost none of them have sat candidates in front of a computer and watched them code. This is the equivalent of hiring a driver and not checking for a driving license or hiring an artist without seeing if you like the way they paint. This really wouldn’t happen in any other industry and is unique to the profession we practice.
Fortunately you’re smart and you know you need to see people code, and there are a number of options to choose from as part of the coding interview. Code homework is becoming more popular, where a programming challenge is given to the candidate to complete at their leisure. There are many benefits to this- if the exercise is being performed at home without the high pressure setting of an interview then your candidate has no excuses for producing bad code. What they produce has to be the very best code they are capable of. However the programming homework is not without it’s detractors; depending on which stage of the process your candidate is at can have a hugely detrimental effect on your ability to hire. Most firms put it as the very first stage. It’s great for filtering out terrible candidates but there are a lot of programmers (particularly senior devs who may be more prone to ego) who will flat out refuse to spend hours writing a program without even being given a phone interview first. You must weigh this in when designing your interview process.
The other option is to bring your candidate in for a face to face programming interview. There are two main options to throw at your potential new hire. The first is to give him or her an exercise or set of exercises and sit them in an isolated room with an IDE for an hour or two and reviewing the answers after they have left the building. In many ways this has the same benefits as the homework assignment and will allow you to review their coding style and give you an insight into how they broke the answer down. There is a better option though: the pair programming interview.
By sitting a potential hire down with one of your existing staff and walking through an exercise you will be able to get unique insights into the way the candidate works. Do they use keyboard shortcuts? How do they work with a colleague on a problem? How do they react when challenged? This is a priceless opportunity. Figuring out problems like this, with support from colleagues, is what a developer spends most of their day doing and using this interview you get the opportunity to witness it first hand. It also allows the conversation to be two way; they can get an understanding of how your team works and whether they will fit into it. The hiring process is not just about a candidate's suitability to the role, but also about whether they want to actually come and work for you.
Once you’ve witnessed their programming first hand you can decide if they are a good fit; the question of “what good coding” looks like will be very specific to your team and this interview will allow you to accurately judge if the candidate fits your criteria. If you haven’t seen them code then you’ll never know if they will fit.
Can they design?
Programming is not simply a matter of typing commands into an IDE and running it. If that was the case there would be immense demand for people who can type over 100 words per minute. The bulk of programming is solutions design- the ability to take a problem space and break it down into understandable sections, in relation to the larger system. In reality this never takes place in isolation but is discussed as a group, team or pair. Fortunately, this is really easy to test.
I like to call it the “tell me about your system” test. Every candidate is working on one or more systems in their current job. They’re spending well over 8 hours a day, 5 days a week working on a massive code base with team members. They (should) know this system inside and out. The question is whether they can explain it.
There are two type of programmer. The first is happy to come to work, use a given set of technologies and tools and just put their head down and code. These are the worker bees, they are reliable and will likely produce average code at an average pace at best.
You don’t want this candidate.
You want the java programmer that comes in with ideas. The developer who questions why technology choices are made, and suggests new ones. When faced with slow tests or a poorly architected system this candidate will tackle it head first and fix the problem as opposed to exacerbating the problem. If you can get a team of these people you will deliver great systems which are well designed, and do so considerably faster.
Ask your candidates to draw the system they are working on. In interviewing over 50 candidates I’ve never had one say they are unable to do this due to an NDA or concerns to their current employer. Challenge the design of every new component or communications layer or failover mechanism. Why choose JMS? Why java? Why run the components hot-cold? They may not have created the design originally as in reality most projects are brownfield but it is important that they understand why the decision was made originally and, if they disagree with it, they have they’re own view as to how to fix it. Take these two answers to the question “why did you use JBoss messaging?”
Answer 1: “It’s a mandated technology in my company so I guess that’s why we used it. It’s ok I guess”.
Answer 2: “It’s a terrible technology but it’s something we’re stuck with. It’s impossible to test and it falls over all the time. I’d much rather use ActiveMQ as you can start it up in memory for unit tests and it’s got great failover options”.
This sounds like a polarised example but this is a genuine representation of the different types of answer I get with this question. Passionate candidates with opinions on technology are rare; find them and hire them. You shouldn’t just look for candidates whose opinions match your own either. A team of people who think completely the same is going to result in a system with a skewed design, that is extremely brittle and is unable to shift as technology changes. Hire people that will challenge you. This way you will end up with a diverse team that is aware of all of the options and produces the best solution based on technical merit and not unproductive bias.
Hopefully you can see the benefit of avoiding remember-by-rote interview questions. That’s not to say they should be completely shunned; some basics on collections, exceptions and other core topics can act as a simple filter on candidates before dedicating the time to bring them in to meet face to face. Interviews need to be balanced, but remember what the ultimate goal is. There will always be IDEs with code completion and google is going nowhere; if someone can’t remember a method or technique it’s not the end of the world if they understand the fundamentals, know how to program clean code and truely understand how to design a system.