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.
Why are software interviews so hard?
It’s true. Software interviewers are harder than non-technical interviews. This is not a profound statement. Passing the bar/board is hard for a lawyer or a doctor. Except software engineering has no such thing. Each company must administer their own bar.
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.
Why do candidates get turned away?
I think it’s helpful to put software abilities into two groups.
- Ability to learn / raw intellect.
Every employer wants to hire the smartest people so the intellect side is assumed to always need to be high.
Buckets of Experience
Let’s do a thought experiment for why experience is important.
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?
One way to think about the spectrum is three buckets per skill:
- 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.
- 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.
- 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
Because to move between the buckets takes more time than the hiring time horizon (ie ≥ 3-6 months). These buckets can also be a black hole in terms of time, and are always moving as technology changes.
The company disconnect — how does this all relate to hiring?
- A company posts a job saying “technology x developer”
- 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?
Some courses do an amazing job blending practice and theory. However in general online courses are light on theory. For better or worse a lot of online courses focus on getting a particular skill from 0 to bucket 1.
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
Imagine you are a fresh graduate of a top computer science program. After 4 years of education you are ready to start working in big tech. You talk with the campus recruiters (if you are a “top” campus) or you send our your resume to big tech. Chances are you won’t get in. Why is this?
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.
What’s the alternative?
I think we should be more clear with ourselves and candidates about what skills we expect to be in what bucket.
- For my top skills, what bucket are they in?
- 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.
How can I more clearly communicate what skills I expect to be 1s, 2s, and 3s?
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:
- Back end, bucket #2
- Front end, bucket #2 preferred will accept bucket #1
- 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