[dnadler]

I have a similar mindset though less focused on the type of questions being asked and more about how many times I have to answer the same question.

Ideally, the number is one time. As in one conversation where the person walks away understanding the answer. If I have to have that conversation more than once it’s a problem.

Obviously there’s nuance - it can take time to get your head around a new concept or hard problem. But in any case, I like that as one dimension when thinking about a person’s skill/level/potential.

[joshstrange]

> I have a similar mindset though less focused on the type of questions being asked and more about how many times I have to answer the same question.

Yes, I completely agree and do that as well.

The focus on “type of question” has been something I’ve done more recently after helping someone out. Just reflecting on “what type of problem did I just help solve and how can I make it easier for them to solve on their own in the future”. Very often the answer is “more documentation” or similar, getting things only in my head down where everyone can benefit. On the other hand I walk away from some problems I’ve helped with frustrated that the answer was 1-2 Google searches away and the issue had nothing to do with “our stack”.

[maccard]

I mostly agree with you, but there’s another angle that is similar. How many times does the person come to you with a similar question but on a slightly different topic and you need to guide them through _how to find_ the answer. I’ve supervised mid level engineers in the past who will just drop a stack trace in a slack DM and expect me to tell them what’s wrong - I didn’t write the code so why do you expect me to figure it out for you. But when I have the conversation of “we’ve talked about how to dxooore these kinds of problems a few times now, next time you need to apply these techniques”,it often doesn’t land.