Taking time to think applies not just to the recruitment test but to the daily work of a software developer. – Rufus Raghunath, ThoughtWorks
Promising software developer applicants for ThoughtWorks typically take part in a live pairing exercise (often virtually, working with a ThoughtWorker to solve a problem together) before having an interview. TARGETjobs spoke to software developer Rufus Raghunath, who joined ThoughtWorks as a graduate, to get his advice on preparing well for the technical aspects of the graduate selection process.
By this stage candidates will usually have already had an initial chat with a recruiter. Rufus explains how the technical assessment that happens after this works.
This part involves a pair programming exercise with one or two senior developers to solve a problem together,’ Rufus says. ‘This gives our senior people the chance to interact with the candidate, to see what you are like in person and in a pairing context. It also works the other way: the candidate can see what it’s like to work for ThoughtWorks because we pair program 100% of the time.’
How to prepare for ThoughtWorks' pair programming exercise
Pair programming, or ‘pairing’, is when two programmers work together at the same work station to write a piece of code.
Not every software business with a graduate scheme uses a pair programming assessment – it depends what the business deems most relevant to how its developers work. It makes sense that this is a key component of ThoughtWorks’ selection process because its developers pair program all the time.
Top tip: be keen
To prepare for the pairing exercise Rufus advises: ‘Find out more about what pair programming is and why it’s useful.’
Pair programming, like all methods of writing code, is seen as having advantages and disadvantages. Research what these are, as they may provide you with good topics for conversation with the developers and interviewers. However, remember that ThoughtWorks pair programs because it considers it to be the best method for what its developers do, so make sure you don’t sound heavily critical or over confident when discussing the pros and cons – remember that they are the experts.
This leads nicely into Rufus’ next piece of advice that you should being open to learning. ‘During the exercise, be interested, ask questions and genuinely try to learn something from the experience,’ says Rufus. ‘We look for people who are engaged and interested in producing good code cooperatively. Your exchange in the conversation is important.’
The upshot is this: get ready to ask questions, and engage eagerly in conversation about pairing, the code itself and about the jobs of the ThoughtWorks developers you are pairing with. If you are naturally more reserved, don’t assume that your enthusiasm for the task and for the job is obvious. Do make real efforts to talk and show that you are finding the task and the people interesting and learning something.
Showing enthusiasm and always being open to learning is crucial because it is an indication of how well you will work in a pair- and team-centric environment. More generally, all graduate recruiters use a candidate’s enthusiasm to gauge how likely they are to accept the job if they are made an offer – they won't bother if they suspect you are going to decline it.
Top tip: take your time
‘The most important thing is that you spend a bunch of time just thinking,’ says Rufus. ‘Don’t jump straight in and try to implement the solution.’
This isn’t just about accuracy, it’s about making sure that you have a strategy to talk about later. The assignment may also be written in 'plain English' (as opposed to using industry-specific terms), so make sure that you are clear on what exactly the brief for the assignment is (mimicking how you would work with a client in a work scenario). It’s likely that you will need to talk about your chosen approach to the exercise in future interviews.
‘They are not horribly difficult questions designed to trick you,’ says Rufus. ‘The point of them is that they are simple enough that you can create a working solution, but complex enough that there are many potential ways to get to it. The most interesting thing for the people evaluating the test is to see what you have focused on in creating your solution.’
Another reason not to rush in is that it’s a quality that ThoughtWorks recruiters look for in the developers they hire. Rufus explains: ‘Taking time to think applies not just to the recruitment test but to the daily work of a software developer. We have all kinds of feedback loops in place to ensure that the code we create is of a certain standard. Feedback loops can be something as simple as test-driven development, meaning that once your tests pass you know that your code works. But in order to write your tests, you first need to have thought about what the condition is that the tests need to pass and what you want to achieve.’
This isn’t to say that you need to spend ages agonising about which solution is best. You need to choose one that fulfils the criteria you’re given and demonstrates coding best practice along the way. ‘Think about what you are actually being asked to do, how that business problem translates into code and, based on that understanding, what the simplest and most easily extensible solution is,’ says Rufus.
A final thought from Rufus
‘If you come out and decide that ThoughtWorks isn’t for you or you don’t receive an offer, I would view the whole thing as an opportunity that will help you learn something about yourself as a developer or help you improve your technical skills.’