Software Engineer Onboarding Tips that Nobody Tells You About

What You Should Know Before Joining, and While Working for, a New Company

Photo by Denise Bossarte on Unsplash

Introduction

I put together this article to help new software engineers, as well as those moving from one company to another, make the transition into a new role as smooth as possible.

Before Joining a New Company

You will have a good idea of the technologies being used at your next company from the interview(s). However, some things you’ll end up using on a daily basis might be underemphasized in either the interview stage or in the job description.

Examples could include:

• Continuous integration and delivery of software.
• Project management software e.g. JIRA, Azure Boards.
• Specific libraries, such as Angular NgRx for Angular developers.

It’s good practice to clarify these things with your next line manager before your first day, asking what preparation steps would be beneficial. From there, you can work out what tutorials you should follow.

After Joining

Onboarding Checklist

In your first week, you’ll have a number of actions to complete, such as raising tickets to get various permissions sorted. You’ll need to track the progress of each of these actions.

I’d strongly recommend creating a spreadsheet (or agile board, if you prefer) with two columns:

• The first column should be the Name of the action.
• The second column should be Notes.

Each new line in the spreadsheet will track the progress of a specific action.

You can change the color of each Name cell to indicate its progress.

For example:

• Start each cell with yellow.
• Change to green once completed.
• Mark red if there’s a blocker.

In the Notes column, add links to things like links permissions tickets, as well as details about actions that are blocked. This way, when your line manager asks for an update, you can simply refer to your spreadsheet.

Remember also that some instructions will be given to you verbally, and it's important to add actions for these too into your spreadsheet.

Bookmarks Organisation

Having your browser bookmarks organized will make not only your onboarding process smoother but will make you faster at resolving issues.

Here are some folders you should add to your browser’s bookmarks bar:

• Website links (Dev, QA, UAT, Prod), as well as subfolders to the current and previous versions of software.
• Source control links, with subfolders for specific projects and versions.
• Links to current and previous sprint boards.
• Continuous integration and deployment links.
• API endpoint links e.g. Swagger.
• Server links with descriptions to help identify what it’s used for where appropriate e.g. “XYZ123 — Team 1 UAT”
• Links to check the health of the websites, API endpoints, and message queue endpoints.
• Helpdesk links to check for dealing with known production issues, and documentation links about how to transfer the phones / other helpdesk rota protocols.
• Utility websites e.g. for JSON formatting (check with your company what is approved for use).
• Links to team wiki documentation, with specific links to frequently referenced pages e.g. “Steps to Deploy XYZ”.
• HR links for registering holidays and sicknesses, as well as for expense reimbursement.
• Links for office-related tasks, such as checking which hot-desk seat you should be sitting in today, or how to book a conference room. Also, make sure to bookmark the out-of-hours contacts list and place your team’s mobile/cell numbers into your phone.

Over time, you should also consider adding:

• Links to previous pull requests that can assist you when completing a similar task e.g. adding and unit testing a new Angular route. This should ideally be placed in the team Wiki for the team to use, so consider speaking with your team about adding a page for that.
• Links to help resolve code or IDE issues e.g. Stackoverflow comments about how to resolve a particular build error.
• Any database query software links, as well as commonly run SQL queries.
• Links to IDE shortcuts — particularly the top ten most commonly used shortcuts that will help improve your efficiency with writing code.

Some teams will also use software such as Postman to save commonly run queries against APIs. You should create a shared API workspace (as named in the case of Postman) if it doesn’t exist to save any frustration when it comes to smoke-testing APIs.

Finally, quite often newcomers will get stuck and a colleague will have a handy command line string to resolve the problem. Consider copying and pasting these into the team’s wiki if it’s not already there. From experience, this can save a huge amount of time and trouble!

Websites and Workflows

Before delving into the code, you should try to get a good understanding of the business logic. Take the initiative to book time with different people for demos of the software. While every company has training (or should do), you are also responsible for your own learning.

Ask yourself the following questions during your probationary period:

• What are the functions of different parts of your application?
• What permissions do you need to view certain pages and perform particular tasks?
• Where is the administrative part of your application e.g. for performing cache cleaning.
• What scheduled tasks and services run and at what times?
• What happens when a workflow fails — can it be re-run, and if so, how?
• Are there important calculations going on, and if so, do I understand how a change in one figure affects another?
• Are you hearing unfamiliar business vocabulary or acronyms? If so, note these down somewhere and ask a colleague to explain what it means at the earliest possible opportunity.

Database

If there are lots of database tables, particularly legacy ones, you’ll need to prioritize your learning.

I recommend starting with going over the top ten, say, most commonly used tables are for.

Ask yourself:

• How are tables linked by foreign keys to other tables?
• What is the structure of the data held?
• Where is the data in tables reflected on your website?

Code

Now you have an understanding of the website, workflows, and database, it's time to delve into the code.

My advice is as follows:

• Ask yourself how the code connects the website and workflows with the database.
• Find out the most commonly used dependencies by reading class constructors for injected classes — these classes will be very important to look into further.
• Examine the configuration files and carefully understand how these are set up for specific environments.
• Check for any commonly used calls (or attributes) in classes and methods, such as calls to verify if a user can access a resource.
• Check conventions for how code is properly documented.
• Check the steps needed before raising a pull request for code changes, and have them documented in the team wiki if not already there.
• Note down any code / unit test built-in classes and take tutorials on these areas to make things easier for you at work e.g. Java Streams.

Helpdesk

Often, software developers have helpdesk rotas to resolve production issues.

Ask yourself:

• Where is the documentation about how to properly process a production ticket?
• What link takes me to the helpdesk wiki, where I can search for how to deal with issues?
• Do I have enough understanding of the workflows in order to diagnose between which two points there has been a failure?
• From checking previous helpdesk emails, who do I go to for production issues between two points in a workflow (and are these contacts documented in the helpdesk wiki)?

And for company-wide tech support helpdesks:

• Take note of how to raise a support ticket e.g. if VPN login appears broken.
• Add links to help you raise an application installation request or license for something.

Emails, Documents, and Presentations

Soft skills can get you far, and a lot can be learned by keeping your eyes and ears open.

Some things you should do:

• Listen to how an experienced colleague does a presentation.
• Read email exchanges that highlight good examples of how to seek agreement between two parties.
• Check a presentation attached to an email that could be a template for you should you need to deliver a presentation in the future.

Thanks for reading! Let me know what you think in the comments section below, and don’t forget to subscribe. 👍