Despite a shortage of software developers, entry-level developers can tell you that it is difficult to get hired. Companies are often reluctant to hire entry-level developers for several reasons that include:
- They don’t want the risk that an entry-level developer may not have the skills to do the job.
- They don’t want to invest in bringing an entry-level developer up to speed and then see the developer go to work for another company.
- They don’t want to pay for the time it takes for entry-level developers to become producers instead of costs.
- They don’t want to lose productivity of current staff devoting their time to bring entry-level developers up to speed.
Development teams also find it challenging to provide tasks for entry-level developers to work on because there are so many things an entry-level needs to understand before doing any coding. A lot of that is the processes surrounding coding and how those processes are performed in the organization. Below is a list of items that many companies want developers to understand. Often only the coding items were part of the training the developers received in school. Companies want a developer that:
- knows what IDE to use, how to install it, open it, update it, and be productive with it,
- understands the technologies used by their app in order to get things done:
- The code language, UI language, data stores, best practices, frameworks, and IDE,
- knows how to test their code locally,
- knows how to commit code changes to a repository and update from a repository,
- knows how to use repository tools to review other code and find code changes,
- can write unit tests,
- can start and run unit tests locally,
- proceeds cautiously at first, not checking in changes without being certain,
- will not check in code changes to the production pipeline accidentally,
- understands there is a build process, and be able to run a build on their own,
- understands the process of how their changes get deployed or used,
- understands there is a production build and how to initiate it,
- understands there is a way to deploy for QA/Test (maybe),
- understands they may be able to deploy directly to production,
- can find the task management system that has the list of tasks and features and bugs they are to work on,
- can manage their own tasks on the task boards,
- knows who to talk to for any task requirements as well as task priority and also if the task is right/ready for them to handle,
- tracks their time – how much are they spending on each task,
- can assess what is a priority, or who to ask to get that answer,
- understands the business domain and what the software “does”,
- understands the development priorities (security or performance or maintainability or customer satisfaction or just functional),
- follows the patterns already in use in the code for solving problems,
- knows how to use our Requirements and Design tools and processes,
- gets to work on time,
- is focused on their work during working hours,
- is eager to learn,
- is friendly with everyone.
When a company commits some time to building a good onboarding process for new developers, they can greatly facilitate the onboarding process and make it less difficult to hire an entry-level developer.
- Create documents and videos of the applications the developer will be working on
- Create documents and videos of your software development processes
- Assign each new developer a contact person they can go to for any question. If you are hiring several developers, ideally each contact person will serve that role for just a single new developer. Also, the contact person should be someone on the same team that is very accessible to the new employee.
- Schedule some one on one time for each new developer with each team member. Often, you can use this time for an existing team member to share knowledge about the company and software with the new developer.
- Prepare their computer, physical environment, and computer software before they arrive for their first day. Make sure the application software, and unit tests if applicable, can run successfully on their computer. Have all of their security accounts ready for use.
- Have mentors reserve time to spend with new developers almost each day for the first two weeks. Don’t just hope to “squeeze it in” as needed.
- Remind existing team members to contact the new developer(s) when they are about to perform a task or process that the new developer needs to learn so the new developer can join them as they go through it.
- Put off some simple fixes/enhancements on your task board for a few weeks to reserve them for the new developers to do. Give the new developers a chance to commit a real code change on their first day.
- Finally, create an onboarding checklist with links to videos and documentation about each item on the checklist.
Here is an example of an onboarding checklist in a google document: https://docs.google.com/document/d/1K5jw1OgQDbLiXt9UvLR9Qnm5Pj9fWj-brp6_FiTUWJw/edit?usp=sharing
If you want a faster start for your own onboarding checklist, I recommend you make a copy of this Trello board and customize it for your own company: https://trello.com/b/h9eTMg4E/onboarding
The way I recommend using this Trello board, is to make a column on it for each new hire. Each employee can work their way down the board, marking items done on checklists and changing the “Labels” on a card when it is completed. Many items on this board anticipate that a mentor will work with the new employee to discuss the item (cards with the “Mentor” label). Other cards have a label named “Complete Independently”. Of course there is still a lot of work for you to do in preparing documentation and customizing the board for your own development shop, but hopefully this helps you get started.
Rob Kraft's Software Development Blog 