I’ve been encouraging and getting the company I work for to hire more early career developers, bootcamp grads, people from non-traditional, non-computer science backgrounds. There’s a shortage of senior engineers, but a glut of early career devs in the hiring market now.
But why hire early career devs? Typical resistance takes the form that it takes too long to train new programmers, takes away time spent on new features for seniors, and you can’t train developers remotely. Well, that’s just not true.
Why “Early Career” Rather than “Junior” is important
There are a few reasons why I refer to people as early career developers rather than junior developers:
- “Junior” can have negative connotations: The word “junior” can sometimes be interpreted as meaning less experienced, less skilled, or less competent. By contrast, “early career” emphasizes that the individual is at an early stage in their professional development, rather than implying any deficit in their abilities.
- “Early career” is more inclusive: Not all early career developers are in their first job or have only a short period of experience. Some may have been working in the field for a few years, but are still considered early in their career. Using the term “early career” can be more inclusive of a wider range of experience levels.
- “Early career” is more accurate: Often, “junior” is used to refer to entry-level positions or roles that require minimal experience. However, this may not always be accurate or appropriate. For example, an individual who has been working in the field for several years but is still considered early in their career may not be considered a “junior” in the traditional sense.
Using the term “early career” rather than “junior” can be more respectful and accurate, and can help to avoid any negative connotations or misunderstandings.
When interviewing early career developers, there are several traits that I look for:
- Collaboration Skills: Development work often involves collaboration with other team members, so it’s important for early career developers to be able to work effectively with others. Seek candidates who are good at communicating, listening, and working as part of a team.
- Adaptability: As technology and industry practices change over time, it’s essential for early career developers to be able to adapt and learn new skills as needed. Search for candidates who are open to learning and who can quickly pick up new technologies and methods.
- Balance: Look for someone that can handle “juggling multiple balls in the air”. Working at corporations means meetings. Countless meetings. It can be hard to carve out focus time. Honestly, here is where I might have a bias for people that have been parents, or leaders in the military, healthcare, or something similar where the situation can get chaotic and emotional quickly. Not exclusively, but it’s usually a good sign.
- Technical skills. I purposely put this last because, although there has to be a satisfactory level, it’s not the most important thing to wow a senior developer.
In a large organization, Consistency, communication, and a growth mindset beat raw talent. Consistency is indispensable because it allows them to build on their natural abilities and to maintain high levels of performance over time. Effective communication is essential for building and maintaining relationships, collaborating with others, and achieving goals. It allows individuals to share their ideas, insights, and perspectives, and to work together towards a common goal. A growth mindset is essential because it allows them to be open to learning new things and to be resilient in the face of challenges. It motivates individuals to improve and to seek opportunities for growth and development.
How to do the technical challenge
While, of course, you have to screen people who can’t “code their way out of a paper bag”, hopefully your recruiters have done that for you.
Here are some tips:
- Approach it collaboratively. Open with how you will work together with the candidate, and possibly an anecdote about how you once were in their situation.
- Allow googling. Be honest, you Google and StackOverflow stuff all the time. You’ll see if they are wholesale copying and pasting. Hopefully, your challenge is unique enough to avoid that situation
- Don’t let them get too stuck or nervous. There will be plenty of opportunities for them to demonstrate their communication and technical skills.
- Time-box the challenge. Being on display is exhausting, for the interviewer and the interviewee.
- Sell the company! When hiring programmers, it’s almost always a competitive situation. You’re going to be working with this person. If you like them, tell them what you enjoy about working where you do.
Onboarding is the process of introducing new team members to an organization and helping them to become productive and effective in their role. Having a good onboarding process helps dial in the whole development process. Faster onboarding for mid-and senior developers. Better documentation. Better abstractions and architecture in the code. All things that accelerate feature development and reduce technical debt.
By providing new hires with the resources and support they need to get up to speed quickly, organizations can reduce the time it takes for them to become fully productive. This is especially important for mid- and senior-level developers, who are expected to contribute to the development process right away.
Effective onboarding can also help to improve the overall quality of the codebase by providing new hires with a clear understanding of the organization’s coding standards and practices. This can help to ensure that code is well-organized, maintainable, and scalable, which can help to reduce technical debt and improve the efficiency of the development process.
Good documentation can be an essential part of the onboarding process. By providing new hires with access to clear, comprehensive documentation, organizations can help them to understand the organization’s processes and systems more quickly, which can save time and reduce the risk of errors or misunderstandings.
A good onboarding process can help to accelerate feature development, reduce technical debt, and improve the efficiency and effectiveness of the development team.
There are a number of mentoring strategies that I have found useful over my years of experience. What is mentoring?
Mentoring is a relationship in which a more experienced or knowledgeable person, called a mentor, helps to guide and support the development of a less experienced or knowledgeable person, called a mentee. Mentoring can take many forms, but at its core, it involves the mentor providing guidance, support, and advice to the mentee as they work towards achieving their goals and developing new skills.
Mentoring relationships can be informal, with the mentor and mentee meeting on an as-needed basis to discuss specific issues or challenges. They can also be more formal, with structured meetings and a defined plan for the mentee’s development.
Mentoring can be a valuable experience for both the mentor and the mentee. The mentor has the opportunity to share their knowledge and experience, and to help shape the development of a new generation of professionals. The mentee, on the other hand, benefits from the guidance and support of a more experienced individual, and has the opportunity to learn from their mentor’s successes and mistakes. It can be a powerful tool for personal and professional growth and development.
I’ll outline several mentoring strategies below:
The grasshopper method
The Grasshopper method is a learning strategy that involves breaking a complex task or concept into smaller, more manageable pieces and tackling them one at a time.
The grasshopper is known for its ability to jump from one place to another. The method is often used in programming or other fields where there is a lot of information to learn, and it can be overwhelming to try to take it all in at once.
The Grasshopper method involves identifying the essential concepts or skills that are necessary to complete a task or understand a concept, and then breaking them down into smaller pieces that can be learned and practiced separately. By focusing on one piece at a time, it can be easier to absorb and retain the information, and eventually, all the pieces can be brought together to form a complete understanding of the task or concept.
The Grasshopper method can be an effective way to learn new material, especially when there is a lot of information to absorb, and it can be difficult to know where to start. It can also be helpful for learners who prefer to work through material incrementally, rather than trying to take on everything at once.
The grasshopper method can be useful in developing and sequencing a list of onboarding tasks, and be combined with the other methods below.
Pair Programming and Code Reviews
Pair programming is working together. Sitting down and banging out some code on a shared screen. Taking breaks to talk about anything but work. Getting to know someone. It’s the shortcut to team building, building relationships one by one without the pressure of a meeting.
Code reviews are not my favorite activity. I sometimes wonder what to say. It’s an impostor syndrome moment. Did I miss an error? What happens if I do, how embarrassed will I be? The truth is, if you’ve hired well, most code is good. If something leaps out at you, positive or negative, say it. But the best thing to do if you have read it and understand it, and have nothing to say is to approve it, to keep work going.
However, like all imposter syndrome events, your input is actually critical at the early career developer stage. Things that you think are “nits” or nitpicking might be well needed feedback to the early career developer. Just make sure to say they are not show stoppers and are purely style or educational oriented. A former mentee of mine said:
From my vantage point those small nuances are some of the gold that more Senior Engineers have learned in their years of experience that I am just starting to embark upon. One day I will have those ‘nits’ to share with early career devs, and the cycle of improving code will continue.
Occasionally, a quick check in over chat or 1:1 zoom can surface questions that would not otherwise come out in other work contexts. Positive feedback from peers is critical at this stage to alleviate impostor syndrome in early career programmers.
You can hire early career software developers
Regardless of your position, with the strategies above, you can be an integral part of hiring early career developers. It’s an important step for equity and diversity in our profession, and can give your company a hiring edge over the competition when effective policies and practices are in place.
How to get started? Share this article with your peers and your manager, and see what discussions arise. Let me know what you do in the comments here, please. I’d look forward to seeing more early career developers being hired.