But why?

Despite having more people joining the software engineering field every year, the software industry has seen a decrease in open positions for junior engineers. Everyone wants to get the most senior engineer out there, one that can hit the ground running and start coding everything in their first week.

The reason for that is due to the median tenure becoming lower and the market is divided into company payment tiers. Engineers can get a higher compensation moving into a techier company after a few years, and unless you are Google or a FAANG top dog, your engineer will eventually leave you in the hiring loop once again.

Companies don't want to train people if they feel they will leave anyway, so they hire only seniors on a team to provide value faster. The problem is that with more seniors, fewer are opportunities for them to practice their communication skills, and more are mundane tasks for them to build and faster they will be leaving.

The top three reasons that people leave are: not learning on their job, the job is not exciting, and lack of a career path. Having junior engineers on a team helps fight these problems because it allows seniors to develop soft skills such as mentoring, communication, and achieving alignment.

Hiring juniors

While junior engineer knows how to code and build simple apps, they don't have much if any real company experience so traditional resume screenings won't tell much about their success in a job, they probably will have done one internship or a bigger project in college, and they probably won't be descriptive with that either.

Screening for potential and motivation

With juniors, their resume is more of a generic page, the first step for hiring them is screening resumes for things that make them outstanding, this includes but is not limited to:

• Checking their GitHub projects/portfolio
• Proficiency in English (non-English speaking countries)
• The projects they attach to resumes, and accomplishments

But this won't tell as much, so we need also to change the interview.

Interviewing:

Take Homes

For senior engineers, doing take-home exercises is the quickest way to kill your hiring pipeline, they generally won't have time to do mundane tasks outside of their work, but in my experience juniors are motivated and up for the challenge.

A good way to avoid people dropping out of the pipeline is announcing before proposing that feedback will be given for completed assignments, most people give up on doing take-homes because they don't receive feedback, or they get ghosted.

A take-home also allows the opportunity for developing skills, first junior I hired submitted his Android project that was above and beyond other candidates. We asked how many years he had had with Android and he said that his knowledge was the 4 hours of tutorials he watched while doing the test, this was a great positive signal.

Some examples of take-home tests:

• (Front-end and mobile) Consume from a public API, display the results list, and then the details (like a bookstore, or any other marketplace).
• (Data) Parse from a data log, and create structured data from it. For example, a game kills feed data, with semi-structured events.
• (Full-stack) Create an API for a marketplace, a simple admin CRUD with a front-end.

Keep in mind that this applies to juniors, not interns, it is presumed that the junior already knows how to code, even if they can't architect larger systems, for example, if they are a full-stack they should at least know how to build a simple backend API.

Explain what things you are most interested in for the candidate, so they can know what to prioritize, which is also an important skill. Tell whether you like them to do tests, solid documentation, or solid design.

Evaluating

Rate candidates from the points mentioned above, if in the delivery they show proficiency but the project lacks refinement, it is worth moving forward anyway. Some people just don't have much free time, I recommend interviewing all of those that were rated more than 60% and thanks the others, giving them feedback before moving on.

Technical Interview areas to assess

Coding:

To prove they did the code, we can their code from the take-home and have them create another (and quick) feature on top of it. Better yet, if possible, tell them to remove a feature they coded. If they cheated in the take home you will notice that they will struggle even with a simple change.

Questions:

• If you had more time, what would you add to this project?
• If you were in charge of making money from this product, what requirements would you change?

Motivation

The most important thing to screen during the interview is to see if they are motivated to engage in problems and resolve them. It is important to see what drives to keep the interest in learning, which they will need to do.

Questions:

• Why did decide to become a software developer?
• What did you learn to complete this project?
• What are you excited to learn right now?
• What project did you do (even in college) that you are most proud of?
• Follow up on the previous question: Why? What was the most exciting / hardest part about it?

Onboarding and mentoring juniors

If you made it this far, congratulations on the new hire!

The first thing needed is setting the pace, junior engineers are not used to working in a team. It is necessary to set clear expectations for their deliverables weekly until they can set them without help.

If you fail to set expectations that the engineer will think the slack they got during their onboard is the same as what will be required daily, just don't handle lots of docs and tell "read this, then do that", most of them don't have the maturity of bootstrapping context on their own. Have some quick but trackable tasks to measure their pacing and growth.

Assign a buddy for them, ideally, the most chill senior engineer that you have, you will end up learning that they will be great partners for a long time in the company, reaching out to a manager as a junior is very scary, but reaching out to a peer in "the trenches" is way easier.

Forward and onwards:

Junior for mid-level is a faster promotion than mid to senior, you want to see they achieving these competencies:

• They can understand the particularities of the systems and their limitations
• They will start to see areas of improvement in the existing architecture
• They will be able to create technical specifications on how features will be built
• They can get technical alignment among the members of the team
• When they display experience in the process that the software is built from concept until production: agile rituals, development process, estimations, and timeline. Architecture, code style, PRs / reviews, deployment, and monitoring.

Most people will leave after 2 years because they will get bombarded by recruiters with better offers. It's also necessary to keep updating the salary to their value.

Junior engineers are the best culture carrier of the company, all their professional experience they have is with the company that hired them. While the seniors are rightly more skeptical because they were burned before, juniors think of the company people as friends, so they are well worth keeping investing in and proving them right.