Overview

Recently I’ve started onboarding Junior Full Stack devs using a beginner Project. Here is why I made that change, as well as what the project consists of and its outcomes

What we did before, and why change?

Before I explore why I’m now using this as an onboarding method I’ll explain what we were doing before. Throwing them into the beep end. That’s not something I’d recommend but traditionally we would spend a day going over the company, the next day going over some of the technology we are currently implementing. Getting them access to all the repos and tools and then saying “go and explore”.

To a mid or senior level developer I’d say this is a good way of getting them up to speed with our tech stack. But for a junior developer it’s not really feasible. They normally do not know where to look, or even what to look for. They don’t know where to start or how to get started.

Now, you could sit them with an experienced developer to go over everything, but that can be cumbersome, time consuming and maybe not as beneficial as you think.

This is where I came up with the idea of the “Starter Project” idea to get them up and running, writing code, pushing to git, thinking about deployment etc etc.

There are a couple of other reasons as to why to do a project like this:

  • It’s fun!
  • It matches the learning they might of done in coding bootcamps
  • It provides a little bit of a structured path of learning
  • It provides a simplified introduction into our technology stack

What stack do we use?

It is worth mentioning the stack I want them to learn.

Here is a list of the technologies (and tooling) we are using for our customer facing web applications:

  • C#/.NET
  • Angular
  • MongoDB
  • GCP
  • Docker/Kubernetes
  • Bitbucket
  • Jira

What do I want them working on?

I assign them a project that they can work on for 1 month. They can use any libraries inside those stacks that they are comfortable with. But the general idea is for them to learn at least a similar way of building things as to what we are doing currently.

Timelines

  • Onboard / Welcome to the Company (introductions with team leads etc)
  • Links to all documentation / e learning providers etc
  • Project Handout (email) - Template Provided (ChatGPT / Ollama generated)
  • Freedom to build as they require or what they want to focus on
  • Daily / Bi-daily catch-ups with the team leads to check progress / answer any questions
  • 4 week mark we do a presentation with just one developer and the leads to do feedback
  • Get them onto normal work from there on.

The (actual) Project Brief

Overview

Simplistically I’d like to see an e-commerce Backend API in C# .NET. MongoDB and Angular as a frontend.

Features

  • User Registration and Login
  • Product Listing (with Angular frontend)
  • Product Details Page (with Angular frontend)
  • Cart Management (add/remove products, calculate total)

Database

Use MongoDB to store user data, product information, and cart details.

Technical Requirements

Frontend: Build the application using Angular. Backend: Use C# .NET to create REST APIs for CRUD operations on products, users, and carts. Database: Design a MongoDB schema to store relevant data.

Learning Goals

  • Implement user authentication and authorization
  • Use Angular components to build reusable UI elements
  • Handle cart management and calculate totals
  • Design a MongoDB schema for the application

Deliverables

  • A fully functional E-commerce application with all features implemented
  • Code documentation (README files, comments in code)
  • Database schema design (MongoDB)

Things not mentioned in text

There are a couple of things that we conveyed verbally for this project. Mostly around CI/CD and source control. Basically it boils down to “we want to be able to deploy our code to a server”. We also wanted to use Bitbucket as our source control system, so we can see who did what and when, as well as getting you to learn our Pull Request Processes

Benefits for the business

What the business gets back from this can be a bit unclear, as the developers are not working on road-map items it can be seen as a bit of a waste of time. However, I believe that setting the juniors up with a achievable learning task that we can use to review their strengths and weaknesses is vital to a successful on-boarding experience.

The business therefore saves a bit of time in hand holding onto road-map items. Save time by progressively setting up with systems (git, CI/CD, Jira etc) rather than all at once as we are setting up as they get there in the project.

This project also provides a bit of a hands off upskilling of the tech stack, without having to closely watch the developers to make sure nothing breaks we ease them into the processes.

Because of the presentation (where the developer will present their solutions) we can also see how they go in a public speaking environment. This is really critical early on to see how they go in groups of people they don’t know.

What have been some responses from the team?

There was (and will always be) valuable insights from the team who went through this project as their onboarding.

One of the common themes that arose was that around support. One thing I tried to do is give the developers free reign on how to build (apart from the tech guidelines) and then give them contacts on who to reach out to if they needed the support. However, what you will always find, is that junior are nervous about reaching out to senior developers. This meant that the optics from the juniors is that there was not enough support available. So that is something to solve.

Another piece of valuable insights was around timelines, I have to remember that a junior has not worked on enough to be able to say “I have 4 months, i need to allocate X time on Frontend and X time on backend”. This meant that a couple of our initial projects were a bit half baked in some features, providing guidance around when to call it a day and move on to the next task is going to be critical.

The last small point that was worth taking away is making sure that the juniors who are going through this process together communicate. This was designed not as a competition but as an upskilling exercise. So getting the juniors to talk and go over issues and solutions would of been beneficial to all involved.

Conclusion

At the end of the day this new process has been successful. Although we have not had quite enough usage to not refine it further.

There are a number of changes we can make with the process for each new batch of developers that we need to onboard. Making sure that the exercise is tailored to the current batch is vital. We can also use it to build out some internal tooling which is lacking in the businesses.

All in all, this has been a success and I now want to roll it out to more of our technology group as a whole.