That's a good approach if only because it shows how and how fast someone can build up a mental model of what a piece of code really does.
The problem is that the 'existing code' may well be of poor quality and that in order to understand it you first have to get into what it was supposed to be doing in the first place, and this isn't always obvious. So the writer had better take good care to make the code self explanatory or provide additional documentation to give sufficient context. In a way the underlying assumption is that the code is 'good'.
And that's where the real problem lies: lots of code isn't all that good and plenty of it is probably best described as 'single use', in other words: write only. Trying to read it or trying to make sense of it is more effort than writing it ever was. And given the fact that code is typically read many more times than that it is written it pays off to write it well, but hardly anybody really does. The pressure to deliver the next commercial feature is just too high.
And woe to the interviewee that points out the deficiencies in the code if the author of the code happens to be the interviewer, because people will be people, so this could easily turn into a minefield.
Questions to ask of the interviewer before 'reading' the code:
- who wrote it?
- is it functional?
- are you supposed to debug it or explain it?
- was it written for the express purpose of the interview or is it code from the company codebase that is representative of how they work there? (this alone might be reason to terminate the interview depending on how it looks :) ).
The problem is that the 'existing code' may well be of poor quality and that in order to understand it you first have to get into what it was supposed to be doing in the first place, and this isn't always obvious. So the writer had better take good care to make the code self explanatory or provide additional documentation to give sufficient context. In a way the underlying assumption is that the code is 'good'.
And that's where the real problem lies: lots of code isn't all that good and plenty of it is probably best described as 'single use', in other words: write only. Trying to read it or trying to make sense of it is more effort than writing it ever was. And given the fact that code is typically read many more times than that it is written it pays off to write it well, but hardly anybody really does. The pressure to deliver the next commercial feature is just too high.
And woe to the interviewee that points out the deficiencies in the code if the author of the code happens to be the interviewer, because people will be people, so this could easily turn into a minefield.
Questions to ask of the interviewer before 'reading' the code:
- who wrote it?
- is it functional?
- are you supposed to debug it or explain it?
- was it written for the express purpose of the interview or is it code from the company codebase that is representative of how they work there? (this alone might be reason to terminate the interview depending on how it looks :) ).