What coding patterns show up in reported Zalando problems, and how should you solve them?

Problem types, from problems that were actually stated or named.

• Strings and scanning: contact search by a phone-number substring; constructing a string from AA / BB / AB.
• Hashing and two pointers: the hash-set then constant-space solution for two-sum in a rotated sorted array, already answered at How do you find two numbers that sum to k in a rotated sorted array?.
• Binary search: that same rotation-point step, and a live-coding item described only as "binary search on an array list."
• Greedy simulation: ice-cream change; the AA / BB / AB construction; a card-picking game whose rules were not remembered, with a request to keep the design extensible and not more complex than the moment required.
• Intervals: covered time as a union length, in the spirit of merging intervals.
• Arrays / filtering: sum of two-digit integers, a warm-up scan.
• Light graphs: flood fill as a small BFS or DFS; Dijkstra as a shortest-path discussion.
• Practical application work: a search box with autosuggest, judged on tests, names, and debounce. One backend online test also had a Java slot and a SQL slot next to a DSA question; the statements were not published.

Trees, heaps and heavy DP are not the problems people wrote down most often. A "DP string question" was named on one thread with no statement, so it is not expanded into a made-up prompt here.

Difficulty. Across public reports and a former interviewer's write-up, the algorithmic work sits in the Easy to Medium band, not Hard-level contest problems. That is a statement about the DSA, not a claim that the interview is easy: clarification, tests, and a simple design are part of the bar.

How to solve under a time limit. Zalando's own software-engineer interview post asks you to clarify anything that is unclear, write code in a live environment, and discuss trade-offs, data-structure choices, and time and memory complexity. It recommends the REACTO strategy. A practical order that matches that rubric:

1. Restate the rules and ask about edges before you type: empty input, no match, duplicates, open versus closed interval ends, what to return when several answers are valid.
2. Ship a correct solution first, even if it uses extra memory. The rotated-array two-sum report did this: a hash set in linear time and space, then a tighter two-pointer pass.
3. Then tighten time and memory, and say the complexity out loud.
4. Treat hidden tests as part of the problem. Online assessments run code against cases you do not see. Before you stop, try the empty case, the "NO CONTACT" case, a twenty that needs three fives, touching intervals, and a start color that already equals the fill color.
5. When the prompt is a small feature or a simulation, write tests and keep the design small. A 2025 coding interview was described as expecting requirement clarification, tests, and explicit error handling, in the way you would write production code, rather than only a pasted LeetCode solution. A 2023 simulation task asked for an extensible design and later feedback was that a more complex design was not required at that point. Start with a clear model and tests; add abstraction when a follow-up needs it.

What this page does not turn into a full question, and why.

• Two-sum in a rotated sorted array: already published, linked above.
• Missing dice rolls: the 2020 Codility report only linked an Amazon online-assessment thread, and that thread could not be recovered, so the statement was not guessed.
• "Reverse a string," "binary search on an array list," and "a DP string question": named only, with no twist or statement.
• A card-picking game whose rules the author no longer remembered: the useful technical residue is "simulate the rules, keep the design simple, and make it extensible when asked."
• "Two easy algorithms plus an AWS Lambda implementation": no algorithm statements.