went through the Zendesk senior SWE loop earlier this year (got the offer, joined, left 4 months later for unrelated reasons, but that's another thread). wanted to leave something useful about the system design round since i found basically nothing when i was prepping.
the system design interview at Zendesk is 60 minutes, one interviewer, virtual whiteboard (Miro or similar). they gave me the classic "design a ticketing system" prompt which, yeah, ironic given what the company does. i think this was intentional. they want to see if you actually understand their product space.
what they cared about most: scoping. i started asking clarifying questions immediately and the interviewer visibly relaxed. they told me later that most candidates just start drawing boxes. write vs. read patterns. tickets are write-heavy at creation, read-heavy during support workflows. you should call this out. indexing strategy for searches across ticket fields. i talked about elasticsearch vs. postgres full-text, they pushed hard on tradeoffs. queue/async processing for SLA alerts and webhook delivery.
what they did NOT harp on: exact numbers at scale (you need rough estimates but don't need to nail the math) kubernetes specifics or infra topology microservices vs. monolith holy war (they have a service mesh; they don't need you to redesign it)
level being targeted was senior/L5 equivalent. the signal they seemed to want was: can you drive the conversation, can you make tradeoffs explicit, can you prioritize ruthlessly given 60 minutes. it's less about whether you know the "right" answer and more about whether your thought process would hold up in a real design review.
one thing i wish someone told me: they pulled from the actual Zendesk product surface. know roughly how Zendesk works as a product. you don't need to have used it daily but you should understand the ticket lifecycle, routing, and SLA tracking at a conceptual level. that context made my design choices feel grounded instead of generic.