Only the code that I write is Perfect, Pristine, and Timeless. (There are only so many Perfect Coders allowed per planet, and I’m it.) All the code you’re likely to encounter will be old-crap that’s barely hanging-on on life support. ;-)
Seriously, most code is “already existing,” therefore “legacy.” The new code that you write, as soon as you write it, becomes part of that “legacy.”
So, it is always an important skill to be able to assess the present-state of a piece of code, to fully understand the desired future-state, and then to be able to articulate and to estimate what it will take to move it forward ... and at what business-risk, and with what allowances for Sergeant SNAFU ... and how it will be testable and how it will be tested ... before you and/or your team starts to write it.
Most of the time, you will find these practices are followed, because people really do need to write stuff that is more-or-less stable and that more-or-less stays that way. However, the code has been changed, many times and by many people over many years for many reasons. This is inherently de-stabilizing to software. The work practices are often most-important: how do they handle problem-reports and change requests? Do they use source-code control? What is their deployment procedure, and how do they recover from / roll back a deploy? How do they “mentor” new team members, such as you would be? These are things that you should ask during that same interview.
Most programmer positions have little direct client contact. But you will still need to develop the ability to converse effectively with a non-technical person about a highly technical subject. You will need to be able to communicate effectively with members of your team, including those who know more and those who know less than you (about a particular subject area), and to work with them effectively as a team. Computer software is not the work of one person.