I think you're better off working abstractly, for two reasons:
1 - the nature of the issues of the day is likely to have sensitive information on it that the group may not want to show to a new person. Certainly the sensitivity varies widely from company to company but it's pretty common to ask engineers not to publicly share bugs and security issues publicly, and an interviewee is pretty close to public. Also, at least in some companies, there may not be a guarantee that the backlog of the team member you are talking to will be your backlog should you join.
2 - it doesn't reflect much about your ability to communicate in the abstract. If you can get your questions into a backlog-agnostic form and drive towards the processes or practices you're looking for, you show the interviewer that you are capable of backing away from the details and asking in a more general way about the way the team manages work. That's a pretty useful skill to demonstrate in an interview!
In between the two - I don't know any team that hasn't had to make some compromises on how they manage their backlog, so just looking at the backlog may not answer some of the most interesting questions about how work gets decided and worked on.