Overall a bit of a confusing interview experience

Phone screen (remote coding) - Used a coderpad to write basic functionality (not really leet-codey, more of a hybrid real-world question with some tricky combinations). They added new requirements as you completed each step of the question. Was straightforward. Upside was you actually got to run your code.

Onsite -

• Manager interview - Generic person/motivation questions
• Design round - Very typical. Was a concrete problem but didn't need to provide actual queries or anything.
• Coding round - Same as phone screen
• Debugging round - Here you have 45 minutes to clone and fix a bug in real-world project. I got to look at a scala example which was obscenely hard and a python example (exponentially easier, but still poorly written uncommented code that used exceptions in the normal flow, and very hard to reason about).
• Build a feature Round - Build something from scratch in 45 minutes.

My takeaway is don't use scala for the debugging round or the build-a-feature round [the setup time is too high and the nature of the problems favors interpreted languages]. Also since these use a local IDE, and zoom slows down computers quite intensely a slow compiler can be an issue. Thirdly, be 100% sure you have your IDE setup to run and DEBUG local unit tests (in a step-through manner).

For fun I looked at the scala debug question for an additional few hours after the interview. Apparently one is supposed to find a bug in a massively-parallel graph-processing library that was written by a faang company. Still couldn't find the bug after hours of looking at the code, it was pretty gnarly (loops going 5+6 levels deep with async, many side-effects).

One of the strengths was that I felt all the interviewers I spoke to had a strong command of the english language and were friendly.

Fortunately I already had a better offer from a better company but I thought I'd share with the community that shared with me.