, ,

Screenshot 2014-07-24 08.52.54

This is the fourth article I’ve written on the ThoughtWorks recruitment process (for developers) and today I’m discussing the last developer-specific activity – the technical interview.

The technical interview normally follows a successful pairing interview and the objective is to have a conversation with the candidate about their views on technology beyond coding.  For senior candidates, this means the conversation will revolve around software design and architecture.  For more junior candidates, the conversation may focus on lower-level concepts around development or development process.

Unlike the pairing interview which is typically more structured, a technical interview is going to revolve around what the candidate brings to the table in terms of experience and is likely to be far more unstructured and organic in nature.

When I do these interviews, I’m trying to understand a couple of basic things:

(1) What is the breadth and depth of the candidate’s technical knowledge?

As consultants, most ThoughtWorkers would describe themselves as “generalising specialists” or “T-shaped people”.  The variety in our client engagements means we get exposure to lots of different technologies, techniques and domains.  This exposure gives us considerable breadth across technology, albeit limited to what is common to corporate and SME development.  Beyond that, individual passion results in specific areas leads us to invest substantial personal time to gain a level of mastery beyond what our work gives us.  This depth of skill in one or more specific areas is the vertical bar in the “T-shaped person” description.

So we’re naturally curious how wide and deep a candidate’s knowledge extends.  Ideally, most have a solid grounding of software engineering practices across web and mobile development (client and server), as that covers the vast majority of the work we do.  In Australia, we still do a lot with Java, but also have a good spread of work involving Javascript, Objective C, Ruby, C# and Clojure as well.  Lack of knowledge in a particular implementation language is not a barrier as long as the candidate has demonstrated the ability and desire to learn new languages.

(2) Where are the gaps or boundaries in the candidate’s knowledge?

As important as understanding where a candidate’s knowledge begins is understanding where it ends.  I try and ask at least one question during a technical interview that requires knowledge beyond the candidate.  The intention of this question is to understand how the candidate naturally reacts to this situation, which is one we face regularly with our clients.

Hint #1: The worst possible way you can answer these questions is to bluff!  Sure, you might fool some of the people some of the time, but you will get caught out.  It’s nigh-on-impossible doing consulting without a surplus of trust with your client and one of the easiest ways to eat into this surplus is to attempt to be the all-knowing technical oracle.

Hint #2: The best possible way to answer these questions is a simple “I’m really not sure”, or “I don’t know”.  If you feel like you might have some related knowledge that could be a useful proxy, by all means offer it, but be transparent in doing so.

Because of their variety, I have a lot more specific hints around technical interviews which I’ll cover in another post.