“What do you do?” or “What does your startup do?” are tired questions in San Francisco, a city where you are measured by your works. The superficial startup ideas, the digital smugness, and the unnatural culture of tech celebrity are sometimes enough to make you want to throw your smartphone into the ocean and dive in after it. Go away from San Francisco for a while though, and you’ll start to remember the thing that drew you in the first place. You remember that, beneath the fads and clumsy attempts of first-time entrepreneurs, lives a city of dreamers and doers defying cynics and conventional wisdom.
Our dream is to create a modern school for engineers to attend throughout their career. Even more audaciously, we want to offer this school for free. Various experiences have led us down this path: our experience as founders exposed us to the pains of hiring, and our experience as engineers gave us the aspiration to be lifelong learners. We believe we can connect the dots and create a better solution for both.
A founder’s perspective
A founder really only has two critical roles: company direction and hiring. A common mantra in the startup world is, “execution is everything”, and, ultimately, it is the team that must execute the vision. Founders often share the trait of being control freaks, so letting go of that control is one of first challenges that they will face. That doesn’t mean letting the company run amuck because setting company direction and expectations is the second role of a founder. I don’t have any sympathy for founders that gripe about their team. All I see is a founder that has failed in their only job.
Unfortunately, hiring is brutally hard. Referral is still the best way to hire, and when that well runs dry, the options are not good. Sometimes, I felt the only thing we could do was watch the months slip by as we tried job boards, contingency recruiters, in-house recruiters, engineering speed dating, engineering auctioning, and any number of ridiculous things.
I find it incredible that large companies use talent acquisition as a major strategy in hiring. I understand how it happens though, when you have executives staring at quarterly hiring targets. Acquisition is probably the only way to expedite the hiring process, so you’re left to solve the challenge of hammering together engineers from different company cultures into a cohesive team. To me, though, that’s like panning for gold when you can build a gold factory instead.
In fact, there is a vast supply of engineers. Engineers who are talented, humble, and eager to learn and contribute. Why, then, do companies drool over Ivy league new graduates whose only experience is school projects when there is this other pool of talent available? At the end of the day, it’s about risk. A big part of hiring is mitigating risk and most experienced engineers don’t have “clean” resumes. Does too many years at the same company mean a lack of initiative? Does too few years mean they are flighty? Also, their technical experience almost certainly doesn’t completely intersect with the tech stack your company is using, so how quickly can they ramp up?
At the end of the day, I can understand the justification for passing on many of these people. Companies avoid risk in hiring so much that one veto amongst six interviews is enough to disqualify a candidate. This is troubling, however, as we have all been in that candidate’s shoes. At some point in our career, a hiring manager or investor took a risk on us, perhaps despite our previous experience, and maybe that was just the opportunity that we needed. In the happiest stories, we went on to be very successful for the company, justifying the risk. Unfortunately, the stories often don’t have happy endings, which causes companies to write off a large number of candidates.
We believe we can change that and broaden the candidate pool beyond those that fit a narrow description. Our school is the perfect environment for individuals to demonstrate initiative and the ability to master new skills quickly. Imagine companies bringing interesting projects to the class or challenges like Google’s Summer of Code. Opportunities to collaborate are opportunities to build trust, and trust is the thing that makes referral based hiring so much better than traditional recruiting. I would have gladly exchanged my many hours spent interviewing with time spent mentoring, probably with more productive results. Properly executed, the school could recycle an endless supply of qualified engineers back to grateful companies.
An engineer’s perspective
The only constant is change, and there’s no truer statement in engineering. An engineer’s career is composed of “learning” years and “plateau” years. It’s deadly to stay too long in the “plateau” years. As a result, professional engineers are accustomed to, and take pride in, frequent self-teaching. It’s a good thing that engineers enjoy self-teaching because it’s the only option available currently. It’s certainly not very practical or efficient to go back to college or even get a graduate degree, and community college and other continuing education programs are no match for modern technology. Instead, you’re left sifting through a thousand different eager voices on the internet, most of whom got something working, but also don’t really know what they’re talking about. You sit there, like some kind of technology archeologist, painstakingly piecing together which APIs were thoughtfully designed and which were some historical remnant. Imagine learning how to be a blacksmith by walking into an empty smithy with nothing but a handful of StackOverflow posts. Maybe possible, but very slow.
On the flip side, think back to some of your more fruitful “learning” years. They are probably characterized by two things: a substantial challenge and a significant mentor. In engineering, there are trivial challenges and there are interesting challenges, but both are time consuming for a newcomer. For example, debugging a well-known library issue can take as much time as designing a clever caching strategy. Mentors streamline the trivial challenges by filling in the communal tribal knowledge. Of course, reference texts are also great resources, but by being comprehensive, important nuggets are lost in a sea of trivia. Lack of mentorship breeds great inefficiencies, and this is made obvious when one observes technologists today praising “recent” advances that are simply rediscovered concepts pioneered decades ago.
We believe that our school brings the same advantages as structured mentorship, and allows engineers to challenge themselves throughout their career. Interestingly, it also brings about another important advantage. Collaboration with like-minded peers is so rewarding that it can keep a team together long after the product or engineering challenge loses its luster. However, if you’ve ever tried to chase that feeling by meeting random engineers at a beer-fueled engineering meetup, you’ve probably been disappointed. A learning environment is infinitely more effective at building meaningful collaborative relationships. The relationships may be its own end, may lead to professional collaboration, or may lead to your next cofounder.
When we founded CodePath, we wanted to build it on several principles. First and foremost is the standard for excellence. We want to attract the best and that requires the highest quality classes. Second, classes are project-based because engineering is best learned by doing. Third, projects are built in groups because engineering is not a solo activity in industry. To us, product, design, and collaboration are as much a part of engineering as libraries and frameworks, especially in a startup.
Making the classes free is a risky decision. There’s no such thing as a free lunch, and that will make engineers wary of low quality or some kind of catch, so that’s an impression we’ll have to overcome. When we set out to build this school, we were determined to build a school that we would attend ourselves. As a student, I don’t have thousands to spend on classes every year. As long as we can prove that we can train engineers to a certain standard, there’s money on the table from startups and big companies alike.
We’ve already been using our curriculum in corporate training for the past several months, and we’re excited to bring the classes to other engineers. Are you interested? Apply for our iOS evening bootcamp or our Android evening bootcamp. These initial bootcamps are targeted towards experienced developers interested in iOS and Android. If you would like to mentor a group, email us at firstname.lastname@example.org.
Follow us @thecodepath or join our mailing list for updates.