How do you structure triggers in an org, and how do you prevent unwanted recursion?

I use one trigger per object that delegates to a handler class, with methods for each context such as before insert and after update. This keeps logic testable and makes execution order predictable.

To prevent recursion I avoid unnecessary updates by comparing old and new values, and when needed I track processed record IDs in a static set, which persists for the transaction. A simple static Boolean flag can break bulk processing because it blocks later chunks, so I prefer ID-based tracking.

Interviewers look for the one-trigger-per-object pattern, handler classes and a thoughtful recursion strategy. Mentioning the static Boolean pitfall shows experience. A weak answer relies on multiple triggers per object with undefined order.