A couple of years ago my business partner and I were setting off to build a new product and needed a core team that would have the ability to grow over time. Building a technical team can be time-consuming, expensive, and is easily messed up. One way to overcome these core challenges is to hire new graduates from code schools and coding boot camps. Cultivating junior talent has its own set of challenges, but it can also help grow the engineering team if done correctly. A team made up of great people, that will contribute to the company's long-term success while creating lower overall costs and turnover.
Three Sections
The problem.
The solution
Feedback from our engineering team who went through this.
The Problem
Recruiters, internal or external, can be cost-prohibitive. For undercapitalized or bootstrapped companies, this is not an option. For those companies that can afford recruiters, the long-term effects of having someone paid to fill roles can lead to having teammates that are less mission-driven and more financially driven. Those types of teams can end up being fickle, inconsistent, and more vulnerable to turnover.
Referrals from team members are a great way to get started, but they depend on the core team’s network. If the team is mostly junior, then their networks are small, and their referrals might not carry much weight. If your team is more seasoned, then their contacts are typically more senior, making finding junior staff difficult.
3. Public job listings are great to get a long list of applicants, but then the real task is filtering. This is where most problems in the hiring process occur. You spend all your time sifting through applicants only to end up hiring the wrong person.
The Solution
Hire code school graduates and put them through a thoughtful and thorough process. Here is what to do and what to keep in mind.
Connect with local code schools.
Most cities have a mix of code schools, coding boot camps, and events they are connected to. In our case, we found Epicodus here in Portland, and they connected us with two software developers.
In addition to playing matchmaker for their graduates and hiring companies, code schools also typically have internship programs. To participate in those internship programs, you simply let the school know what you are building, how you are making it (the technology stack), what’s going to be built next, and what type of junior developer you are looking for.
Offer paid internships or short term contracts.
We onboarded two new graduates for a trial period as 1099 contractors.
Regardless of whether it’s an internship, a trial period, or a short-term contract these new team members need to be paid. This is the moral approach, but there are also regulations around the type of work that can be a part of an unpaid internship. You do not want “free” work to come back to haunt you later on.
"If you pay peanuts, you get monkeys" - James Goldsmith
Bring on more than you expect you need.
Don’t go on a hiring spree, but if you need one full-time junior engineer, bring on more if they are coming out of a code school. Be clear about your needs and the fact that it isn’t likely that all will become involved full-time. Also, let them know that no matter the outcome you are offering to help them learn.
"Have no more than 1 junior engineer for every 3 to 5 senior engineers" - Jim Snowden
We brought on two developers from code school, knowing we likely needed more than one full-time developer, but we weren’t sure. For those first 3-9 months, the code school grads productivity will be below a typical ‘Junior’ engineer so over-subscribing the position helps fill the gap in the engineering team and gives them both time to feel things out without sensing massive pressure.
Give them self-contained tasks that are needed but not critical.
Newly minted software developers need clearly defined self-contained tasks. An example would be an integration with Facebook for user authorization. This is a very well-documented API, with many example applications to reference. Even if these types of tasks took twice as long, it was still saving us money compared to having our senior engineers do the same work.
If you can have a few of these types of tasks ready right when a junior engineer joins, it allows them to dive in without an abundance of direction or oversight.
Allow for struggles, questions, and even failure.
There is are no expectation these new hires will be great coders. They are bound to encounter lots of challenges right out of the gate. The important part is to look for developers who take initiative, are willing to struggle, wanted to do the research, and ask pointed questions.
The desire to learn and do a crappy first pass is key. If they aren’t taking that step themselves now, then it probably won’t work out for them in an early-stage company. They either need to continue learning or go work in a large corporation where they can specialize and learn slowly.
If they struggle but keep working and have good communication that is all you can ask for early on. Encourage it! Both of our new team members were great at working hard to get something done, then ask key questions about how to make it better, and in the rare instance they were stuck we could dive in and help.
Focus on how much effort they put in, how communicative they are, and how quickly they improve. But make sure they do not over-work.
We noticed that there were some days that they both came into the office looking tired. You could tell they were working late. You can’t ask people to live like that, you have to correct them to only work billable and reasonable hours since that isn’t fair. However, the instinct to work hard and power through problems is good.
“It is a common experience that a problem difficult at night is resolved in the morning after the committee of sleep has worked on it.” - John Steinbeck
Encourage them to get a full night sleep, so that they can come in the next morning with a fresh perspective to tackle the problem. They need to understand that the goal is not for them to complete that task at all costs, but rather the goal is for them to understand the process, learn, and grow. Things learned tired often slip away.
Hire as many that show the key traits of effort and desire to work.
We hired them both after their initial period because we saw lots of potential and because we still had plenty of work for them both to do at that point. It is very easy to justify the expense when you have time to work with them and see their true value.
There is no requirement that you have them become full time, salaried, and benefit receiving employees. You can offer an extension to their trial contract, a modification to their contract, or offer them something completely new, but that is absolutely up to you and them to define.
Regardless of how their employment continues, talk to them about their options, where they stand with the company, and what their future might look like. You are giving them an education about their new career so take it seriously.
Continue their education.
This can be through internal mentorship, support sessions, and even external tutoring if needed.
Jim, my business partner, has lots of experience mentoring software engineers. It is a blessing to have that kind of person in-house. If you don’t have someone capable and willing to do so then get help or this might be too challenging. We also look to Jim to learn new languages and prototype new systems so he is very up to speed on all the newest technology, this continual learning makes him a great educator for newly minted developers.
To support these new employees Jim designed a curriculum for a senior engineer to take them through once a week, for 1 - 2 hours a session, teaching them design patterns, algorithms, data structures, and other advanced concepts he knew they wouldn't have gotten in a coding boot camp. This went on for 6 - 8 weeks.
The time they were with the tutor they were not paid because the company was paying for the tutor and they were not working during those hours. Giving them the time in their normal workday to meet with their tutor, telling them not to do long and late hours, helped them succeed and made them happier and more productive teammates. This kind of investment and care goes a long way to build trust.
Continue to offer more challenging work.
One new teammate started gravitating towards iOS development so we encouraged him and started giving him that work. Soon, he was given a majority of the feature development for our iOS application.
It is surprising how much can get done if everyone supports each other, understands many different disciplines, and lets those who want to learn a new skill try it on live projects. It creates happiness and stability throughout the team. Unhappy teams get broken up, become slow, or produce bad work.
Provide incremental wage increases each time they increase their capabilities and become more efficient.
Both of these new teammates likely wouldn’t have even mentioned money for the first year or two, but as their skill and contribution increased we proactively increased their pay.
Don’t worry about a set-in-stone salary increase schedule, but rather do it proactively and build trust since you are paying what they are worth, not what they are negotiating.
When you do increase their wages you need to explain that you are doing this in relation to the value they are providing. This is also a great time to highlight how your company's compensation plan, benefits, and other defining qualities measure against different opportunities.
If someone is losing desire, or their effort slips, speak up early and often.
This career is all new to them and it may be a lot for them to take from a personal standpoint. You are there to help them become a great team member.
There are endless combinations of reasons why a teammate doesn’t work out. If they don’t want to be there, or if it’s just not a great fit, then working with them to modify the role is always the first step.
In the end, if it still isn’t working well then ending the relationship and moving on, before the relationship goes sour, is best.
If they want to explore other opportunities, take time off, work on other projects, or even leave, it is important to encourage them and find ways to support them in doing so.
This is the right thing to do, they are early in their careers as engineers and this is your responsibility at the start.
“Variety is the very spice of life, That gives it all its flavor” - William Cowper
When junior employees know they have every option and support no matter what they do they will respect the team, respect the company, work incredibly hard, and speak well to others that are potential employees, partners, investors, and clients.
Keep very strong communication, not just between them and their team leaders but the entire company at all levels.
These new teammates have a new skill in an industry that is foreign to them, you need to encourage them to learn about all the various moving parts of your company and give them some time to explore.
Part of the way we did this was to invite them to listen in on discussions, have small information sessions between senior folks in open earshot of them and do one on one sessions.
Opening up the door to see other roles helps them better contribute but also to see if there are other things they might be good at or want to try out. This coding skill and experience can help them no matter where they end up in an organization.
Stay connected after they leave.
I discussed this with my current team and some colleagues, this might be the hardest lesson learned. Take it as a job for the entire team to stay connected to those that leave, especially those that were great contributors.
Feedback from the team
Jim, a senior engineer with 30+ years of experience who has hired more than 10 code school graduates in recent years using this process.
Q: What is the most important thing for companies to keep in mind when deciding to bring on a code school graduate?
A: Most code school graduates are from other career paths. These folks do not have Computer Science core teachings one gets at a University, or any real experience, so it is up to the company to bring them up to speed if they expect them to be fully functioning engineers. Algorithms, design patterns, data structures, development methodologies like Agile, etc… We set up custom curriculums for each set of grads to help kickstart their careers and their productivity within our projects.
Q: For those directly managing these new employees, what advice would you give them?
A: Honestly, sifting through lots of folks to find the gems like Ben :). Expect to do lots of mentoring, and have them coworking in the same space (or find a way to keep them in close communication) with mentors to make it work. Have things very well structured and requirements defined for the first 6 months or so. Do trial periods! Have them do lots of code cleanup, bugs, etc like any new Engineer coming into the system to start. Expect very little output from internships.
Q: What is one thing you are going to do differently for this next, incoming, code school graduate?
A: Have no more than 1 junior engineer for every 3 to 5 engineers.
Q: Any resources (readings, articles, etc.) you would recommend to companies as they make this decision and work with these code school graduates?
A: Look at curriculums in college today, condense material down to a boot camp, then stretch that out over many weeks so that <20% of their time is dedicated to it. Alternatively, reach out and we can help.
Ben, a graduate of Epicodus, who went through the above process, and is now the lead engineer on multiple projects. He inspired this article.
Q: What is the most important thing for companies to know when making the decision to hire code school graduates?
A: The company should have experienced staff that will work closely on the same projects as the new code school hires. They will need a lot of guidance. Know what to look for in an interview with a code school graduate. This is a person who might not have had any prior programming knowledge only 6 months ago. They will have a good understanding of what they learned in code school, but that might be it. An employer should be looking for someone who can easily translate their experiences in one tech stack or language to another and has an understanding of how design patterns can be applied in different situations.
Q: What advice would you give to new, code school graduates, as they take on their first paid position?
A: As a recent code school graduate, you should prioritize the environment that you will be entering more than anything. Does the new job provide a multitude of mentors that you can learn from? Is there ample free time to do some learning on the job? Will you be working on things that interest you? Your personal development is what both you and your employer should prioritize initially because that will bring the greatest return for you both and is an important part of keeping motivated. Once you find a position be sure to ask for help if you don’t understand something. Realize that you will often face difficult problems but you will become more confident over time in handling them.
Q: Is there anything you would do differently if you were to do it all over again?
A: I would spend more time working on well-developed side projects to show my understanding of core programming concepts. Even better would have been to develop projects with multiple other people.
Are you ready to grow your team? If so, take our advice and work with eager novice developers, help them grow into competent engineers, watch them surpass all your expectations, and find new friends in the process.
If you want to learn more about our journey, or need help navigating your own, please reach out to us. We are here to help!
YourFriends@H3Pros.com