Lululemon · Primly Community

Lululemon coding interview / online assessment, format and difficulty breakdown

market_realist · 4 replies

did the lululemon online assessment back in february for a mid-senior backend role. been meaning to write this up.

first: it's NOT a standard HackerRank grind. no timed algorithmic puzzles with edge-case-heavy test cases. they sent a github repo with a partial implementation and a set of failing tests, and you had 72 hours to make the tests pass AND add tests of your own.

the problem domain was something like: a simplified checkout service with a loyalty points calculation system. they had some classes stubbed out, a README explaining the business rules, and about 15 pre-written tests that covered basic happy paths.

what the assessment actually tested: reading existing code quickly and understanding the intended design implementing business logic correctly (the edge cases were in the business rules, not some contrived algorithmic trick) writing tests. this is not optional. they looked at test quality. code organization: naming, function size, whether you introduced unnecessary complexity

language was open, i used Python. the take-home had a note saying they'd discuss my choices in the debrief, which was true.

difficulty: honestly medium. if you've worked on real product code you'll be fine. if you only grind leetcode and never write maintainable, tested code for real systems, you'll struggle more than expected.

timing: most people could probably do a decent job in 4-5 hours. i spent about 7 because i over-engineered the refactor. don't do that. do the simple thing that works and is well-tested.

debrief: there was a 30 min debrief call where they walked through my submission with questions. they asked why i structured the loyalty calculation the way i did. be ready to defend your choices out loud.

bottom line: if you're a good engineer who writes real code at work, this format plays to your strengths. if you're purely interview-grinding, the format might catch you off guard because there's no single "trick" to solve.

4 replies

ds_dmitri

this is so much more interesting than a timed leetcode screen. it's also so much harder to fake. you can memorize a DP solution but you can't fake a well-structured, tested codebase under time pressure.

pivot_pat

the debrief call part is kind of terrifying. did they try to catch you out or was it more collaborative? i always freeze when i have to explain my code on the spot.

quietquit_quincy

genuinely collaborative in my case. they asked questions but it felt like curiosity not gotcha. the one thing i'd say: don't be defensive. if you'd refactor something now you know the requirements better, say so. they liked that.

contractor_kai

72 hour window but only 4-7 hours of actual work. that's the right design for an OA. lets people with day jobs actually do it without having to take PTO. more companies should do this instead of synchronous timed assessments.