I had a dozen interviews in my life (I'm about to graduate) and I wonder why I was only once asked to read and explain some code. Roughly, 90% jobs are mostly about maintaining existing systems. IMO ability to read someone else's code is an important skill.

Why don't interviewers check it?*

*Among my friends I am the only one that was asked to review some code.

  • 4
    I was asked to read some C code at an interview once, and I pointed out numerous poor practices in the code: memory allocated here and freed way over there, etc. It was their production code. I didn't get an offer. – kevin cline Aug 29 '12 at 20:08
  • 1
    Voting to close simply because we cant answer why other people did or didnt do something. For all we know he got eliminated from the hiring process before they got to the source-code reading stage. If this was changed to 'should interviewers require...', it might be a suitable question. – GrandmasterB Aug 29 '12 at 20:43
  • 1
    @GrandmasterB Interviewers also show up on this site. If they intentionally don't look for code-reading skills, there may well be a good reason for it. – Izkata Aug 29 '12 at 20:58
  • Please avoid extended discussion in comments. If you would like to discuss the merits of this question further then please open a question on Meta where such a discussion belongs. Thank you. – maple_shaft Aug 30 '12 at 0:18
  • I would like to add that I have been asked to read code before and point out bad practices and any errors. – andy Dec 10 '12 at 16:20

When I was asking interview questions I did at first but slowly phased it out. The applicants that could write code well in the interview could all read code well in the interview. The applicants who couldn't read code couldn't write it either. The questions involved in reading code didn't really differentiate any applicants.

| improve this answer | |

Short version

If the job consists of maintaining an application, the skills you need to test during interviews are:

  • The ability to understand the large codebase with its documentation, unit tests, etc.

  • The ability to refactor the code and to bring changes without breaking everything.

Asking people to read code will not help you to evaluate those abilities.

Long version

Were you asked writing code? If yes, as Sign noted in his answer, this is enough. If we generalize a bit, a person who write clear, easy to understand source code would be able to read source code written by other people.

If you weren't asked to write code, then, well, you were probably interviewed by a person from human resources department. Such interviews cannot be too technical, and are mostly worthless, since they don't asset your skills and your ability to work well, but rather the number of years you spent in college and other things which has nothing to do with the job.

There are a few more reasons to not asking to read code for a maintenance job:

1. It's difficult to do reliably

Concretely, what would you do if you were an interviewer? Make your candidates read some code. What code? In what language? How well or badly written? With or without comments? With or without documentation?

More importantly, what does it tell about the candidate? How well does it correlate with codebase itself?

Let's say you have a legacy VB.NET app to maintain. You know that the source code is mostly ugly and untested, and a few comments are outdated or misleading. For the past three months, you had a very skillful developer working on the solution; he refactored and unit tested the most critical parts of the application, added comments where there was a need for comments, and, most importantly, wrote detailed documentation about the overall architecture, the critical parts and the pitfalls.

You're now hiring a developer to maintain this codebase. During an interview, would you give a piece of legacy (ugly untested) code, or the piece of code which was refactored by the previous developer?

Would you give the documentation? In order to read documentation, the candidate will need to spend at least a few hours. This makes it impossible to do during an interview.

2. Reading short piece of code is not the same as reading code of a familiar project

Remember, the job is to maintain a project. It is difficult to maintain a large codebase the first days or weeks when you're not familiar with the project. It's much easier to do it after a few months when you've written all the documentation and have a clear view of the overall codebase.

The most important thing to test is if the person will be efficient those months. You don't care if the person will not be able to understand anything at all the first two days.

By asking a person to read a short piece of code from scratch, you are not testing how this person would be able to deal with a familiar, documented codeabse of thousands of LOC.

3. Maintaining source code is not just reading it

When you are maintaining a codebase, you are modifying it. A developer who just reads code doesn't bring anything useful to his company.

The useful skills are the ability to refactor code, to add unit tests, to predict the impact of a change, etc. You don't test those skills by asking a person to read code during the interview.

| improve this answer | |

Reading is an assumption based on the fact that ability is present for writing. Consider the concept in any language. Programming is just a language to communicate between human and machine. Consider a human to human communication. If you were hiring someone to be an interpreter for Japanese, wouldn't it stand to reason that if they could write a 1,000 word essay on a particular topic that they would be able to read it?

As programmers, our primary activity is the creation of code and the translation of abstract ideas into concrete implementations. This generally means writing. I agree that reading is just as critical, but in a large majority of cases, where writing ability is present reading ability is also present. The only real case where I could see a distinguishable difference would be in an environment where there are a lot of highly complex cases that have evolved over time. Even given these, though, you would not expect someone to be able to read them and understand them without at least some study.

Also, reading code and explaining what you think it does doesn't really express to an interviewer how you use your critical thinking skills. It shows a bit of analysis, but most employers want to see if you can think without being placed into a box. They want to know if you can grasp the concepts without the benefit (or crutch even) of existing code to tell you what or how to do something.

| improve this answer | |
  • Read it, yes, understand it?...not necessarily. – jmoreno Aug 29 '12 at 18:15
  • 1
    @jmoreno: Maybe not, but given how precious time is, if you ask a candidate to write something similar you can gain much more knowledge than you can watching them read something complex. – Joel Etherton Aug 29 '12 at 19:06
  • I disagree. Once you get beyond trivial implementations, reading code is much harder than writing code, and there are a large number of developers who can write code but can't read existing code, mainly because code is all in the imperative tense. To use the foreign language metaphor, developers are mostly rich tourists who need to be understood enough to get what they want, but don't feel the need to understand what's being said around them. – Dan Monego Aug 29 '12 at 19:34
  • 1
    @DanMonego: I understand your point, and it's not that I disagree at all, but the question is regarding why most interviews do not incorporate reading not what the value of reading is. Most interviews don't involve more than trivial implementations whether it's reading or righting because of the nature of time. – Joel Etherton Aug 29 '12 at 21:34

In the past I use to think that reading code should be something demonstrated in interviews, but over time I've realized that this is a waste of time for both for the interviewer and interviewee. Why? Because even bad coders can read a snip-it of code.

Being able to judge someone's ability to read code only becomes relevant when you look at something complex or code spanning many classes and files. Being able to trace code to figure out what it's doing is a desirable trait, but there just isn't enough time for someone to come up with a good example (not production code) nor is there time in an interview to ask such a question.

So, bad coders can read code, but they can't write code well. Asking to see examples of a candidates work or to ask a candidate to write code in the interview are way better indicators of their skill. If they can write out clean concise code, chances are they can read code was well.

I ask every candidate I'm interviewing a variation of the FizzBuzz problem. It's quick, simple and can normally pick out bad coders much faster than anything else I've found. A good programmer will get it very quickly and easily and it will give you a quick look in to their coding style and thought process.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.