As a senior engineer or a technical lead you need to be there for your colleagues from mentoring to helping them out with obscure problems. If done right it can make your team a lot more productive, can help your career by showing management that you are an effective leader and is generally rewarding. If done wrong it will harm your productivity and spoil junior colleagues by creating dependence behaviour.
The way it works is that the more you know, the more people come to you, and the more you are open, the more people come to you. So if you're a great programmer and you love to share your knowledge then you can end up creating problems for yourself because of the constant interruption from colleagues and this ultimately can make you end up being more closed and not sharing knowledge because you get so frustrated.
So how to get it right? First of all don't stop being open, being open is vitally important especially if you're a team lead. Your team needs it, your organisation needs it and it will help your own career in the future. There is a single powerful sentence which you can employ when a junior comes to you with a problem:
“Explain to me the steps you have taken to figure this out on your own”
This sentence has magical properties and can literally make a colleague stop, turn around and go back to their desk and do what they should have done in the first place – try and solve the problem by themselves first. The first time that a junior hears this sentence it often stops them in their tracks because they haven't done anything, not even a Google search, and they admit they did nothing. So you then tell them to go back and investigate it by themselves and if they still can't figure out to come back and you would be happy to help but it is very important that they do something first. Colleagues soon learn that this is your first response and that you better come prepared with the steps you have taken. I am not a free service that can be used whenever it takes your fancy. I work hard to cultivate a culture of respect for other’s time and a culture of openness and collaboration. The fastest way to ruin that culture is to let it be abused.
The better juniors don't ever seem to have this problem, they seem to innately understand that you are not a free resource and they genuinely enjoy investigating things by themselves and are hungry for knowledge - they are independently minded people. However some developers are not so independent and if left unchecked they will develop a dependence problem on the senior colleagues and create conflict within the team. Depending on the team, sometimes bitching can sprout because the senior colleagues get fed up with their time being wasted by a junior that consistently asks without trying themselves first or asks similar questions consistently and is unable to learn from the advice of the senior colleagues. This then becomes a problem for the technical lead and/or line manager because they have a people problem in their team.
So the key is from day one making it clear that juniors must investigate first and also they must make notes so that they don't come back with the same or a very similar question two or more times. If I receive the same question from the same developer and it is not super complex then I have words with them and tell them that they need to make notes so that they don't need to come and ask me or a colleague again.
It's all about setting boundaries, when juniors understand the boundaries and that within those boundaries there is freedom and openness to seek help from senior colleagues then everyone benefits. Juniors grow and become more productive and seniors are able to mentor in a positive way, in a way they can enjoy and get benefit from and the whole thing is sustainable.