Yeah. Even a "firefighter" should be able to discuss the architecture(s) they inherited, and the associated strengths and pain points, and the tricky/interesting parts of the system. So I wouldn't view that as an impediment at all to this style of interview.

And I'm not interested in the sorts of specific details that go fuzzy over time. I'm interested in a big picture view of choices made and alternatives discarded. We should talk about some implementation details as well, but "I don't recall" is definitely an acceptable answer for some decently large percentage of those choices.

If you're talking about a Rails project you did ten years ago, I don't really care if you used Sidekiq instead of Resque or vice-versa. I mostly want to know if you know what sorts of jobs should be moved to background tasks and how you structure those jobs and what are the tradeoffs etc.

Also, if I (the interviewer) selected one of the candidate's more "boring" roles, I'd happily let them suggest we focus on one that is juicier and/or one where they were more involved in the design process.