Quick recap. Last year, I walked away from being a founder/CEO to return to the job market as a software engineer. This is a piece of that story.
I am a bit of an idealist when it comes to jobs in tech. It seems to be a world that you can enter without the usual, expensive ticket (i.e. a university diploma). Where your skills matter more than your background or your experience. This was the idealism we launched SharpestMinds with. That anyone could become a data scientist, a data engineer, or a software developer. All you needed was some will power and the right guidance.
No knowledge? Teach yourself. No experience? Build something. No network? Write a blog. You get the idea. Of course, there is a lot of gatekeeping—especially at the early stages of an application pipeline. But if you can convince a hiring manager that you’re capable, your lack of industry experience and STEM degree won’t matter.
I still believe in that path. It’s hard, and often requires a lot of luck. But I’ve seen many folks do it.
The point is, you can get in the door of a technical career without “traditional'“ experience. But it’s a whole different ball game for senior level roles. Experience matters. And, as I found out on the job search, the nature of that experience matters a lot.
I was targeting senior web developer positions. After all, I had 6+ years of experience building web applications. True, it was was mixed with the founder-level duties of an early stage startup, but it got me past most gatekeepers and I was lucky to have a consistent stream of interviews. But in those interviews, I repeatedly came up against one decisive word:
Scale.
Here’s the thing. Writing web apps is kind of easy—until it isn’t. It’s scale that makes it hard. If your app works for 10 people, it might not work for 100. It if works for 1000 people, it might not work for 10,000. It definitely won’t work for 1 million. Having lots of people, from all over the world, use your software at the same time introduces an entire suite of programming problems that were not there before.
Unfortunately, SharpestMinds never got to scale. So while I had 6+ years of experience, it was basically 6+ years on easy mode.
The companies I was interviewing at (mostly Series A startups) wanted engineers to help them scale. Demand for their products was increasing exponentially, and they needed folks who could handle the technical problems that was creating. Optimizing compute, handling high-throughput concurrency, dealing with unpredictable spikes in traffic, querying terabytes of data efficiently. You get the picture. Things that you don’t have to worry about with a few users.
Scale also brings with it an increase in edge cases. If there is an obscure bug that affects less than 1% of your users, it can likely be ignored. But, at scale, that small percentage adds up.
Over and over again, I was forced to admit that I hadn’t really experience true scale. It was eye opening. I was learning my biggest weakness as an applicant. Normally, my instinct would be to go heads down and up-skill by building something. But it’s very hard to introduce scale into a hobby project. How do you get 1 million users to try your custom Spotify dashboard?
Despite some discouraging rejections, I was feeling motivated as ever. Clearly, there was demand for software engineers who have experience with scale. In the startup world, there was an even more acute demand for software engineers who have scaled—who were building products as their user base grew rapidly.
At SharpestMinds, I learned how to take a product from 0 to 1. At my next job, I decided, I would learn how to take a product from 1 to 1,000,000.
yes Russell, As a senior system engineer leading a team of elite UNIX/Network/ Security people "back in the day" and trying to build up my team, during hiring there was always a chasm between those with scaled experience and those who play with development, and smaller use cases. I hired folks who showed the potential to learn from the more experienced ones, and those who displayed a genuine 360 view and interest of what the business actually needed. You don't get experience on scaling without literally doing it, but you can work on simulations of scale and throughput.