In observing an interview practice for pair programming for job interviews, I saw and enjoyed a really wonderful process between two of my respected colleagues. They discussed, argued and bargained from the start, and they soon made compromises and began to work. During the coding stage they discussed and overcame every unintended problem they met; they tested and verified their correctness just in time. Both of them were truly involved in and contributed to their pair programming effort. They were so excited and passionate that they even scrambled for the keyboard and mouse to type something. I’m sure both of them were satisfied with each other and this of course would be a very successful job interview.
However, to my surprise, when I asked them following usual questions:
(To the interviewee) What do you think you did well in this process?
(To the interviewer) Do you propose to hire him? Why?
(To the interviewee) Are you willing to be join our company?
Both of them expressed concerns about the other. How can this be? I am sure the colleague who played the role of interviewee is so competent that he should be the candidate we never want to miss. The colleague who played the role of interviewer is an easy-going person and he demonstrated his excellent technical and soft skills during the process. I was very confused so I tried to asking them the following questions:
(To both of them): What did you do just now? What did you observe your pair do? What did you archive?
(To both of them): What merits or weakness did you find from you pair? What did you think you had done well and what did you think you could improve?
After they answered these questions and explained their different perspectives on the whole process, suddenly both of them came out magically: “My partner did really well and he helped me so much! Now I have no concern at all”. This is the magic of a retrospective which can turn defeat into victory.
As far as I am concerned the agile way is an approach which changes an open loop process to a close loop process. The most important thing introduced to the process is the feedback and correction (inspecting and adapting), the feedback includes test, metrics, code review, retrospectives, etc.
Take testing as an example, we have different kinds of tests at different level: unit test, integrating test, functional test, acceptance test and so on. But when we take retrospectives into consideration we only have retrospectives after every iteration, release, and project. Apparently we are lacking some more fine-grained retrospectives in our daily work.
In my opinion, doing retrospective after every pair programming, no matter formally or casually, will be an excellent opportunity to fill this gap.
