I’ve been in meetings as a Sr. Staff SWE where the expectation was that I could provide guidance and direction for projects using tools, architectures, or stacks that I’ve not used extensively… or at all. In those cases, I try to make it clear where I’m not confident in my knowledge and ask questions designed to uncover what I need to know to do my job.
I’ve learned to do that even in areas where I’m almost completely inexperienced. For example - I’ve never worked with Java and Spring Boot, but I’ve worked with the JVM and many application frameworks in other contexts, so I’d ask questions to help me understand the strengths and weaknesses of those tools, with a focus on areas where I’ve found friction in other projects with similar architectures.
I’m also always worried that I’m “taking over the meeting”, and every couple of rounds of questions I pause and explicitly ask if I should continue to investigate or take it offline and come back with findings.
I’ve been in meetings as a Sr. Staff SWE where the expectation was that I could provide guidance and direction for projects using tools, architectures, or stacks that I’ve not used extensively… or at all. In those cases, I try to make it clear where I’m not confident in my knowledge and ask questions designed to uncover what I need to know to do my job.
I’ve learned to do that even in areas where I’m almost completely inexperienced. For example - I’ve never worked with Java and Spring Boot, but I’ve worked with the JVM and many application frameworks in other contexts, so I’d ask questions to help me understand the strengths and weaknesses of those tools, with a focus on areas where I’ve found friction in other projects with similar architectures.
I’m also always worried that I’m “taking over the meeting”, and every couple of rounds of questions I pause and explicitly ask if I should continue to investigate or take it offline and come back with findings.