Zendesk · Primly Community

Zendesk coding interview and online assessment: format, difficulty, what I actually saw

sre_sol · 6 replies

just wrapped up a Zendesk SDET/QA role loop last month. different from pure SWE but the coding portions overlapped enough to be useful for a broader audience.

the online assessment (OA): two coding problems on HackerRank. 90 minutes. the difficulty was solidly medium, one problem leaned toward medium-hard. nothing i'd call LC hard. one was a graph traversal variant (BFS, finding connected components), one was a string manipulation problem. i was able to brute force one and optimize the other within time.

for a pure SWE role, a friend told me he got similar. two mediums, one array/hash map problem, one tree problem. he finished in about 50 minutes. passing the OA seemed to be table stakes for getting to the phone screen, not a differentiator.

the technical phone screen: one 45-minute call with a SWE from the team. live coding in a shared editor (CoderPad). one problem, medium complexity. mine was about rate limiting data (sliding window approach). he said it's typical. they want to see you code cleanly, explain your thinking out loud, and at least mention time/space complexity even if they don't push hard on optimization.

the onsite coding round: two separate 45-minute sessions. both more applied than pure algorithmic. one felt like a realistic scenario: parsing and querying structured data, not unlike what you'd encounter in a support tooling context. the other was closer to classic LC: two-pointer or sliding window, i think (not my loop but confirmed by two others who went through recently).

overall difficulty assessment: if you're comfortable with LC mediums, the Zendesk coding loop isn't going to surprise you. it's not Google. it's not trivial either. they seem to care more that you can write clean readable code and explain your choices than that you solve a hard problem in record time. comments, variable names, "let me think about this edge case" -- all of that matters.

also: they do use Python and JavaScript primarily on the engineering side, so coding in those will feel natural to the interviewers. using Java is fine but you may get fewer "oh nice" moments.

6 replies

firsttime_mgr

is the OA proctored at all? or just honor system?

qa_quinn

not proctored for me. no webcam, no screen monitoring as far as i could tell. just HackerRank with a timer. standard stuff.

sec_sasha

the "parsing structured data" coding problem sounds like it could overlap with what data engineers see. did anyone go through their data engineering loop and have something similar?

ae_andre

"comments, variable names" mattering is a sign that the team actually codes together and reviews each other's PRs. greenest of green flags tbh.

sdr_sky

counterpoint: "not Google" difficulty coding might also just mean the eng bar is lower. curious whether the actual team code quality matches the interview signal.

marketer_mei

from my four months there: code quality varied a lot by team. some areas were genuinely solid. others were... layered legacy. like any mid-scale SaaS. the interview was a fair proxy for what they value, i'll give them that.