You certainly can (and should) ask about the development methodology that is used which should tell you a good deal about how much overhead you should expect.
Rather than asking how much time you would be expected to spend babysitting deployments, you'd want to ask about the build management system. If the interviewer says that they've got a system that automatically builds and deploys to production every day with no downtime, you can be pretty confident that you're not going to spend much time dealing with deployments. If the interviewer involves more manual efforts and coordinating the efforts of humans in different groups, you'll be spending a lot more time on deployments.
Rather than asking how much time you would spend writing documentation, you'd ask about the organization's approach to software development. If they do traditional waterfall development, you'd expect that a lot more time is spent by developers writing documentation (and much more time would be spend writing requirements for the developers). If they have a more agile approach, you'd expect less time to be spent generating documentation (though, of course, that also means that the requirements you get will tend to be less detailed because the approach assumes that things will change).
Similarly, you can ask about how they track bugs, how they track requirements, how they test, how they prioritize items, etc. The more manual the process and the more process there is, the more time you should expect to spend doing non-technical tasks.
By talking about the software development process, you generally show yourself to be an engaged developer and you generally make it hard for the interviewer to (intentionally or accidentally) mislead you. Most people don't have a really accurate idea of what they actually spend time on over the course of a day-- lots of minor tasks end up swallowing much larger fractions of the day-- so it is hard for most people to accurately guess about how much time is spent working on builds. This is doubly true when the people doing the interviewing are managers that aren't doing those tasks themselves. It is easy for managers to believe that a build process is relatively smooth when, in reality, it involves a ton of manual intervention, simply because no one brings the inefficiency to their attention. Talking about the process of developing software, however, tends to be much easier since it is much more transparent. It is unlikely that a manager would be unaware, for example, of the daily standup meeting if that's what the team uses or that the manager wouldn't be able to describe at least generally how releases are planned and deployed.