Heading into 2017, forecasters estimated 45,000 software jobs would go unfulfilled in the Puget Sound region due to a dearth of talent. In Washington State, where our headquarters is located, hiring for tech workers (developers, testers, Project Managers, analysts, and systems engineers) is challenging at best, and exasperating at worst.  Location is a premium, and next to Silicon Valley, there is no hotter spot to be a developer than Seattle in 2017. Amazon is consuming talent at a voracious rate; Microsoft, Expedia, and Boeing are always local heavyweights. And now Valley giants like Facebook, Google and Apple are muscling in to open “remote dev centers” in our backyard.

“Come work for us at Base2!” we implore candidates – we’re a multiple “Best Place to Work” finalist, our benefits are competitive, and you’ll work on cool projects. Frequently the answer we get is, “Base Who?”

Given the intense demand, how does a software and systems engineering consulting firm like ours grow our talent pool in such a competitive landscape? The solution was easy (we’re engineers!): just analyze the problem and you’ll quickly identify the solution. In the classic technology business case analysis of “Build vs Buy,” we opted to build and made the decision to round out our team with folks from Code Schools. But, a nagging concern lingered:  “How do we make them successful?”

Within the quiet confines of our Base2 Solutions office lounge, we pondered this question intently before deciding to take the plunge. What should be our expectation of their dev skills? Can we ask them to design and implement a method, an object graph, a function, a UI? What might the introduction of this new “class” of technologists do to the culture that we’ve worked so hard to build and fiercely preserve?

We first dipped our proverbial toe in the Remote Distance Learning program from Oregon State University (OSU). They offer a 1-4 year, self-paced, online Computer Science B.S. for folks who already have a first degree in any subject. We ultimately hired one of our first interns from their program. She was a second career grad with an abundance of talent, energy and a strong willingness to learn. We paired her up with one of our principal engineers, and gave her the task of designing and coding an internal project, then presenting it to the leadership group at the end of the summer. She proved to be such a great find, that we offered her a job at the end of her stint, and she graciously accepted. Then, she introduced us to two of her “study group” friends who were also looking for jobs. They, too, were second career folks: one was a classical pianist, the other a former Marine Corps officer.

As a company with a certified process for developing software for regulated industries (think FAA), it took a while to inculcate them to our nefarious ways, but their patience, maturity, and eagerness to explore new technologies seemed to smooth their transition from turbulent to laminar flow, and they became successful Base2 developers.

We decided to take the next step and explore candidates from Code Schools by participating in the WTIA Draft Day. We interviewed many candidates, brought four of them back to our office for deeper-dive discussions, and eventually put out offers to all of them. To our delight, three of them accepted. It has been nearly a year since the three started working at Base2. Anne Bly, a Sr Recruiter for Base2, said, “All of them are glad to have chosen their paths. Draft Day is model that works well for Base2. Not a lot of time to handhold new hires. It’s great for companies that have limited resources because most of the coding school grads have had work experience before. It’s a fabulous program as long as you can dedicate time to do some mentoring. Base2 is agile based so they could fit in a lot of learning in a short amount of time for the hires.”

As one of them shared with me, “In code school we were so hyper focused on our stack – all we did day in and day out was work with one language – so when you finished, you felt pretty confident in your ability to work with it. However, not having spent a lot of time looking into other languages, initially made applying general programming knowledge to other stacks a little difficult.” We recognized that they are skilled coders, in that they learned how to code primarily in a single language such as JavaScript Python, but being a developer on a project is so much more than that. To be an engineer and developer, one must know design tools and documentation, be fully integrated into the team, work within new frameworks and evolving paradigms (Clojure!), conform to a workflow process and methodology, and also be able to solve problems and debug issues.

We realized that we needed to put tooling in place to help both them and the business be more productive faster. Here’s what we evolved over time to try and help them fit in to the Base2 culture.

1. To Have a Mentor You Have to Be a Mentor

For us, “Paying it Forward” is reaping long term dividends. Everyone needs someone to turn to when we are in a new space. The experience with our erstwhile intern-turned-engineer revealed the power of two, and motivated us to pair-up our newbies with an old hand. What we’ve discovered is that over time, as the newbies get folded in, they are willing and anxious to also teach others who come behind them.

