During design meetings, when there are questions that causes circling around a topic that is marked as out of topic. Even though I tell people that it is out of topic as we don't have time to build it and no plan to build it in future and people are still ask questions about same topic. When I personally feel its a nice to have feature but the scope has already been defined, what to tell and move forward to continue with the rest of the design?
First, I highly recommend this similar discussion on how to keep a meeting focused (also from an SDE 2 at Amazon coincidentally enough).
When I personally feel its a nice to have feature but the scope has already been defined, what to tell and move forward to continue with the rest of the design?
I think you can more or less just say that. When I ran into these scenarios, I would run something like this pretty much word-for-word: "I think this idea's great, but let's put it on the backburner for now so we can get back to the goal of the meeting and figure out X." Doing this is going to feel painful (and if your meeting has fast talkers, you will likely need to cut someone off), but this pain will lessen over time as you build up this skill of being a little "mean" here and there.
Having strong presence and being confident in your communication is pretty much a requirement to be a senior engineer at a FAANG company. Treat these meandering meetings as a forcing function to make you develop these skills. 🙂
When I have a design meeting, I will be taking notes in a doc, and I usually have a section that lists out of scope items. When someone is bringing back the topic, then you can explicitly refer to the list of out of scope items.
I would also start by defining the goals and timeline. If the item is out of scope, then it's usually because it doesn't pass the goals or timeline requirement, so you can use that as the reasoning as to why the item is out of scope.