Creating a genuine Pair Programming Interview Environment

It seems every development role in the world now requires a ‘pair programming’ element within the interview process. However, this pair-programming item bears little relation to the collaborative spirit and tasks that you would experience in a normal development position.

Frequently, you are invited to a URL on Hackerrank, Hackerearth or another permutation of such. You will be asked to screenshare, and you will be asked to solve an algorithm of extremely varied complexity, dependent on the selection skills of the interviewer and the randomness of the algorithm itself within the platform. Typically, the interviewer will have already seen and analysed the question, together with hints and guides on the algorithm question that the interviewer can see, but the candidate cannot.

As such, the interviewer performs the role of the Oracle, where the candidate if he hasn’t studied the question as part of his interview preparation and is unlucky in the question that has come up, will ask increasingly desperate questions as the counter runs down to add to the interview pressure. The interviewer will refer to the ready reckoner provided,  and will give as accurate or as vague a response as they feel appropriate.  Then, if the candidate is fortunate, the test case passes.

This is also not enough. There are perhaps twenty other test cases, hidden from the interviewee but available from the interviewer, where the candidate has to guess / calculate why the test case is failing. They often cannot see the failing test case.

Now, having been both a candidate and an interviewer, I don’t feel this process helps assess a candidates suitability for a role. In a real, collaborative, pair-programming environment, you will be tasked together as a team to solve an unseen problem together. You will all have different skills you bring to the table, and through a system of dialectics you evolve the solution to the best fit using your respective talents. This is one of the wonders of software creation when done right and produces excellent software which is why the methodology is championed. What is not a scenario is where one developer already knows the answer and the other is asked to reinvent the wheel where the result and methodology is already known.  

I think these integrated code test environments are excellent platforms, however I don’t think they are being used to their full potential by the interview process. Instead, I would propose that the interviewer also has the question unseen, and together the interviewer and interviewee collaborate to achieve the solution. I would also advocate that the tests cases are fully presented and known upfront.

Through making these two simple tweaks, this would truly capture the spirit of Pair Programming and lead to a much more robust recruitment process.