Pragmatic approach to onboard new hire
Imagine, you hired a new engineer to help with your software products, or you are an engineer who just got hired. What would be your expectation? Being productive, as soon as possible, right?
I am an engineer, worked in different software company for last 10 years, conducted tons of interviews, helped company hire and onboard new-hires. Here are some notes on good and bad onboarding ideas.
Good Ideas:
- Business Analyst / Product Owner talk about the products.
- Architect / Developer talks about architecture, explain how different parts of the product are connected.
- Set a ‘buddy’ for the new-hire.
- A dedicated person to help the new-hire.
- This will prevent bouncing from person-to-person to get simple things done.
- A ‘buddy’ is not a mentor.
- Duties of a ‘buddy’:
- Answer/help with anything new-hire might need.
- Help with getting access to Code Repository / Artifact Repository / Build System / AWS etc.
- Setup meetings with different people who can explain things to new-hire.
- Show the codebase.
- Explain how CI/CD process works in the company.
- Help to run project on the local machine.
- Help to pick up small ticket, help the new-hire as much possible. Merge the code and test! This might seems hand holding, but trust me it works.
- Tips for the person who play to the ‘buddy’ role:
- Try to write down the overview of different talks. Send the overview as a chat message after the talk.
- List all links, e.g. codebase, Sonar, Jenkins, Artifactory.
Bad Ideas:
- Week long boring training session.
- “Just read the code, you’ll figure it out. It’s just code.”
- Ask to Read the Fu**ing Manual (RTFM), aka Confluence / Wiki / readme pages.
Live long and prosper!