Why does Thoughtworks assess candidates' pair programming skills?
At Thoughtworks, we strongly believe in pairing not just for programming, but also for most of our everyday activities. In fact, this very post is a result of pairing! Pairing naturally promotes communication, thought alignment, and knowledge sharing while seamlessly replacing any sense of competition with a sense of collaboration. For our clients that translates into higher quality software, a reduction of knowledge silos, and better communication.
As counterintuitive as it may sound, pair programming is only 15% slower than having two developers working separately (see #1.) 15% is also the average percentage of bug reduction of pairing when compared to having those two developers working separately. This really pays off when we take into account that pair programming prevents bugs in the early stage of the software development life cycle and bug fixing costs escalate exponentially the later they are detected (see #2.)
Am I expected to have prior pair programming experience?
No. Ultimately, what we’re assessing are your teamwork and hands-on technical capabilities.
What does the pair programming interview look like?
The pair programming interview is split into two sessions. In the first one, you’ll be given a problem statement and some minutes to read through it. The first interviewer will then join and you’ll discuss the approach you’re going to take and the design you’re going to use, as well as any other aspects you think may be important. The discussion should naturally result in some code and eventually the first session will be over.
For the second session, the first interviewer will leave the room and another one will join you. You’re expected to talk him/her through the problem, the approach you and the previous interviewer have decided to take, the whys, some decisions’ trade-offs, etc. Onboarding the new interviewer to the current problem solution context is much more important than showing and presenting him/her code. Eventually you will get back to coding, and the second session will soon be over as well.
We don’t expect you to deliver a complete solution to the proposed problem, so don’t worry about that.
What are the main aspects assessed in the pair programming interview?
Communication
This is probably the most important aspect we’re going to assess in this interview. Communicate at all times. Hesitating between two approaches? Introduce them to your interviewer: What are each one's pros and cons, implications, trade-offs? Stumbled upon something you do not know? Let your interviewer know what you already know, how you would pursue a solution for that question, where you would start from, what path you would take. Struggling with a problem? Vocalise your concerns, discuss possible approaches, their pros and cons, the trade-offs.
Train of thought
We expect you to be able to structure your thoughts and define a strategy for tackling the proposed problem, as well as the problems that will come up from it, in an organised way, so your interviewer is able to not just follow you, but also collaborate with you. Getting your interlocutor lost is expected as well, but so is being able to take a step back and getting him/her back on track.
Teamwork
This interview is shaped to look a lot like an ordinary workday at Thoughtworks. Your interviewer will act most of the time more like a coworker than like an interviewer. You both are expected to push back on things you do not agree with, to discuss your ideas and to adapt to new facts and propositions you are introduced to, according to what you feel right or wrong.
Design
Drafting a design for your solution is an important step to take before writing any code. It will allow you to better understand the problem, to anticipate coding structure and integration problems and to choose the point to start coding from in an educated way. Take your time to think, discuss and evolve it as you go.
Coding skills
We expect you to be familiar with the language you choose for the pair programming interview as well as with the IDE you choose to use. We will not be specifically assessing your skills on that language, but a lack of familiarity with it or the IDE you choose may impact our ability to assess your programming skills.
Automated testing is a very important part of what we do and we expect some familiarity with that subject from you. Because of the nature of the proposed problems statements and the time constraints, we only address unit testing in this interview. Knowing TDD and how to apply it in practical terms will definitely help you.
Mind your code readability, maintainability, and extensibility.
1. Alistair Cockburn and Laurie Williams, “The Costs and Benefits of Pair Programming”
At Thoughtworks, we strongly believe in pairing not just for programming, but also for most of our everyday activities. In fact, this very post is a result of pairing! Pairing naturally promotes communication, thought alignment, and knowledge sharing while seamlessly replacing any sense of competition with a sense of collaboration. For our clients that translates into higher quality software, a reduction of knowledge silos, and better communication.
As counterintuitive as it may sound, pair programming is only 15% slower than having two developers working separately (see #1.) 15% is also the average percentage of bug reduction of pairing when compared to having those two developers working separately. This really pays off when we take into account that pair programming prevents bugs in the early stage of the software development life cycle and bug fixing costs escalate exponentially the later they are detected (see #2.)
Am I expected to have prior pair programming experience?
No. Ultimately, what we’re assessing are your teamwork and hands-on technical capabilities.
What does the pair programming interview look like?
The pair programming interview is split into two sessions. In the first one, you’ll be given a problem statement and some minutes to read through it. The first interviewer will then join and you’ll discuss the approach you’re going to take and the design you’re going to use, as well as any other aspects you think may be important. The discussion should naturally result in some code and eventually the first session will be over.
For the second session, the first interviewer will leave the room and another one will join you. You’re expected to talk him/her through the problem, the approach you and the previous interviewer have decided to take, the whys, some decisions’ trade-offs, etc. Onboarding the new interviewer to the current problem solution context is much more important than showing and presenting him/her code. Eventually you will get back to coding, and the second session will soon be over as well.
We don’t expect you to deliver a complete solution to the proposed problem, so don’t worry about that.
What are the main aspects assessed in the pair programming interview?
Communication
This is probably the most important aspect we’re going to assess in this interview. Communicate at all times. Hesitating between two approaches? Introduce them to your interviewer: What are each one's pros and cons, implications, trade-offs? Stumbled upon something you do not know? Let your interviewer know what you already know, how you would pursue a solution for that question, where you would start from, what path you would take. Struggling with a problem? Vocalise your concerns, discuss possible approaches, their pros and cons, the trade-offs.
Train of thought
We expect you to be able to structure your thoughts and define a strategy for tackling the proposed problem, as well as the problems that will come up from it, in an organised way, so your interviewer is able to not just follow you, but also collaborate with you. Getting your interlocutor lost is expected as well, but so is being able to take a step back and getting him/her back on track.
Teamwork
This interview is shaped to look a lot like an ordinary workday at Thoughtworks. Your interviewer will act most of the time more like a coworker than like an interviewer. You both are expected to push back on things you do not agree with, to discuss your ideas and to adapt to new facts and propositions you are introduced to, according to what you feel right or wrong.
Design
Drafting a design for your solution is an important step to take before writing any code. It will allow you to better understand the problem, to anticipate coding structure and integration problems and to choose the point to start coding from in an educated way. Take your time to think, discuss and evolve it as you go.
Coding skills
We expect you to be familiar with the language you choose for the pair programming interview as well as with the IDE you choose to use. We will not be specifically assessing your skills on that language, but a lack of familiarity with it or the IDE you choose may impact our ability to assess your programming skills.
Automated testing is a very important part of what we do and we expect some familiarity with that subject from you. Because of the nature of the proposed problems statements and the time constraints, we only address unit testing in this interview. Knowing TDD and how to apply it in practical terms will definitely help you.
Mind your code readability, maintainability, and extensibility.
1. Alistair Cockburn and Laurie Williams, “The Costs and Benefits of Pair Programming”
2. Jonette M. Stecklein et al., “Error Cost Escalation Through the Project Life Cycle”
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
