Thoughtworks assesses candidates’ pair programming skills for several reasons.
Our goal at Thoughtworks is to pair our work in every part of our lives, not just in programming. In fact, you are reading this because we paired! In pairing, communication, alignment of thought, and knowledge sharing are naturally promoted, and any sense of competition is seamlessly replaced by a sense of collaboration. That means higher quality software, reduced knowledge silos, and improved communication for our clients.
Although it may seem counterintuitive, pair programming is only 15% slower than having two developers work separately (see #1). 15% is also the average bug reduction of pairing, when compared to having two developers work separately. Taking into account that pair programming prevents bugs in the early stages of the software development life cycle and bug fixing costs increase exponentially as they are detected later (see #2), this pays off in spades.
Do I need prior experience in pair programming?
I don’t. In the end, we’re looking at how well you work in a team and how good you are at learning new things.
How do you conduct a Pair programming interview?
There are two sessions for the pair programming interview. Your first task will consist of reading through a problem statement for a few minutes. You will then discuss with the first interviewer what approach you will take and what design you will use, as well as any other aspects you consider important. As a result of the discussion, some code will be created and eventually the session will be over.
During the second interview, the first interviewer will leave the room and another will join you. He/she will want to hear about the problem, the approach you and the previous interviewer have chosen, why certain decisions have been made, etc.Showing and presenting code isn’t as important as onboarding the interviewer to the current problem solution context. After the second session, you will be back to coding.
Please don’t worry about delivering a complete solution to the proposed problem.
How does the pair programming interview assess the main aspects?
In this interview, we will probably focus on this most important aspect. Stay in constant communication. Not sure which approach to take? Explain them to your interviewer: What are the pros and cons, implications, tradeoffs of each?something you do not know? Explain to your interviewer what you already know, how you would respond to that question, and where you would begin. Having trouble? Talk over your concerns, the pros and cons of possible approaches, and the trade-offs.
Your interviewer should be able to follow you, as well as collaborate with you, if you are capable of organizing your thoughts and defining a strategy for tackling the proposed problem, as well as any issues that will arise. It is also expected to get lost with your interlocutor, but it is also expected for you to take a step back to get them back on track.
A typical day at Thoughtworks is shaped into this interview. Interviewers should act more like coworkers than interviewers most of the time. We both expect you to push back on things we don’t agree with, to discuss your ideas and to adapt to new facts and propositions we introduce, based on what feels right or wrong to us.
Before you write any code, you should design your solution. With this, you will be able to better understand the problem, to anticipate coding structure and integration problems, and to choose where to start in an educated manner. Spend some time thinking about it, discussing it, and working on it as you go.