Interviewing tips for software engineers applying to Zalando. Before Amazon, I worked for Zalando for over 2 years. During that time I interviewed countless developers, from junior to tech leads, mostly in the Android space. In this post, I share what I was looking for and how to best prepare for the software engineer interviews.
Zalando is the leader company for online fashion in Europe. In 2017, the company totaled over € 4 billion in revenue and grew more than 20%. They employ an agile and laid back style that focuses on team autonomy, mastery, and purpose. To sustain their rapid growth, they’re hiring plenty of engineers.
I had the pleasure not only to work for the company but also to be on the frontline of interviewers. I did hundreds of phone screens, Skype interviews, onsite interviews and also some manager/tech lead interviews.
I will describe the process how it was when I left the company, which is in May 2017. There might have been changes but I expect the structure to be quite similar.
The interview process
The interview process consists of:
- A call with a recruiter
- A phone screen over Skype with an engineer
- Three Skype or onsite interviews
The recruiter call deals with behavioral questions such as your motivation to join Zalando and what excites you about your job. Also know your resume inside out and be prepared to talk about your past projects.
The second interview is a phone screen with an engineer. This interview is similar to the other onsite interviews but it may kill your application if your performance is not great. The covered topics are technical: coding, algorithms, Java, architecture, design, and some easy questions on standards such as HTTP and REST.
Zalando vs other tech companies
Zalando is growing fast and the change is reflected in its interview process. To sustain the company’s growth, the hiring pipeline was remodeled after the suggestion of a consultant who previously worked for Google. The main ideas are similar to my posts about the Google interview and the Amazon interview, especially the part about algorithms.
The main differences are:
- Zalando focuses more than usual on Java knowledge
- Android specific interviews will have plenty of Android questions
- Algorithms are easier than Google or Amazon
- System design might include API design as well
- There can be knowledge questions about tools, best practices, and technologies.
Java questions
In order to pass the interview, you must know Java well.
Read Effective Java, 3ed. In particular, focus on the contracts of equals(), hashCode(), and compareTo() (Items 10 and 11). If you read the second edition, read the third edition again: it has additional content from Java 7, 8 and 9, such as best practices for try-with-resources, stream API, and modules.
Another important topic is to know what classical data structures Java provides. Know when to use a Set and when to use a List, the differences between the two, and the big-O notations for their main concrete implementations.
For more specific Java tips, you can read this blog post by Sean Floyd, an ex-colleague of mine.
Android questions
If you want an Android role, you need to know the Android fundamentals. They include:
- Activity, Services, Content Providers and Intent Receivers (in order of importance and detail)
- Fragments and Views
- The lifecycle of all above
- Main libraries and tooling
- How to carry out common operations such as network requests and saving data to flash memory.
The list looks basic and simple but so many people can’t answer basic questions around these topics. Brush up your fundamentals.
The main resource for this is the developer site, containing trainings and the Java docs of the APIs. If you want to go deeper into the system internals I recommend two books:
- Modern Operating Systems, 4th edition, Chapter 10.8: make sure to get the 4th edition as it contains a chapter by Dianne Hackborne, one of the creators of Android. This chapter explains how Android works at the OS level and some of its differences from plain Linux. The information is golden and very hard to find elsewhere.
- Embedded Android: Porting, Extending, and Customizing: this book deals with the internals of the OS and the contained information come from countless hours of tweaking and playing around. Having worked myself at the OS level, I might say that this information is extremely hard to find. Don’t be put off too much by the age of the book: most of the Android internals haven’t changed fundamentally from Android 2.3 (at least at the level of this book).
Algorithms and data structures questions
Algorithmic questions are easier than the big 4. Usually, at least one interview will deal with coding, with an emphasis on algorithms. Other interviews may have easier coding questions on the line of “reverse a string”. More advanced topics such as graphs and dynamic programming (and more dynamic programming) are not so common.
For example, I used to ask flood fill, a graph question. The problem was taken directly from Cracking the Code Interview and can be resolved in few lines of code either by recursion (DFS) or with a queue (BSF). I thought that taking a problem from a standard source would make it easier to answer. I was wrong: only one person in a dozen answered satisfactorily and I had to take the question out.
To prepare I recommend Tech Interview Pro by ex-Google, ex-Facebook Senior Staff Software Engineer Patrick Shyu (the Tech Lead). Use this links to get 40% off and support the blog. And for more popular coding interview problems, check out CoderPro. Use this link to get 20% off.
System design questions
System designs questions vary a lot in Zalando. For Android roles they revolve around:
- App architecture design (not distributed systems)
- API design (following REST principles)
- Component/OOP design.
For the first question, have a sound understanding of Clean Architecture and/or some alternatives. You need to articulate how you would distribute logic through components and how to make them testable.
For the API design, you need a basic understanding of REST and HTTP. It is not expected you know fancy media types or the intricacies of HTTP proxies but you need to know how to structure an API and its data using HTTP and JSON. You should have a look at the Richardson’s maturity model (till level 2) and perhaps have a quick look at his book, RESTful Web Services. (Richardson’s newer book, RESTful Web APIs, deals with REST level 3, i.e. hypermedia controls, which is more advanced and out of scope for the interview)
Component and OOP design questions are less common and I don’t believe they require specific preparation. They may involve the high-level design of a component or the code design of a class. Best practices and well-used design patterns are always welcomed. As an example, when asking flood-fill to more experienced candidates, I would leave the question open and expect them to model the problem themselves.
Tools, best practices, and technologies questions
This is a broad category. As a software engineer, you need to keep up-to-date with the industry best practices, know your tools and be constantly learning. Common questions in this domain involve knowledge of methodologies such as TDD, libraries such as Retrofit and blog resources such as Medium or HackerNews. The key element here is not to know any specific tool (though it helps to have some breadth) but rather to show motivation, commitment and desire to learn more.
What interviewers are looking for
Contrarily to other sources, I still believe that solving the problem with correct code is the best way to ace an interview. Good code goes a long way and makes up for rough starts, lack of knowledge and even suboptimal communication skills.
This varies from interviewer to interviewer. In my mind, I had a bar set by interviewing dozens of candidates. During the interview, I would compare your performance with what I had already seen. Good candidates managed, on average, to solve the problem. Bad candidates didn’t. So this for me was the most important point.
The second most important point was communication skills. Say you come up with a brilliant algorithm but cannot articulate your thoughts. I don’t understand your solution, so how should I score you? Well, I would analyze your code post-interview and see if it works. If you “solved the problem”, you are all good, I would even grant additional points for smartness. But, more likely, you have some bugs in your code. Not understanding your idea, I don’t know if your approach is fundamentally flawed or you just mistyped some indices. So I would consider the code wrong and reject you. On the other hand, if the interview was about system design the situation is even worse: the whole point was to showcase your communication skills and you just bombed it.
Finally, the scoring system had four categories: strong yes, yes, no, strong no. You generally need most yes‘s to pass. You might still go through with a no, but a strong no would kill your application very quickly. Of course, take this with a grain of salt because it has been about a year since I left Zalando for Amazon.