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.
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.