* Set clear expectations ahead of time. For example, when NicoJuicy says "Filter those that don't ask the same things 2x-3x", if you decide to take that advice

* Set clear expectations ahead of time. For example, when NicoJuicy says "Filter those that don't ask the same things 2x-3x", if you decide to take that advice then you should be clear with them "When you ask me a question and I answer it, I expect you to both write down the answer in a place where you can retrieve it for yourself and to ask follow-up questions to ensure you understand it." If you are afraid to hide your expectations because they sound harsh to you, then reflect on how stressful it is to know that you are expected to do well but to not have direction. * Make a learning plan alongside them. You have a much better ability to curate resources that are relevant to your toolset than they do. * Help them learn what makes a good question. Question-asking is a real skill and since they are fresh grads they might not have it. Julia Evans has some good writing on this[1][2] * Expand the menu of questions that they know they can ask. For instance, it might not occur to them to ask you for 45 minutes of time on your calendar in order to walk through the structure, interaction flows, or major data models of the project. * Be wary of asking them for estimates. Estimating software timelines is a hard skill. I've seen multiple new managers ask a junior dev for an estimate, receive "I don't know" in response, and then pressure the junior dev into lying. That sets up a communication roadblock. If you want to work with them on doing the task-breakdown required for an estimate, that can help as a means to teach estimation. > comfortably work with beginners Why is it a requirement to do so comfortably? Doing things that you are not yet skilled at is both uncomfortable and necessary to grow. It seems to me that you'd want ability to identify situations where discomfort is necessary and to tolerate discomfort. For instance, you might decide to try programming-out-loud with them. Here, you tell them to grab notebooks and you book a conference room with a projector. Then, pick a ticket and you talk through your whole process of investigating, breaking down, planning your approach, reading through the relevant code, writing tests, refactoring, and writing code to solve the ticket. This could very well be uncomfortable for you to do and it will likely be uncomfortable for them to stop you mid-thought and ask you to explain something they didn't understand. Does that discomfort mean you shouldn't do it? Only you can answer that, but you should probably call out this discomfort explicitly and say you're going to work through it and you expect them to work through their discomfort. [1] https://jvns.ca/blog/good-questions/ https://jvns.ca/blog/good-questions/ [2] https://jvns.ca/blog/answer-questions-well/ https://jvns.ca/blog/answer-questions-well/