Software engineering paths

Am I good enough? This is a surprisingly tough question to answer when it comes to software.

It’s generally accepted that current software interviewing practices leave a lot to be desired. There are attempts to fix it. Having been on both sides of the table I thought it may be useful to share some thoughts on the topic.

Photo by Jukan Tateisi

Why are software interviews so hard?

The best explanation I have heard is summarized as: Most companies interview to avoid failure, not for the potential of success.

The concern is not really if the person could do the role. Rather the concern is avoiding loss. In other words, “am I 99.99% certain that this person will succeed in the role?” This means that even candidates that have an 80% chance of success in the role, get turned away.

Photo by Stefan Spassov

Why do candidates get turned away?

  • Ability to learn / raw intellect.
  • Experience.

Every employer wants to hire the smartest people so the intellect side is assumed to always need to be high.

Buckets of Experience

Imagine you had the opportunity to hire a young bill gates — sounds like an obvious choice right? What if you must say ship a feature that depended on a skill he was unfamiliar with?

Pretend for a moment company won’t exist if the feature can’t be shipped so no long term benefit to having him on. It doesn’t matter if he’s a 10/10 on the intellect scale, the experience isn’t there, and so he may not be right for the company at that moment in time.

So how much experience is enough? Am I a “senior” engineer?

  1. I understood only the highest level implementation and followed tutorials most of the time. I may have done a small scale similar project. I’m not comfortable implementing something much outside the scope of those tutorials, or it would take me a long time to do so. I first encountered this technology less than 6–12 months ago.
  2. I understand a few different ways to solve this problem. I worked with a larger scale system and/or saw a smaller scale system grow. I implemented some of my own workarounds to the typical approaches. I can confidently explain my understanding of trade off decisions.
  3. I built or helped build the technology that others use to solve this problem. On this narrow topic I’m generally one of the best people in the world. Generally things I don’t understand about this problem are considered to be “unsolved problems” by the community. I first encountered this technology more than 2 to 5+ years ago.

Beyond this is the exit from engineering and entrance into pure research

How many people are in each bucket?

Most people for most things will fall into the first bucket. When considered per skill, very few people will fall into the 3rd bucket. Think literally less than 100 people in the world per skill.

The first bucket is a good thing. I think most of our work should fall in that bucket.

To try and show how easy it is to not be in bucket 3 consider this. If you wanted to implement the python/c++/language, would you fit in the 3rd bucket for that?

Of course not! (unless you are Guido or Bjarne or a core contributor to those languages) And of course, you don’t have to be!

Why it’s hard to move between buckets

Photo by Matt Heaton

The company disconnect — how does this all relate to hiring?

  • A candidate being a bucket 1 in technology x comes along and applies.
  • The company does a “tough” interview and the candidate fails.

This is really just a misunderstanding in a sense, a mismatch between the company looking for a bucket 2 skill and the candidate being a bucket 1 in that particular skill.

Top companies usually don’t hire for a role where the primary skill in the 1st bucket. It’s just to common / too quick to pick up. Therefore companies usually hire for the 2nd bucket. But no one tells you that! Interviewers are coached to not give feedback for legal reasons and even when they do few will convey the message that “yes you are smart, you just aren’t there yet for this skill (in our opinion)”

The goal of coding quizzes is usually to determine if the person is actual in bucket 2. The problem is that being good at quizzes does not equal being good at the role. Companies ratchet up the quiz difficulty, candidates further optimize quizzes. It’s like an arms race, the loser is everyone!

Online education to the rescue?

But don’t mistake it for bucket 2! I don’t believe any program, not matter how good can really teach bucket 2 skills. Because the definition of bucket 2 that is must go beyond whatever is commonly accessible through education.

The college disconnect

Working in technology requires understanding how to do practical stuff, hopefully in addition to, the theory behind it. For example, you may have learnt about sorting algorithms. While useful, that will not directly translate into a skill that gets hired for. Unless you say progress to a graduate program where you are doing bucket 3 algorithm research.

What it does help is more quickly go from 0 to bucket 1 for new skills — it’s valuable and needed, it’s just a different concept from a single monetizable skillset.

Some university programs (Waterloo for example) have strong internship programs that provide the practical experience needed to supplement theory. Some don’t.

If you invest the time to work on your own project, or do relevant internship or similar, you likely will progress from bucket 1 engineering skills learnt in university to bucket 2 skills.

Photo by Will Francis

What’s the alternative?

For candidates:

  • Be strategic about what you learn. What skills do I not want to progress into bucket 3?
  • What bucket 1 skills do I really need to move into bucket 2? For example if you aren’t really interested in the ins and outs of python, you may consciously say I never want to be a bucket 3 in python.
  • Don’t expect your employer to really be aware of which bucket they are hiring for. Even if you are talking with a technical hiring manager they may have never really given it thought (the just “know” what they want.)
  • Don’t expect a project alone to be enough as a primary skill. For example this is a project I did for a full stack course online, knowing what I know now about backend development I would not hire myself for a backend role off of that project alone.

Some questions that may help direct the conversation during an interview are:

  • Are we planning to use popular libraries to solve a core part of this problem (bucket 2) or are we writing our own library (bucket 3)?
  • For (this) skill are you looking for a world expert (bucket 3), someone to implement best practices on this technology (bucket 2), or just need the person to have a general idea (bucket 1) to guide work on a different skill?

Be aware if you do get a role where the primary skill is a bucket 1, your employer is subsidizing your education to being a productive bucket 2 or 3. Ideally all employers would do this but most can’t or won’t.

For employers:

For example, right now Diffgram (where I work) is hiring for a software engineering role. In the context of the this article what we are looking for in order of priority:

  1. Back end, bucket #2
  2. Front end, bucket #2 preferred will accept bucket #1
  3. Deep learning, bucket #2 preferred will accept bucket #1

In the job description this translates into:

You are a good fit for this role if the following describes your backend skillset:
“I understand a few different ways to solve backend problems. I worked with a larger scale system and/or saw a smaller scale system grow. I implemented some of my own workarounds to the typical approaches. I can confidently explain my understanding of trade off decisions.”

Beginner front end and/or deep learning experience is ok, preference given to candidates more experienced in these areas.”

By the way if you fit this description I encourage you to apply!!

Thanks for reading

Anthony

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store