The acclimation process as a new engineer may be daunting for some. And since I’ve been through the process myself, I’d like to share these tidbits to help you - as the mentor - help out your mentee.
Writing my own documentation specific to the project and tech. It helps the junior engineer get acclimated to the context they will be working in and gives them a bigger picture of what’s going on. Things like specific Slack channels, email lists to join, repositories to download, helpful software additions, et cetera.
Forwarding them to the right people. Introductions or forwarding them names of the people they will need info from (example: a web engineer needing information from the backend engineer).
Don’t assume that they know! I err on the side of giving as much information as possible to a new engineer so that they understand the full context. If they already know, great - but still, it’s good to check-in beforehand to see what they know.
Share your tips that you know and use often. If you know a shortcut for a workflow, or how to debug more easily, share that with the engineer! I had to discover a lot of shortcuts on my own (sifting through Slack channels for example) and had to waste countless hours when someone else had a simple command for it.
Keep internal company-only acronyms to a minimum. Business jargon may confuse newcomers, so lighten up on that. There’s been countless times I’ve been in meetings with new hires and they have no clue what is going on due to acronym usage.
Open up the floor. I want my mentee to feel as comfortable as possible coming to me with questions. If I don’t know, I’ll ask someone else or forward them to the right person. As someone that had a challenging case of impostor syndrome, this one could have a profound effect on newly minted engineers.
A major component to mentoring, overall, is to be communicative. Although it may feel like more effort to explain or give additional context, it is likely appreciated by the mentee, and can save a lot of unneeded frustration.
Have any other additions to the list? Feel free to comment your own!
Top comments (5)
Have you ever encounter junior who really learn slow and repeat mistakes? If yes, how did you deal with that?
Hi Pawel, good question. Yes, I have encountered a junior who needed more time to understand.
Generally if the person repeats the same mistakes, that means:
For 1, leaving "fix it" improvement comments on their pull requests enough times usually helps the junior understand that there is a standard/quality, or that "this is how it is done". In my experience juniors will remember and understand after 2 or 3 times. (It could take more times.)
For 2, that might be of a conversation with the junior and why they repeat that same "mistake". Perhaps the engineer believes their implementation is the correct way. Then at that time, the more senior developer can explain why or why not, and have a discussion.
In general I would also ask the junior, "What is your learning style?", as one method of learning may not work for another. For example, many like to start a project by writing as many notes as possible and reading through the entire codebase. Other people learn by writing code immediately, using APIs, becoming familiar with the project by trial and error.
I would encourage more senior developers to take time to understand and communicate with juniors. I think that would solve a lot of problems. With patience and reinforcement, junior engineers should understand eventually.
Thanks for sharing these tips ☺️ Lauren
Thank you for reading Paul
Awesome article!