What do candidates report about the coding and system design rounds?

Reported coding signals. A former Zalando interviewer on Blind in 2021 said to expect "basic LC questions ~medium" and "would not expect hards". A December 2025 Glassdoor snippet calls the coding assessment LeetCode medium. Problems named in reports include binary search, finding two numbers that sum to k in a rotated sorted array (solved first with a hash map, then with two pointers), a dynamic-programming string problem and flood fill. An older interviewer write-up from 2018 says correct working code matters most, communication second, and that Zalando "focuses more than usual on Java knowledge".

Reported design prompts. Payment system, inventory system, ticket booking with follow-ups on modelling billions of records and distributed transactions, URL shortener, a crawler, a to-do list with cloud cost estimates, an analytics system for large user-generated data, and defining a REST resource's methods, headers, payloads and status codes. Each prompt appears once; none repeats across reports.

Lessons candidates state.

• Ask about scale first. One June 2026 candidate wrote that they failed design because they should have asked for the number of clients instead of assuming.
• Cover the six criteria Zalando publishes: architecture, scalability, technology choices, resilience, operational excellence and security. Operations and security are easy to forget.
• Know HTTP precisely. One candidate stumbled on the status code for validation errors. The correct code is 422, which RFC 9110 now names Unprocessable Content; 400 is the general alternative. Zalando publishes its own RESTful API Guidelines, which are worth reading before an API design question.

Inferred for a search role. No public report from a search candidate exists. For a search team, a product-search design is plausible; prepare it from Product catalog search system design.

Alternate interview scenarios

"Design a crawler that, given a set of profile links, collects public user information." This is the 2022 report's system-design prompt. I would scope it first: how many seed links, how fresh the data must be, and whether links found on a page should be followed or only the given set crawled. Then:

• Pipeline: a URL frontier (a queue partitioned by host), fetch workers, a parser that extracts the profile fields, and a store keyed by the profile's canonical URL or ID.
• Politeness and legality: obey robots.txt, which RFC 9309 standardises: a crawler finds the group of rules for its user agent and applies the most specific match, and the RFC notes the rules are not a form of access authorization, limit requests per host, and back off on 429 or 5xx responses. Check the site's terms; where the platform offers an official API, use it instead of scraping pages.
• Deduplication and freshness: normalise URLs, keep a seen set, and re-crawl on a schedule based on how often a profile changes.
• Failures: retries with backoff, a dead-letter queue for pages that keep failing, and idempotent writes so a re-fetch does not create duplicates.
• Scale: partition the frontier by host so one worker group owns the rate limit for each site, and scale fetchers horizontally.

"You are building an app with a lot of data. Estimate what it costs to run on AWS." The same report says the general-tech round asked for this. I would not quote prices from memory. I estimate the drivers and then price them: requests per second and payload size give compute and data transfer; data volume times replication and retention gives storage; reads and writes per second size the database. Then I name the biggest cost and how to cut it, such as caching, cheaper storage tiers for old data, or right-sizing instances, and say I would confirm with the AWS Pricing Calculator.