Does Your Next Software Engineer Need a Degree?

When debating the qualifications of a candidate without a degree, the usual criticisms and questions still exist:

• "How much can someone really learn in 12 weeks?"
• "What about data structures and algorithms?"
• "I only hire top-tier developers on my team."
• "We can’t afford to bring on someone more junior."

I heard these types of questions often while teaching a coding boot camp, and before that, when I personally transitioned from teaching to software development. After several years in the industry, I still hear these types of questions come up in conversations about hiring.

A developer with a non-traditional background can, with time and support, perform just as well as a developer with a more traditional background. Personal drive determines a lot of that, as does environment.

Depending on context, these questions or concerns might be well-founded. For example, if you are working on real-time computer vision, you probably need someone who can write extremely efficient code and is very strong in mathematics. But these questions might be ill-informed; the result of not examining some misguided assumptions.

Perform a company self-evaluation

It is important to identify the right qualifications for your role. Before making a hire, or even posting an open position, a good manager will ask themselves some basic questions:

• What problem are you trying to solve by hiring?
• What actual need exists here?
• What knowledge and experience does a candidate need to have coming in and what do you expect them to learn on the job?

Most software development is about translating (sometimes vague or abstract) business requirements into technical requirements, and then turning those technical requirements into code. That code, in turn, either directly or indirectly drives business activity and key metrics. That's why evaluating the types of business requirements and solutions your team receives and produces is a great place to begin when deciding the qualifications your candidate needs.

• Is the nature of your business math-heavy?
• Algorithmically complex?
• Are there particular compliance or regulatory demands?
• How straight of a line can you draw between the business requirements and the implementation of a solution?

Next, it's worth taking a look at your processes.

• Who generates those business requirements?
• Who turns them into technical requirements?
• Who implements them, and how?
• What system or systems might a developer touch on their way to a complete implementation?
• What do you use for version control (if anything)?
• What system-wide patterns and idioms exist?
• What do you use for testing?
• How do you solicit and provide feedback on code, and what are the components of that?
• How often do you release?
• How often do you change the structure of the database?
• How do you track and triage bugs?

It's worth also examining your code.

• How readable is it?
• How coupled are different parts of code?
• Could a reasonably competent developer who is unfamiliar with your codebase orient themselves and find the line(s) of code responsible for a certain feature?
• How many different languages and frameworks are you using?

Finally, consider the issues that seem to occur frequently.

• Do developers implement solutions that do not actually meet technical requirements?
• Is deployment tricky?
• Do show-stopper bugs frequently make it to production?

This evaluation is not designed to create blame, but instead to give you an accurate view of your organization. From here, you can make a list of competencies and knowledge a prospective hire might need or be able to quickly acquire. You can also determine bandwidth existing employees and managers might have to help a new hire get up to speed.

• Do you need a developer who can invert a binary tree?
• Do you need someone who knows Ruby better than they know themselves?
• Do you need someone who can hand-tune SQL queries operating over millions of rows?

You might need someone who can do these tasks! But don't screen for them if you don't need them.

You might just need someone who can take relatively straightforward business requirements and build relatively straightforward solutions for them in a reasonable amount of time. If that is the case, how much does a candidate's degree really matter?

Evaluate for the key characteristic: Competence

When evaluating any junior developer, especially those from non-traditional backgrounds, there are only so many examples of work to draw from. Many such samples may be protected by NDAs, the result of tightly prescribed class projects, or old enough as to no longer be useful. For this reason, we at Unabridged Software use a take-home project to evaluate technical competence.

However, the take-home sample is not the only thing we look at. We also expect our developers to be able to:

• Precisely describe technical processes using relatively simple language
• Decompose problems into simpler steps by way of analysis
• Compose simple individual pieces into a more complex process or solution
• Ask questions and resolve ambiguity as concretely as possible
• Anticipate possible sources of errors or chaos
• Evaluate competing solutions to determine which one is best for this context
• Evaluate competing problems to determine which is best to work on now
• Treat others with compassion and thoughtfulness

None of the skills on this list are unique to software development, nor even to STEM. You will see some evidence of them in the take-home work sample, and you will need to look for evidence of these skills by asking questions and prompting for more information. You may be tempted to ignore a candidate's previous non-technical work history, but that would be a mistake -- this history often reveals a lot about who the candidate is as a person and how they work. The other great place to look for evidence of these traits is in areas where a candidate has achieved success in the past, vocational or otherwise.

Education is the starting line, not the finish line

A candidates' educational background matters less and less as they gain experience and skills. Education still stands as a proxy for competence — a computer science degree from Stanford or MIT naturally carries more weight than an associate's degree in software development from a community college — but any degree is only a starting point.

A developer with a non-traditional background can, with time and support, perform just as well as a developer with a more traditional background. Personal drive determines a lot of that, as does environment; most folks rise to meet their current situation when given the opportunity. It is rare that you will find someone who does not want to succeed, though you may find many people whose success you are not (yet) able to support with sufficient resources.

Even if you hire someone who knows the languages and tools you use, and even if that person already has knowledge of your industry, there will still be a considerable ramping up period as that person gets to know your codebase, internal practices, and tools. There is no such thing as a developer who can truly hit the ground running. Rather than wait for such a mythical creature to appear, focus on building the infrastructure needed to help new hires be successful as quickly and consistently as possible.