Skip to main content
december garnet-smith

"seriously, though, how do i break into tech?"

a series of signs at an intersection pointing in multiple directions, many of which overlap.

Photo by Daniele Levis Pelusi on Unsplash

A few months ago, I wrote about the idea of "breaking into tech" and how that alone is inadequate; instead, it's more important to build a sustainable career.

At the same time, I do often see junior engineers, particularly bootcamp graduates, who are confused about how they should find their first role in the industry. Mostly they're told to practice leetcode endlessly, create a side project, and contribute to open source. Instead, I think the best solution is to build a project that is useful to you or people that you know.

Think about the last project you created, whether that was a side project or a bootcamp assignment. When was the last time you actually used it? If you're like most people, you probably built a project with the goal of learning a specific technology like NextJS or Vue or some other tech and then abandoned it immediately once it was done. In so doing, you're circumventing your own learning and limiting your growth as an engineer.

This is because there are different problems associated with projects built with actual users in mind. When they break, you have to fix them. You have to learn to write code that is easy to maintain and read so that when you set eyes on the codebase six months later, you have no issues making needed updates. You'll need to document your code in such a way that other engineers could contribute to it and make changes. You would need to consider whether or not your code scales - does your application work great with few users and less data but break as your user base grows and the amount of data increases? Is your site performant? You'll also want to weigh the pros and cons of different technologies before building your application so that you're choosing tech that actually meets your project's needs. If you never build anything with the intent to use it, or for others to use it, it'll be harder for you to learn those things.

Demonstrating that you understand the importance of code maintainability, performance, scalability, readability, and good documentation is arguably more important than proving that you can do something that you already know how to do. Of course you can learn a new language, pick up a new framework, and implement new tech. All software engineers should be able to do this. What else can you do?

I do want to clarify that doing this will likely not lead directly to a job. In fact, I wouldn't do this assuming that it will. But it will draw people's attention. I've scrolled through LinkedIn and paused to examine a project by a student that I don't know because it was interesting. I'm more likely to remember that person's name and the kind of work that they do. It's noticeable when someone builds an application or a website or an app that they're putting out into the world for other people to benefit from and use. The endless to-do apps and basic checklists tend to blend into the background.

Another upside of building your own application or site is that, assuming there are potential customers, you could monetize it. If you can learn how to create technology that people actually want to use and pay for, perhaps you can create your own opportunities for yourself. If this interests you, you might want to check out the Indie Hackers community as well as the Startups for the Rest of Us podcast.

There obviously isn't one specific way to break into tech. However, taking the road less traveled can help you to stand out in a crowded market of junior engineers eager to prove their skillset rather than putting it to use.


Want more articles like this delivered straight to your inbox? Subscribe below!