TLDR: The coding problems consist of classical Cracking The Coding Interview stuff and no single problem was overly difficult. But I would still recommend to properly prepare since it’s a different beast to solve these problems on a whiteboard - even if they are a rather easy if you are sitting at home on your couch with your favorite IDE. Furthermore, be prepared to cover _a lot_ of topics: The interviewers (most of them are very experienced) asked me questions that covered everything from low-level data structure and implementation stuff to design, scalability, QA, DevOps, development methodologies and leadership. Last but not least: The recruiter I worked with (Michael) did an outstanding job - he was very engaged and kept me informed about every step in the process. Step 0: A recruiter got in touch with me on LinkedIn / initial call with the recruiter The interview process consisted of 7 steps: Step 1: Phone Interview with the Hiring Manager A roughly 45 minutes long phone interview with the hiring manager. This was actually a little bit tricky since I interviewed for 2 different roles at the same time. That made the conversation until the end of the interview process a little bit less straight forward compared to the case where you know exactly which role you are applying for. Step 2: Technical phone screen A software engineer administered a coding challenge via CodePair. It started with a fairly easy tree construction / processing exercise. The interviewer then incrementally added more requirements and asked some behavioral question in the end. Step 3 (on-site): 1 hour whiteboard coding session Two software engineers conducted a 1-hour whiteboard coding session that covered basic data structure stuff. While it was not too difficult, you should be confident writing compilable code on a whiteboard. Step 4 (on-site): 1 hour lunch with the hiring manager A (obviously) less technical session without any whiteboarding. Gave both me and the hiring manager a chance to talk in more detail about both roles. The hiring manager also asked a lot of process related questions: Which development methodology (e.g. Scrum vs Kanban) do I prefer and why? What is my take on TDD? Stuff like this. Step 5 (on-site): 1 hour whiteboard system design session One software engineer and a DevOps manager conducted a 1-hour whiteboard system design session. The task was to design a scalable web application. Should not be too difficult if you have done that before. Step 6 (on-site): 1 hour DevOps / QA Q&A session A 1 hour conversation with two DevOps / QA engineers. Boy, I don’t even recall how many topics we touched. Felt like we talked about every single topic you can discuss about in software engineering world. Step 7 (on-site): 1 hour whiteboard coding session Ironically, the initial task (some in-place string manipulation stuff) was the easiest problem I was given so far. But I made the mistake to define my test cases only as set of parameters (I did not write down the expected values). The result was that I had to keep track of two different things while manually debugging my code: What should the algorithm do vs. what does the algorithm do. This threw me off big time and I was not able to fully recover from my brain freeze (since at this time I did not really see the root cause). So I just struggled through it until the end.