How to be an expert in details?

This is a good question but also tricky to answer. This sort of intuition is something that comes with time. My main piece of advice is to focus on learning from your past, particularly your mistakes. Here's a basic process to follow:

1. Compile all the questions you've been stumped on
2. For each question, ask yourself if there was a way you could have handled it better
3. Draw patterns from #2. Maybe you have realized that you're consistently forgetting to handle older app versions. Now you know to proactively think about this in the future
4. Talk to the necessary experts to bridge knowledge gaps identified in #3

If the details you're missing are edge-cases in particular, check these out:

• https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/sweat-the-details-call-out-edge-cases/
• https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/case-study-signup-form-edge-cases/
• "How do you find edge cases in DSA problems for FAANG?"

If you can provide specific examples of questions you were stumped on, I'm happy to provide more concrete tactics.

Is there any way you are able to categorize the questions into themes? I think that a lot of questions can be bucketed into two themes:

1. Execution
   1. What's the high level solution you're going for, and why is that the best solution out of the other solutions?
   2. What's the timeline for your project?
   3. Are there any blockers?
   4. Is there anything that can make your project move faster?
   5. If you have XFN stakeholders, do you have buy-in from them?
2. Impact
   1. What kind of impact is your solution actually going to provide? (quantify if possible)?
   2. Can you think of any cases where you end up shipping your solution but it doesn't actually have the impact?
   3. Is it actually worth solving this problem?

1. One hack is to informally present / demo your work to a limited set of people (may be just one) before the actual formal presentation. Note down all the questions you get here and get answers to them before presenting to bigger audience. This is similar to doing mock interviews.
2. While prepping for the demo / presentation, try to think from the perspective of the audience to anticipate common questions. This is like self-reviewing PR before asking others for review.
3. Give a thought to how you can simplify the demos and tailor them according to the audience. If there are details that the audience doesn't care about or doesn't need to know, you can hide those and focus only on the important parts. This avoids unnecessary questions from the audience.
4. "I am not sure right now but I can get back to you on that later" is also a good answer. However, if you're saying that frequently, then that'd indicate a problem.

This question resonates with me a lot, thanks for asking and providing the context and examples! I agree with others, that this is something you develop over time and that finding patterns is key. However, I also feel that this goes beyond doc writing and presentation scenarios. I must make clear that writing is one hundred percent a great exercise to think and organize your thoughts. Identifying patterns as well as learning from other people's doc would help immensely.

While other answers have covered your scenarios, I wanted to touch upon - "I was asked to explain what a "model" is. It is a simple thing everyone ought to know, but I felt my answer was not up to the mark." - Not exactly sure how it went, but also think that you are being hard on yourself. Such scenarios become more common as one grows and are mentoring or demoing to people who won't have all the context (or are non technical). The main advice is to not be taken aback by such questions, just slow down, gather your thoughts and answer. You obviously understand what a model is, its just that no one asks these questions so we might not always have the exact words ready.

I couple of other things I use to improve attention to details are -

• Find more and more opportunities to absorb knowledge. As much as possible, be present and engage when other folks are discussing work related or operational issues in standup/team chats. A lot of decisions will come out of these discussions/events which probably won't be documented well enough in the code (e.g. why was it decided to make a particular object immutable). I am not going to comment on how to organize this information, I am pathetic at updating my docs, so I am just trying to understand the issues deeply in the moment. No template will cover all situations always... we need to get into a habit of thinking more often.
• I also find it difficult to develop strong opinions unless I have coded it. So something that I have picked up in the last year is to have proof of concept code when I am writing docs. Due to the nature of services my team owns, I am by default thinking of burst traffic, and outage scenarios. This exercise has helped me make numerous decisions.
• Lastly, its useful to think about the tenets of a system and thinking about the overall product when taking decisions. For example, making a change in your monitoring service to reduce some false positives but which in hindsight would also alter your ability to gauge real customer experience. In this example, it would have been useful to think about the "tenet" of a monitoring service.

First, let me commend you on your awareness.

This is a great starting point.

As Alex and others have mentioned below, start with compiling your questions where you fumbled, find patterns, and proactively prepare some questions that may come your way.

An additional step would be to check with your peers/seniors/manager and do some prep, if possible, before the demos.

Observing what questions are being asked to other members during their demos and how they answer would provide good learning too.