Another recent code school grad shared that her mentors “… support me in improving as a coder but also provide insight into working in a consulting environment. My experience approaching anyone at Base2 for help has been generally very positive.”

2. Find Your Passport Yet?

To work at a consulting firm, it’s helpful to know more than just your own little project, as we do much more than just software development. So we created a passport program for new folks. Each person meets with their lead, who assigns them a passport or guide book that lists individuals in the business they need to meet (like the Office Manager, A Systems Engineer, and the CEO, for instance) or processes they need to go learn (you crusty Old Salts should harken back to your PQS days). As they find someone to explain it to them, they get a line item signed-off in their passport booklet. There’s no quiz at the end; only new contacts and connection in the office, and more awareness of what we do.

3. Check-In Early and Often

Although that’s the paradigm for developing code, it’s also important that any mentoring relationship have regular opportunities for connection. Find a reason to go get coffee, meet up for lunch, or just do a drive-by check in with your new teammate. This frequent contact does a few things: it helps them stay connected to you, it helps you give them guidance on resources they can find to learn and grow, and it provides you an early warning if their role in a project is going off the rails.

4. Have a Willingness to Try – and Succeed – or Fail.

Create an environment that fosters curiosity.

As Samantha recently shared, “Base2 has created a very inclusive culture. There is a general understanding that at some point everyone was new to the industry and that everyone, even developers who have been programming for years, will have questions. You can ask anyone anything and you will usually find someone who is willing to help you and give you a thorough answer. In my experience people aren’t also afraid to speak up if they see you doing something inefficient or incorrect – they will often show you a new way to do something, or explain how they are doing it. Base2 also made it OK to fail or make a mistake and encouraged you to try something even if it wasn’t the ‘best’ way to do something. That kind of thought process really helps you learn and helps you not make the same mistake twice.”

5. Language – It’s Not Just for Programmers

Donevan, a Principal Engineer and Team Lead, quickly realized when he was mentoring one of our new team mates that he and she did not speak the same language. He was using terminology that made total sense to him, but she would look at him sideways. Ping? Grok? PR? Repo? Dependency Injection? Even worse, they did not grasp language that was specific to aviation, our more prominent industry vertical.

To be inclusive, it’s important to realize that these folks are new to your world. You should be willing to explain the lingo in a non-threatening way that helps them grow. Be patient; their mastery of the lingo and the technology will happen.

6. Teach an Old Dog New Tricks

Every one of our Code School grads are second (and third) career engineers. One is a mother who successfully launched her last kid and wanted to re-enter the workplace. They have a depth of maturity, a wealth of life experience, and are very capable of learning new languages, O/Ss, frameworks, paradigms and tooling – something that is emphasized by the Code Schools. Challenge them to explore those opportunities and you will find that they are more likely than fresh college grads to come up-to-speed quickly.

Some teams self-organized a lunchtime book club to learn new languages or become better programmers. A perennial favorite is The Clean Coder by “Uncle Bob” Martin.

So, what did we learn from this grand adventure?

• Take a calculated risk. Do your due-diligence during the interview process and your homework with references. But also recognize that a failed “Stump the Chump” whiteboard session during an interview doesn’t mean that they are not qualified; it’s likely that they are just inexperienced. They know what they know; it’s your job to teach them the rest.
• Hire for aptitude not core knowledge. Languages and technologies can be learned; attitude cannot.  We try to flesh out how well, quickly and willing they are to expand their repertoire of skills. The ones with activities beyond just coding (such as playing Rugby, performing Taiko drumming, or presenting at women’s conferences) tend to make better consultants.
• Code Schools helped Base2 increase our gender diversity. We have hired more than twice as many women as men from the programs.
• Second Career candidates tend to be more mature. We try to hire developers who can grow into consultants. Being able to code is just one slice of the pie: can they communicate with the team and eventually the customer? Are they open to feedback? Do they play well with others? Are they open and honest? Almost to a person, the answer is “yes.”

Good luck – and be sure share your own experiences in the comments.