Ditto. I'm still pondering how working with junior folks might work. In-office teams _may_ be able to absorb and level-up more junior people.
Would love to spitball ideas on this with anyone else interested in that topic.
It isn't that difficult to do remotely. But some people just don't like it in general.
That said we are trying to bring in more junior engineers via our internship program: https://about.gitlab.com/handbook/engineering/internships/
If our internship pilot is successful we hope that this will be a feasible way to bring in more junior engineers.
- Setting up your environment is scary. For a new junior hire, you must have someone responsible for helping the junior dev set up their machine. Someone patient and non-judgemental. Documentation must be unambiguous, really step-by-step, without assuming anything about what the dev should know already. Getting to the point when I could run a project on my computer without any issue is a big deal.
- Junior developers need a safe space to ask dumb questions. In the office, I would stand up and go ask a senior developer. From meetings and conversations, I could identify the ones that were more open to answering very basic questions in a non-judgemental way. These were the ones on your team and others who took the time to come present themselves to me, show interest in you and your background, and explicitly say that I could go to them and ask for help if needed. For some people, this is natural to do in-person. But I have the impression that those same people wouldn't do that as spontaneously in a remote environment. This should be encouraged. Tell senior developers from other teams, to go and make this intro and offer for help in individual channels, not just a formal message on the public channel. Go into a DM and make sure the junior dev is comfortable with messaging that developer with "dumb" questions any time.
- To the point above really work, your team must have senior developers that are patient, non-judgemental, and willing to help junior developers. Not just the ones in the junior dev's team, but a few others in other teams too. This is true for in-office too, but worth saying. In my first job, I could go to 4 or 5 senior frontend developers from all over the company to answer my noobie questions. That was ideal. I could rotate the ones that I would interrupt, I could try to identify the one that it was in a better position for me to interrupt, I could have different styles of explanations from different people, I could ask something that I had already asked, but forgot, only to a different developer so I wouldn't look stupid or annoying.
Some very knowledgeable developers are great discussing complex problems of software architecture, but the moment a junior dev asks why they are getting a weird error when running a project without realizing that they just forgot to do "npm install" they just think "I don't have time for this shit" and it shows.
There is such a thing as a junior dev asking too many questions too fast (without proper research on their own), but a junior dev should never feel afraid of asking. Make them comfortable to ask anything first, and only if they start incurring in this behavior of asking too much without trying on their own, you give this feedback so they can improve.
- Code Reviews are essential for junior developers. In this case, almost nothing changes by being remote. Just remember that code review of junior devs should include an education part. Explanations, code samples, links to resources, clarifications of terms. Things that would sound patronizing to senior developers are fundamental to junior devs. Err on the side of explaining too much. Some code reviews require more clarification than what's written on the review. So make sure a junior dev being reviewed is comfortable in DMing the person who reviewed for clarification and guidance.
- DMing itself might be an issue. I know remote teams encourage all discussions to be on open channels, so the knowledge is not siloed. But junior devs really need a private line for clarifications without exposing themselves too much. It is easier to ask dumb questions in a private message.
- Lastly, I do think regular junior devs (who are also young and inexperienced, not just technically junior like myself) need closer management. At each beginning of the day, it must be clear what are the tasks to be done; at each end of the day, it should be written what was done. It can be done in a way that is not micromanagement, but it is much easier for a junior to be lost, and that leads to being unproductive. Procrastination might come from confusion, not just time management.
Also, get suspicious of a junior dev going too quiet. A senior dev might disappear from communications for a whole three days and come back with a very well-done and researched PR. A junior dev doing that will probably come back in three days and say, "I am not sure if it is that what you wanted... but I did this." And it was a totally different thing. They just lost three days googling weird error messages, reading tutorials, copy/pasting stack overflow answers, only to learn they were doing something that was not what was asked. Check junior devs work every day. Of course, it requires management skills to don't do it in a condescending or micromanaging ways.
"Documentation must be unambiguous, really step-by-step, without assuming anything about what the dev should know already" this will just about never happen. Documentation always lags. You have to be able to connect some dots sometimes.