Taro Logo
15

How to be an expert in details?

Profile picture
Associate Member of Technical Staff at Taro Community10 days ago

Hi Taro Community,

Often times during presentations/demos and other informal calls, I have seen myself being stumbled by questions related to my work that I am unable to answer. The questions seem simple, and I have often felt in retrospect that these are things one ought to have known, or spotted beforehand. I feel there needs to be a modification in the way I approach a problem/bug/user story assigned to me. Does anyone have any tips on how to be more detail oriented and have a holistic view of whatever it is that one is working on? How to approach the work items assigned in a way that one is extremely clear with the basic stuff?

293
9

Discussion

(9 comments)
  • 8
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    10 days ago

    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:

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

    • 1
      Profile picture
      Thoughtful Tarodactyl
      Taro Community
      10 days ago

      Highly agree with this. It helps to write it out properly. After I fumble I immediately go through and update my notion doc with details that I should have had in mind.

      Also it helps to just play devils advocate when you prepare. Write out your experience and then poke hole in it

    • 0
      Profile picture
      Associate Member of Technical Staff [OP]
      Taro Community
      10 days ago

      Thank you for the detailed response! For more specific examples:

      1. Its mostly around theoretical understanding of the problem, for example, I was working on a problem related to anomaly detection in databases, and 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.
      2. As a second instance, I was working on a project for which I picked a particular library to use and I was asked to defend why I did not use the other open-source libraries instead. Questions around how what you are doing/proposing is different than what has already been done? (In terms of tooling design)
      3. I was working on some DevOps related stuff, and felt less confident on my knowledge around Kubernetes and AWS. For some of the commands I had been using, I was not very clear what exactly was happening in the background once they are executed --> for example, what exactly are credentials being passed for, what is a particular terraform file doing, what processes does deploying to an environment trigger, how are pods spun up, etc.

      I understand these are all things that can be read up on the internet, my issue is with not being able to anticipate the details I should be clear on. Its only when someone raises a question that I realise I might need to read up more on it.

    • 0
      Profile picture
      Tech Lead @ Robinhood, Meta, Course Hero
      5 days ago

      As a second instance, I was working on a project for which I picked a particular library to use and I was asked to defend why I did not use the other open-source libraries instead.

      So this one is relatively easy to prevent, especially given that you used an open-source library. In general, it's good to come up with 2+ approaches to a problem. Strive to do that in the future, and you'll be fine.

      For #1 and #3, these are trickier and I don't even think they were real problems:

      1. If everyone should know what a model is, why did you get asked what it was? It seems like the person asking also didn't know (unless they were randomly quizzing you, which is weird).
      2. For the DevOps example, there's nothing inherently wrong with not knowing what's going on underneath. A lot of the time, unwrapping the abstraction isn't necessary to doing your job. For example, I've done Android development for 11 years, and I don't really know how Gradle builds the Android binary (because this is knowledge that doesn't help me do my job better).

      You should only unwrap abstractions if they're meaningful towards helping you do the job. The good news is that this is generally pretty obvious when it happens as you will face a problem. For example, early on I realized that the lists I built in Android were quite laggy. In order to debug, I had to read through and thoroughly understand what view recycling was. This is core logic that every Android product engineer needs to understand (and I've failed many interview candidates over this).

      Here's another great thread to read through: "How to avoid going down the rabbit holes when learning new things?"

  • 7
    Profile picture
    Eng @ Taro
    10 days ago

    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?
    • 0
      Profile picture
      Associate Member of Technical Staff [OP]
      Taro Community
      10 days ago

      That is a very helpful advice, thank you! Will surely try to categorise the questions into buckets like these.

  • 4
    Profile picture
    Senior Software Engineer [SDE 3] at Amazon
    9 days ago
    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.
  • 1
    Profile picture
    Senior Manager at SAP
    7 days ago

    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.

  • 1
    Profile picture
    Software Engineer
    6 days ago

    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.