Another candidate mentioned this, but it bears repeating: the first interview is a coding screen conducted with another developer. They provide a two-part problem: Part One is a dense, "real-world" scenario that ultimately boils down to just 3–4 if statements checking deltas between inputs. It’s a trap and a major time sink. Spend no more than 15–20 minutes here. Most of the time is spent parsing the overly complex problem statement, not writing the code. In my case, the interviewer encouraged me to add extra tests, which ended up being unnecessary, and I easily spent 35–40 minutes on this section. Part Two is where you are truly evaluated. It’s more complex and typically involves recursion—likely DFS. You’re given a list of groups with parent/child relationships (think org chart) where the relationships are represented by nested class objects. The task might include counting direct reports or similar traversals. After this you would then use the 3-4 if statements on each person in each group getting group aggerated data. I ran out of time and was ultimately rejected. Tip: If possible, ask the interviewer which part usually takes longer. You may be allowed to tackle the second part first, which can often be solved 99% without completing part one.

Really enjoyed the conversations, had a leetcode style phone interview. Onsite was 50% behavioral and 50% technical. System design + backend practical. Backend practical was coding plus understanding of distributed systems.