Coding School Graduates and Market Saturation

Coding schools abound these days, and there are now a proliferation of schools designed to handle many backgrounds, aspirations, and cost models. Most people who aspire to be a software engineer today can find a place to learn, and with some work, can find a job. But what happens as the market becomes more and more saturated with coding school graduates?

Differentiation for a Naïve Market

Today, coding schools attempt to differentiate themselves for the sake of their graduates ability to get positions, or choose to opt out of that metric entirely. Everyone wants to be the "Harvard of Hack Schools", or the main supplier of diversity candidates. These methods of differentiation are a bandaid that addresses the question "will our graduates be able to get jobs" with the answer "of course, because they are different than other schools' graduates".

The market for new, junior software engineers today has a cap. As junior engineers mature into mid and higher level developers, leave the industry, found companies and make lateral moves, turnover keeps positions for junior developers open. However, junior engineers are (locally, in silicon valley at least) being produced at a faster rate than those positions are being created. No amount of amazing programs or creative, inspiring teachers can produce candidates that can enter a senior position without the experience they need. So what do we do? Turn down the throttle on junior developer production? We can't very well do that, as we're in a "baby boom" period in software - this happened in the last bubble, and when it burst we had homeless engineers and a mass exodus towards the midwest, where smaller, less well paid, semi-stable jobs awaited.

The market for junior engineers looks a lot like the western logging and mining efforts that ravaged our natural resources last century. There's wealth out there, and the market is going to reach for it. Asking people to produce less, strive less, and leave opportunity on the table is unrealistic and unfair. Fortunately, "replanting" and "conservation" efforts need not be as slow coming, nor as painful for the industry.

An Educated Market Is Bigger

I believe the answer is in preparing the market to receive and contribute to the rapid growth, and success, of candidates produced by coding schools. Recently I wrote about onboarding junior developers, and efforts to this end will help companies capitalize on a talent pipeline that will only grow larger and more sophisticated as time wears on, as well as stabilize the exit point of this pipeline for junior talent. 

However, the onus is not solely on companies to provide stellar onboarding experiences. It lies on both the community, in providing stable, encouraging mentorship, and on the coding schools themselves. Coding schools can offer many things to graduates, from career counseling services to ongoing education in order to make their skills not just broad, but relevant to their specific employer. The biggest thing they can do is spend time educating companies on how to best use their graduates. 

Coding schools teach widely different things, which create a thousand different vocabularies around what junior developers have learned. Some teach the Twelve Factor App, some teach MVC religiously as though it is the only programming paradigm that works. Some teach as agnostically as possible, leaving students to navigate and assert the usefulness of different technologies on their own. These different ideas and paradigms produce diverse candidates that can navigate the spectrum of the market's needs, but what they don't often realize is that their messaging around their curriculum is often the entry point of understanding that companies have about a candidate. You can say "we taught them Python, and how MVC webapps are built", and that sets a company up with both expectations, and explains what still needs to be taught. 

Schools should standardize not their curriculum, but the language that describes the approaches they take, as well as what students can say that they know upon leaving. This doesn't need to be controlled by a committee or ruled by bureaucracy, but can simply be defined by communicating clearly what "they know Javascript" means. does it mean they can manipulate the DOM? Do they understand prototypal inheritance? A good breakdown of what exercises were done, what concepts are covered, and what proficiency means to the school itself can prepare a company for a candidate on the interview side, and once they've begun working. 

Most coding schools have "partner companies", with which they enter both a monetary, but also a trust arrangement. This arrangement means usually that schools receive a recruiting fee, and get first access to graduates, improving chances of a match. The arrangement benefits the school and often is the reason they can keep their doors open. The arrangement only marginally benefits the company, however, and often does not benefit the candidate other than by doing a mass of introductions, and gives them an idea about what kind of company they might like to work for.

I encourage coding schools to prepare material that can help the onboarding process easier for candidates. Sharing the broad curriculum with partner companies, and educationally-minded suggestions about on the job training based on how their students are prepared during the program will help graduates be more successful, helps partner companies hire more and more effectively, and further solidifies the ideals encapsulated in the term "partner".


I'm available for consulting work in this area, and the next few months of my life I'm going to be collecting a series of case studies to test the point that an educated market is better for everyone. If you're interested in providing a case study, or interested in consulting, drop me a line at lizTheDeveloper@gmail.com.