I’m a self-taught developer working for BCG X. Here’s how I did it

What this piece isn’t

1. This is not a piece to brag about my great job and one up everyone else who isn’t working at an established name. That’s a form of punching down that happens a surprising amount on social media and it grosses me out. It’s simply one of many, many stories of self taught developers who found themselves in a career rut and managed to find a way out by learning how to code. And the truth of it is that my job has not significantly changed between my different coding experiences. My core job as a software engineer is to create clear spec, convert the spec into functioning maintainable code learning any technology necessary, and be a great teammate and add value where I can. Its the same formula wherever you are and after getting the offer, I still had the same function as I do now.
2. It’s also not a playbook on how to get a cushy, high-paying job at a great company. Unless you’re the .1% of developers that’s a genius on the keyboard or who has built multiple successful companies before the age of 22 (which, you guessed it, is not me), a lot of getting into a company like BCG is luck, privilege, and of course, a lot of hard work and uncertainty. For the record, working at BCG X is wonderful. All my co workers are great, I’m paid well, I get to travel around the country, and I get to build for some of the most influential companies in the world. But all of that is the extra stuff- it’s not the meat of why I’m here. As soon as I think I can learn more somewhere else or can make bigger impact that speaks to my values, I’m jumping ship- that’s really the meat of it. For now, BCG X is giving me fresh A5 wagyu 3 times a day.

What this piece is

1. This piece is meant to add to the growing database of stories of self-taught developers and their journey to stable software career. What do I mean by stability? If I were to suddenly lose my job, I wouldn’t be that worried. I’d be able to secure a job with comparable learning opportunities within 6–8 weeks and I’ve built a financial cushion for myself to explore a bit beyond my domain of expertise. I think in general if you’re starting off wanting to be a coder from scratch, that should be one of your big milestones. Ultimately you want your skillset to support your lifestyle.
2. Cringing at myself a bit for this one but this piece is meant to inspire. Career-wise I’ve been lost- I graduated from grad school not exactly sure what I wanted to do. Again- this is not a rags to riches story- people have been in way worse positions than me financially and have had less credentials to get to higher, more reputable places than me. But that doesn’t make my problems any less significant to me and doesn’t take away the pride I have in what I’ve accomplished. It’s horribly cliche but no less impactful and important to say- if you’re trying to make the switch into software from scratch, we live in a country (USA) and an age (the internet era) where your chances of success are very high.

My journey

I’m going to break down my career starting from not knowing any code and ending at BCG X. I’ll share what I was learning, the languages I coded in, the different decisions I made along the way, and some of the main obstacles I faced at each stage.

This is a graph of all my positions after grad school and the green boxes are what I was roughly doing in each of those positions. Follow the numbered list below- they map to the bolded milestones beneath the Projects/Jobs row. These are what I think to be important milestones for self-taught developers.

(1) Learning the basics

I’m talking super basics- this is stuff like:

• How does binary work and how does a computer interpret compiled code.
• String, integer, and number behavior, for/while loops, if/else, arrays and arrays of arrays.

I went to the University of Wisconsin-Madison and studied biomedical engineering where we primarily used Matlab to run our lab experiments. We would simulate stretching muscles for example, and graph, analyze, and write reports using simple Matlab scripts. At this point I wasn’t interested in software engineering as a career. I liked the math and logic but I enjoyed the experimental process and was getting interested in the biomechanics of injuries in athletes. This continued into graduate school at Duke where I developed more using Matlab.

General advice:

Matlab is a licensed technology and has some great perks like built-in ML templates, a clean UI, and it’s easy to pick up. But for someone hoping to get into software development, Matlab would close doors for you. There are specific industries where expert Matlab programmers are needed but that’s something you’ll need to suss out when you pick an industry to target.

If you’re not convinced, see the chart below- it’s a google trend of searches in the past year. As you can see, Python takes the cake compared to some other comparable languages. Matlab is at the bottom.

From Google Trends

(2) Learning how to put basics together to make “stuff” happen

In grad school I took a basic Python course. Here’s where I graduated from the single-run scripts to starting to design software systems that could run autonomously. The class was a surface-touch of some more foundational CS concepts such as:

• Object-oriented programming
• Importing packages
• API endpoints and how to roughly design them
• Naming conventions and why modular code is great
• General CI/CD concepts

By the end of this milestone, I was able to stand up a Python backend that stored data in MongoDB, and had a Python GUI frontend. It was a basic image upload and editor. It was really really hard and at the time I wasn’t convinced anyone would pay me for this quality of work. By the end of this class, I knew I wanted to continue growing as a developer but didn’t strongly consider software engineering as a career.

(3) Practiced making better “stuff” with contract work

Source

This is where my career got significant traction.

