I had the exact, cookie-cutter experience that seems to summarize every software engineer candidate with this company.
I had a pleasant half-hour talk with the recruiter who talked about the products they work on and went over the interview process. I told the recruiter about my experience. One of the things that we discussed was Python. From what I've heard, it isn't terribly difficult to come up to speed on, but I made it clear that I am not currently familiar with it. He said that wouldn't be a problem as long as I would be able to quickly learn it.
The next step was the "test". After seeing the first two or three multiple choice questions, I realized that not having any Python experience would make this pointless. I could obviously Google Python syntax and figure out the questions, but certainly not in the time allotted.
Seeing this, I skipped forward to the two coding questions. Neither of these questions offered a mental challenge, just artificial timing challenges.
The first coding question was the oft-mentioned RPC calculator. Once you realize that this is stack-based, implementing it is trivial. Where I fell in the weeds was when one of the test cases failed. You aren't allowed to know what the test cases are. Even your program output is hidden from you. The idea is you just have to guess what could be wrong and repeatedly throw the pasta against the wall until it sticks. My problem turned out to be that they were using a multi-digit integer for one of the calculations. Normally, RPC calculators use one digit at a time. Fortunately, I guessed this and corrected for it. This is great for a hacker challenge, but not at all a real-world problem. Kind of like how real chefs don't have to deal with what you see on Hell's Kitchen.
That left just a few minutes for the second coding question. It was the also-previously mentioned find bodies of water and their sizes. I knew exactly how to solve this (modified flood-fill), and I got it typed in, but ran out of time doing the final debugging and cleaning up. Obviously, I had no time to go back to the multiple choice questions.
After I closed the test, I went ahead and finished coding the solution on my PC (it took five more minutes) and testing it. When the recruiter first emailed me, he said "I manage our engineering recruiting efforts for the Seattle office...", so I sent him an email with detailed feedback on the test and the process. The response? One line: "Unfortunately you didn't pass the quiz but thanks for giving it a try. Thanks again for considering us in your search."
Ultimately, this process paints a poor picture. If the work environment of this company is reflected by their recruiting process, then instead of doing thoughtful work solving interesting problems, you'll spend your days speed-typing to beat a timer and dealing with arbitrary limitations that have nothing to do with solving the core problem.
I'm going to share the coding problems below. To be clear, I'm not under any kind of NDA from this company, and they never asked me not to share this information. That said, knowing exactly how to code the solution won't help you. You just won't have time.
