Hi Jeremy,
Thats a great question. Unfortunately, this is one aspect of programming that is extremely difficult to capture in an interview. Even with interviews that ask you to code on the spot, its very unrealistic to expect that code to be pretty. Candidates are rushed, stressed, and pressed for time - in fact it can even hurt you to spend too much time making your code pretty if it doesn't work. And once it does, the interviewers are usually more interested in the next question. In the real world, refactoring is an essential part of programming, but that comes after the code because you get a better picture as the code is developed than you do right from the start.
However, there are some questions that can hint at a candidates mindset about this. For example, people usually ask about the four visibility modifiers and their differences. My follow up question to this is always: Why not just make everything public? If a candidate doesn't have a good answer to that, I know they are not concerned about information hiding, which doesn't bode well for the code they would write. The same goes for immutable objects - I'm sure you can tell me what it is, but why would you go through the trouble of making them? The ones who answer these kind of 'why' questions confidently tend to be the ones who write the cleanest code. I had an interviewer ask me once what my
philosophy on coding was, which I thought was a great way to see how I really felt about programming. In the end, you'll have to look for clues to make an educated guess about the type of code they'll write. This is also why I advise against memorizing answers - I can't learn much about you if I hear the same thing from everyone else.
But I think the main reason code cleanliness is not critical in an interview is because a lot of good coding practices can be taught. In fact I make all my new hires read a coding standards document (if your company doesnt have one, I'm sure it would be a great help). Also I tend to be strict with the code review process - once people know that, they are more careful with future commits, just to avoid the hassle. Some things can be auto formatted of course, but I believe thats only a partial solution. If someone uses short obscure variable names, you can bet I'll make them refactor it to be more readable. In the end, its probably a gap in management if developers have these problems. But I have found that people are eager to learn how to write clean code, especially if they are surrounded by clean code. Messy code tends to stay messy, and clean code at least becomes obvious when its getting messy.
I can go on for days about clean code haha, but I better stop now!