I will give my opinion about using this technique to try to recruit someone for a software engineering team that makes product or to be a contractor.
But first, I’m going to remember what this technique is. Basically, putting two people to solve a problem, with one computer. We have two figures, the driver and the navigator. These are the duties that they must fulfil.
-Write the code according to the specification of the navigator.
-Listen carefully to the navigator’s instructions
-Ask questions where there is a lack of clarity
-Offer alternative solutions if you disagree with the browser
-In case of disagreement, leave it to the navigator. If your idea fails, fail quickly and move on.
-Make sure the code is clean
-Possesses the computer/keyboard
-Ignore major problems and focus on the task at hand
-Trust the browser: ultimately, the browser has the last word on what is written
-You are writing the code
-Dictates the code to be written – the ‘what
-Clearly communicates what code to write
-Explain ‘why’ they have chosen the particular solution to this problem.
-Check for syntax / type errors while the driver is driving
-To be the safety net for the driver
-Make sure the driver sticks to the small task at hand
-Sketching and writing down high-level tasks/problems
-Code review in progress
-Wait until the task is completed for design/refactoring problems to arise
-Actively participates in the programming
-Aim for optimum flow – avoid trying to be ‘correct
-Accept your role
-Intervene if your partner is silent
-Know when to give up / steal the keyboard
-Communicate, communicate, COMMUNICATE!
-Synchronize frequently to make sure you are on the same page
-Don’t hog the keyboard
High five every time you pass a test
-Follow the best practices for TDD
-Switching roles frequently
Okay? basically one tells the other to write and if the other doesn’t agree, it’s a matter of reaching a consensus to write the best possible code the first time, without having to do peer review by a third party. So far, more or less in agreement, with my hitches.
This can work if, in order to do a test, the examiner acts as a driver and lets the surfer write what he thinks is appropriate, but if the driver already tells you at first that, to give an example, you can’t use objects, you can only use primitives, or whatever, you are first disrespecting the person because you are imposing your will in an absurd way, you are not reaching an agreement, you are taking advantage of your position to impose your will. It is unscientific in the end. If you do that, the navigator feels that he has to guess the code you have to write, completely nullifying the trust and the accumulated experience. There came a time when the interviewer driver wrote the code in the test without me saying anything, stunned as he was by the bad intention and desire to be above the interviewer. In the end, the interviewer made in two hours, an implementation of a Set class limited to 10 objects that used an Array to keep the information. And I could not even express my opinion about the loss of time and the quality of the code that came out.
Something that if you want to make a little more special, like you want to keep objects in a set in order of appearance or in natural order, or if you want a structure based on multhreading to take advantage of parallelism or another kind of set as special as you can think of, the possibilities are given by the imagination, in the end you only need that class to have as a private attribute one structure or another, like a hashmap, a treemap, concurrenthashmap, etc…
Anyway, it is obvious that the purpose of the test was not to produce a brilliant implementation of a set, but to measure if I am able to work in a team doing pairing. It is obvious that if the driver imposes his will and doesn’t let the navigator to give his opinion, then you are left with the only one who contributes is the driver and the navigator feels that he hasn’t done anything, he hasn’t been able to contribute anything and his opinion and experience is misused. I did not like it. Firstly for reasons of efficiency, for the quality of the code, secondly because it was stressful, I felt like going back to the first year of university when you knew absolutely nothing, because you were trying to guess the professor’s thinking, until you finally understood where you wanted to go. And finally, it’s not fair to try to test the ability of the engineer you want to sign. You want to be above the applicant, you don’t want to prove anything. You want to be able to tell the company that hires you that you are indispensable, you want to take away competition. It’s absurd. I want to help, I want to participate, nothing more.
Much more interesting to do pairing and tdd, is a situation where one writes the test, the other writes the production class, and then changes the papers. They exchange ideas about the implementation of each other, refactor what needs to be refactored, learn from each other and move quickly to another use case. With speed and agility, producing quality code because we give a very quick peer review, without the need to be dogmatic about that one can only have the keyboard and only my opinion is correct.
The purpose of pairing is to produce quality code that goes through peer review, so that several people feel ownership of the code and feel more responsible for the code produced, it will not be that one of the two decides to go somewhere else because he suddenly receives a mega economic offer impossible to refuse. These things happen, I know, I’ve seen it. It’s also about justifying to the employer that two engineers who earn, to say the least, 100k a year can produce a code that would make a person who earns more than 200k. In this way, the employer is wasting money, guaranteed.
It makes sense to do pairing like I did in the test when you put a junior programmer together with a senior one. The junior will learn from the senior. When you put two experienced programmers together, one of them will get bored and stressed. He will feel that he is wasting his time. This is guaranteed. If you put two experienced programmers together and you don’t take into account at all what the other one thinks, in the end you will disconnect, and you will lose the sense of belonging between two and the peer review.
Anyway, it has been a bad experience, I hope I don’t find myself in a situation like this again, because I really wanted to contribute to this project and because of the dogmatic and gridded thinking of following a set of rules in which the interviewer goes overboard, I feel I have missed a great opportunity to move forward and keep learning.
Dogmatic thinking is unscientific, totally contrary to freedom of thought and unproductive. Following the rules dogmatically prevents you from questioning their motivation.
In the end, I did an implementation to prepare the test, in which I learned what the real implementation of a set in the JDK is like, what to do to extend the mathematical behaviour of a set, and in the end I am left with the feeling that thanks to this test, I was able to dive into the entrails and understand the motivations of the JDK engineers. I didn’t have to reinvent the wheel, but I acquired the necessary know-how in case I had to create a wheel made of adamantium.