A brief phone screen, with most questions revolving around experience, and various typical questions like "Describe a project or situation where you encountered a major problem and how you worked to resolve it", and one "logic" question.

Invited to an onsite at various locations (had to pick one). There is a group call explaining the day a week ahead of time, going into lots of detail; this was very helpful.

The interview day itself was a half day, with three 45-minute slots with various senior developers. You and some of the other candidates on that half day always reconvened in a meeting room with various snacks and drinks, and were encouraged to have a friendly chat. There was no pressure here; the recruiter (who followed me along the entire process, even after hiring) insisted that they did not have numbers to fill and would select any candidate that was a match. This ended up being incredibly nice and was a chance to discover the different backgrounds of people in the field.

The interviews themselves followed a different form depending on the office. Interviewers had great liberty to do what they felt was necessary to get to know you. I'd recommend the usual (and they will too):

• Do some HackerRank questions
• Practice on a whiteboard
• Read some algorithm design books
• Brush up on your data structures and software engineering practices

The programming questions themselves weren't particularly difficult, but generally allowed less than 15 minutes after the long talk to figure them out. What's important here are edge cases and reasoning how you spot things going wrong in what you wrote. Perfect code with all edge cases was not expected, but you were expected to spot these problems once you thought you were done.

Write a function that, given two input strings and a third "reference" string, determines whether the reference string is an in-order mix of the first two.

Examples: "aaa" "bbb" "aababb" -> true "abc" "abb" "abbbc" -> true "a" "" "b" -> false