Stop gatekeeping tech jobs with superfluous CS degree requirements

A couple weeks ago, I wrote about the Sphinx guarding the gate of Thebes and devouring all would-be visitors who could not solve its riddle as a metaphor for decoding SRE job listings. (I still don’t understand why the Thebans did not just build a second gate on the other side of the city, but whatever.)

There’s another, more prevalent, form of gatekeeping common in many types of software engineering job listings and hiring requirements, however: CS degrees.

First, let’s address the fact that many listings have that requirement to make the role eligible for H-1B visa applicants in the US. If that’s why you (the hiring manager, recruiter, etc.) have that requirement, I understand, but even if you accept that a degree may not be a hard requirement for the role and you would have no problem hiring the “right person,” whether or not they have one, you also need to realize that having this “requirement” in your published job description will likely repel otherwise qualified candidates, especially in groups already underrepresented in tech. (If that sounds actually like a bonus to you, just stop reading now because you need to fuck off posthaste.)

But let’s talk about that requirement outside the scope of enabling visa sponsorship.

Without even discussing the extreme variation in curricula and requirements from CS degrees at various universities even within the US, not to mention abroad, the vast majority of jobs in the tech industry are not for “computer scientists.” They are software engineering jobs. Can aspects of CS be applied in those jobs? Of course. But most software engineers are not applying deep theory, building compilers or operating systems, or performing chip design. They spend their time writing code, waiting for it to build, debugging it when it breaks. They read other people’s code (or try to). They write pieces of applications that massage data retrieved from one source and push it somewhere else. They move pixels around on screens. Do they need to know how the relative efficiency of various algorithms (bubble sort ftw)? Yes, please. Are there roles in tech companies which depend on the deeper theoretical knowledge that is generally learned in formal programs? Of course, but those are the exception, not the rule.

But aside from the actual content of the “average” CS undergraduate program, the history of the last 50 years shows us that a huge potential exists for software engineers who have little if any formal training and who learned by pounding on the family or school or whatever computer they could get their hands on. Sometimes they got programming/IT/web page design/whatever jobs in high school and ran with it. Maybe they went to college afterward, maybe they got the degree, or maybe they didn’t, but they were acquiring and honing their skills and knowledge, sharing it with others, and learning from whatever available resources they could get their hands on or dig up, even before the Internet put so much of that at people’s fingertips.

And you know what? That method of skill acquisition is immeasurably more valuable in the tech industry. Even for CS programs that do offer a fair deal of practical, as opposed to theoretical, content, and even if that practical content generally represents current technology and trends in the industry, the tech will always change, sometimes slowly but sometimes very rapidly. (I’m not ignoring the fact that many industries harbor “legacy” technologies which have persisted, sometimes with no change, over decades, e.g. this listing for an experienced COBOL programmer to work on New Jersey’s unemployment insurance system, which was collapsing under the onslaught of COVID-19-related filings. This article focuses on the industry that grew with or converged on the Internet.)

Tech engineers average around 3 years at a company. Even if they move to a new role which uses the same programming language and basic software tooling and frameworks, they still need to be able to learn new codebases and engineering processes. But during any amount of time in the same company, even if they stay on the same team, they will likely have to learn at least some new technology, whether it’s a new API, new framework, new system for generating documentation (ha), new database to interact with, whatever. And many companies, especially smaller companies, have none-to-terrible onboarding resources and documentation for new hires of any skill level. How flexible they are, how adept they are at digging in to figure out how stuff works without much help, and how quickly they can assimilate the new knowledge and technology likely reflects much more strongly on how successful they will be in their job than most of their actual coursework, especially if they’ve been working more than a couple years.

Many listings in these roles will read “CS degree or equivalent experience” and, yes, that last modifier helps and certainly makes much more sense for more senior roles. (And this may be a signal to appease the H-1B visa system; I’m not privy to all the tricks and requirements around that.) But how are they comparing the two? Especially for, say, infrastructure engineers or roles skewing towards engineering operations, I guarantee no CS program exists which can teach what “equivalent experience” would bring. If you want to hire someone who can actually do the job well, which option do you think would provide a better indicator?

Wouldn’t you rather hire an autodidact with a proven track record for picking up new skills and learning new tools and applying those in real-time without bringing down production over someone who sat in classes for 4 years? If you can get both in one person, great. But why make the CS degree a requirement if it is genuinely not going to be a strong indicator of success in the actual reality of a given job? If it’s habit, well, just drop it. If the role really, genuinely needs deep theoretical knowledge or another specialty with dependencies on other areas, such as signal processing, then great. But your average full-stack engineer probably will perform comparably whether or not they took a college course on operating system design. And if it’s a way to game the H-1B visa system… well. The system is broken. But you have no excuse for ignoring the side effects and consequences of playing to it.

Hiring managers and companies that leave the degree requirement in job descriptions for roles where it would have no impact on how well a person with the actual pertinent skills and work experience could do the job are, consciously or not, intentionally or not, practicing and perpetuating a toxic form of elitism. And these are likely the same hiring managers, recruiters, and companies who complain about a dearth of candidates or the euphemistic (read: fictitious, lazy-ass-covering, bullshit) “pipeline problem.” Stop playing the Sphinx’s game and stop buying into beliefs that persist not through proof but through bias and habit.

Most importantly, realize that considering and actually hiring candidates with diverse backgrounds will enhance your team without sacrificing the quality of the engineering work that team actually, not academically, needs to do, although you do need to provide a safe and inclusive environment for them to thrive. Isn’t that what your company said it wanted in that #BlackLivesMatter statement in June?