[pton_xd]

Recollection of specific implementation details of an old project may be fuzzy, but I'd hazard that any competent programmer should be able to discuss the themes and challenges of the project in depth, along with approaches for different requirements.

Overall shallow knowledge is not a positive signal, in my opinion. If they really are a firefighter who constantly jumps around, the interviewer should lean in to the organizational challenges they face when identifying and fixing problems across a variety of projects and domains. There's always a way to drill down with more specific questions.

[JohnBooty]

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.