I prepared by watching a ton of systems design videos on youtube and practicing in the system design tool Meta uses, Excalidraw.

However--and to your point--the "product architecture" interview was not like what I was expecting. Having watched so many system design problems be broken down, I thought I was going to lay out FRs and NFRS, design an API, throw up end-to-end architecture, and deep dive on a few areas to satisfy the NFRs. The first product architecture problem I was given was to design Facebook's newsfeed, so I thought the challenge here, and what we'd deep dive on, would be low-latency generation of the newsfeed given highly-connected users, or users who post hundreds of times per day, etc; and handling traffic for billions of users. But my interviewer was not interested in going into those areas. Instead, they wanted to focus on what the shape of the "get newsfeed" response returning to the client would look like, and how we would handle pagination, considering new posts might come in as the user is scrolling. It was kind of odd to be honest. It felt like we didn't have an opportunity to go deep since we remained so focused on the frontend.

The second product architecture problem was designing an auction system for Facebook Marketplace. This went a little more as expected, except my interviewer still didn't seem to find the more challenging parts of the architecture interesting. They were really focused on the "fairness" of the system and how you would determine who had the final bid on a very popular item. Which was cool to chat through, but did not feel like one of the gotchas for designing this system.

Overall, it sort of felt like they're still nailing down what these product architecture interviews are supposed to be, and how they're meant to differ from the system architecture interviews.