Coming out of grad school, I knew I liked to code and I liked startups. There’s something infectious about working with startup founders. Everything is new and exciting and possibility is just around the corner. But I couldn’t find a way in and couldn’t find a way to interact with these companies. Luckily I had a fresh portfolio of coding projects highlighting that I wasn’t completely useless at writing Python code and a degree from a reputable school. Also in my favor was that a lot of early-stage startups are willing to take a bet on unproven talent. Fresh talent is cheap, passionate, and durable. You can throw us around and pay us close to nothing and we’ll do it with a smile on our face.

After a short stint at Techstars helping startups grow I contracted with the founders of HurryHome where I built some market research and customer organization tools in Python (HurryHome is an exception to the ringers that startups put young talent through- they treated me exceptionally well and paid me fairly for my work).

I was a solo contractor with some talent but the difference now is that my software needed to be worth the money for an organization on a tight budget. I was responsible for setting my own deadlines, finding key pain points, and deploying software. I learned most of these things- I didn’t master them but I got a crash course on organizing software work and debugging deployed code.

General advice:

Contract work is a great way to stress test your software skills. It’s more accessible than a salaried position and gives you some extra income.

(4) Learned professional coding practices from someone much much better than me

Cornerstone people are individuals that significantly influence our way of thinking either personally or professionally. They’re able to teach us into a higher stratosphere of thinking and leave a permanent mark. I was lucky enough to work with a cornerstone mentor who whipped me into shape. This mentor taught me, in excruciating detail, and with focus on execution over high-level conceptual thinking, things like:

• Writing smart DRY (Don’t repeat yourself) code and why it’s so important.
• Writing great build scripts and best devops practices.
• Creating great endpoint architecture.
• Writing great Javascript code with a focus on fundamentals down to the most minute details.
• How to properly review code.
• How to organize your work and estimate your time properly.
• How to write tests and why they’re so important.

Most importantly, my attitude toward software shifted. I no longer focused on learning as many languages as I could. I recognized that the overall system thinking and habits of great software engineers can be transferred across most technologies and that learning those best practices was more important.

General advice:

Find the cornerstone mentors- they have to be really really good at what they do- and make sure these people are regularly reviewing your work and providing feedback. I would be years behind without my cornerstone mentor.

(5) Got good enough to teach myself web development

I became good enough and confident enough to teach myself the hardest parts about web development:

1. Basics of web security
2. Getting good at docker
3. Creating great CI/CD pipelines
4. More advanced React
5. Performance optimization in web apps

After practicing enough and under the guidance of a cornerstone mentor, I starting chasing down the harder problems and started getting some success. The learning momentum kept me going.

(6) Landed interviews with several big tech companies

I’d say by the end of step 5 I pretty much had a stable career in software engineering. I’d earned a few stripes and could confidently call myself a software engineer. But there was one thing missing:

Learning the classic data structures and algorithms interview is not a strict requirement to be a software engineer. A few of the best engineers I know have never done a data structures and algorithms interview and have star-spangled careers.

For most interviews though, this is the go to interview style. It’s not a bad idea to spend time learning it as you gear up for proper interviews.

After the startup, I was uniquely poised to go for, in my mind, the blue chip tech companies (MAANG and others in that league). I had a stretch of time to floor it and study like crazy for the DSA interviews and I had a few recruiters pinging me to get in the interview pipeline. My study process was meticulous but rewarding- I treated the questions like games which made it fun and I was shooting for 100% accuracy.

During this period, I became intimately familiar with the Python language which proved invaluable. Not only did I seem competent in my tech interviews, but I became a better Flask/Django (Python backend/API frameworks). For those people who say DSA interviews are useless- I’d agree they’re not the best measure of success in a software role, but the growth and learning was worth it.

(7) Secured a Job at BCGX

I landed an offer from BCGX after 4 rounds and cancelled my other interviews. BCGX sold me as being scrappier and faster with more opportunity for growth and learning.

Overall, there were 3 core ideas that helped me

1. Play to your strength- even if it’s not coding. I identified a natural strength of mine and leveraged it to meet the right people and get the right interviews. I’m good at and I like talking to people- even though I wasn’t a good engineer in the beginning, I was pleasant to work with and a clear communicator, something rare in software engineers. Turns out, being a clear communicator saves stakeholders a lot of headache and I got hired on interesting jobs because of it.
2. Engineers must be muggles. To the outside world, the craft of coding is magic. We can make anything. Period. As engineers ourselves, we’re not allowed to believe in magic. Everything can be explained and broken down into smaller and smaller bits. You must be a muggle. Getting really good at explaining what’s going on at deeper and deeper levels is going to help you move
3. It should be fun. This one’s kind of big- coding is inherently fun for me. Everything is a puzzle and there’s so much possibility. When I started to love the process of coding, interviews and work became more interesting and fun, and new projects got more exciting. If the process of coding isn’t fun most of the time, it might be good to do some career introspection or consider a different field.

Thanks for listening. I’m getting off my soapbox now.

Please subscribe for more insights on the world of tech and software!