5 Junior Software Engineer Learning Traps

Something I deeply believe in and have shared several times with Taro's community of 15,000+ software engineers is that time is the only resource that truly matters. In today’s extremely chaotic landscape, the world is filled to the brim with distractions and ineffective time sinks. Unfortunately, I see a lot of software engineers fall into these traps. In this article, I will cover 5 traps that junior software engineers in particular often fall into, why they’re actually traps instead of opportunities, and how to get out of them.

Tutorial Hell

There are so many amazing tutorials nowadays, and that’s a huge net good for the community - the tutorial landscape has exponentially improved compared to 10 years ago, making the software world far more accessible. However, the problem with tutorials is that a lot of junior developers don’t realize that they’re merely a starting off point, not a path towards becoming a senior engineer or even a junior software engineer capable of landing a full-time position.

Tutorials should only be used to build a basic understanding of the language or framework you are working with and that’s it. You shouldn’t be at this stage for more than 1 month, maybe 2 if you are completely new to programming. However, I see so many junior software engineers do tutorial after tutorial for months, trying to learn every possible component one can build within their primary stack (e.g. basic rendering -> onboarding -> animations -> video chat -> push notifications -> magical Christmasland). It’s even worse if you are doing tutorials for different languages and frameworks, because on top of being in tutorial hell, you also have no depth and only breadth, which is terrible for job searching.

You may feel like you’re making progress doing so many tutorials, because you are writing different code every time. Here’s why this is not the case:

1. It's not a real learning process - Writing code is indeed a core way junior software engineers can learn, but the educational value you get from it is heavily dependent on how you do it. When you are doing tutorials, you aren’t building much real technical proficiency outside of the very basic surface level understanding. When you spend too much time on tutorials, you are merely refining your reading comprehension skills instead of actually becoming a better junior software engineer.
2. Tutorials solve unrealistic, cleanly packaged problems - This is not how software works in the real world. When you’re actually working, you will never get a problem that is 100% defined like a tutorial is, and you actually grow as an engineer by solving more and more ambiguous problems over time. If you constantly need a heavy guiding presence like a tutorial, you will have a hard-time shipping in a professional, production environment.
3. Tutorials are too accessible - This means that millions of people can easily do it, regardless of skill level. This means that by definition, your tutorial accomplishments, even if they are for monster 50+ hours tutorials, do not stand out. And in today’s ultra-competitive software landscape, especially as a junior software engineer, you need to either stand out or be unemployed.
4. Tutorials are always shallow - This is because their focus is on just getting stuff working. This is especially true for all the “popular app/website clone” tutorials. These tutorials only build the happy flow, and getting the initial happy flow working for a product is only 1% of the journey. The real journey is handling the edge cases, making the code resilient across a variety of screen sizes and operating systems, and gracefully evolving your product based on user feedback. Depth is absolutely crucial as a software engineer, so you need to get out of the kiddie pool.

To illustrate how to avoid this trap, I actually have myself as an example. I picked up iOS development for fun again in 2021, after an iOS break of ~6 years. I effectively started from 0 as I used the new SwiftUI framework and Swift was on v5, which is way different from the Swift 1.2 I wrote back in 2015. Anyways, here is how I learned iOS:

1. I started with Apple’s SwiftUI tutorial where they have you build a sleek sample app that lets you browse a list of famous landmarks and view a full page of each landmark’s details if you tap into one. Even though I was incredibly thorough with it (I played around with the code at each step), I finished this tutorial in ~2 weeks.
2. Immediately after the tutorial, I started building an iOS side project. After ~2.5 months, tons of Googling, and tens of thousands of lines of Swift, I now have a pretty polished and complete iOS app. The code is far messier than what I’m used to writing on Android, but the app is fully featured and I consider myself a fairly capable (but far from good 😂) iOS developer now.
3. I used those skills to build the entire Taro iOS app from scratch, which, as of now, is a beloved app with 320+ reviews and a 4.9 out of 5 average rating.

As you can see, I literally only spent 2 weeks in the tutorial phase, and this would have been 2 days if I worked on this full-time instead of as a side project (I was working full-time at Robinhood during that time). You should do the same: Get out of this tutorial state within 1–2 months and just start building, either through side projects or open source contributions. You’ll have way more fun, achieve way more impact, and grow a lot faster.

Certification Collection

Certifications are effectively tutorials++ in that that they’re still very structured and predictable. The difference is that instead of giving neatly defined scenario -> answer, you only get the neatly defined scenario and have to come up with the answer yourself on some test you need to pass. As a reward for having to come up with the answers yourself, you get a nice certificate at the end, which you can then share on social media and get 100 likes.

I firmly believe that you shouldn’t get any certification unless it’s a hard requirement for a job you really care about. I think why a lot of people value certifications is because they are used to the school way of thinking, where you wanted to grind out as many certificates and awards as possible to get into a good college. Succeeding at school takes a lot of effort and is definitely hard, but in the end, it’s fairly straightforward and follows a very defined set of rules. Software development, especially among top companies like FAANG, is literally the complete opposite of this. At any meaningful tech company, software is a giant ball of chaos that you’re adapting to on the fly while hoping your product doesn’t catch on fire. Good software engineers have to be nimble, versatile, and flexible, and pursuing certifications like they’re the Infinity Stones builds a mentality and working style that is the complete opposite of this. True learning comes when you’re free-styling and forced to go off the beaten path.

I have been on the hiring loop for hundreds of engineers across my ~8 year career. I have literally never seen certifications help a candidate in any case. So let’s say you want to prove to employers that you’re good at Android. Instead of getting an Android certification, try building an Android side project app that gets a lot of users instead. This is far more indicative of your actual potential within a professional tech environment.

Competitive Programming

From my understanding, competitive programming came crashing in during the data structures and algorithms (DSA) wave ~15 years ago when every tech company ever started jamming their interviews full of DSA problems. However, in the current climate, companies are realizing that DSA doesn’t give a complete, holistic evaluation of an engineer’s skills, so they’re not as extremely bullish on it anymore.

Don’t get me wrong, knowing DSA is still important, especially for passing interviews. However, doing competitive programming to help with your job search is like bringing a rocket launcher to a knife fight. You can easily ace the DSA rounds for any company, even Big Tech, with just Leetcode. Something important to remember about DSA is that it’s not meant to be an accurate predictor of how you’ll do on the job - It’s just the best companies can do given the constraints of an interview (i.e. in the span of a few hours, gauge how effective an engineer would be working across years at their company). DSA problems are hard, but again, they are straightforward - You take some input A of type B and return output C of type D. Software is not as clear cut as that, which means that it doesn’t really make sense to hyper-index on DSA - Just learn enough to pass the interview and that’s it. Most junior software engineers aren't competitive programmers, and they are able to make it into Big Tech.

Actually being impressively ranked at competitive programming is incredibly difficult, and for the time it takes, the returns really aren’t great helping you find a job and definitely not for leveling you up once you have a job. I also don’t think I have ever seen competitive programming give a candidate a hiring edge. If you genuinely love the spirit of competition and solving these kinds of problems, by all mean, go nuts with competitive programming. But if you aren’t and just want to land a decent tech job, there are much more effective ways to spend your time.

Building In Secret

As I’ve mentioned before, I pride myself on being honest when sharing advice, so here’s another cold, hard truth: Your idea almost certainly isn’t worth stealing. As I talked about in my article series on side projects, the execution is what’s valuable, not the raw idea. The idea is just the beginning, and there are very few ideas that are so groundbreaking that they are, in and of themselves, valuable. You can see this from how so many existing tech products nowadays are just better versions of older products - The tech game is almost entirely about the quality of execution.

There is also a very real cost when you keep your ideas and code completely secret to yourself: You lose the massive power of community. When you get an idea, share it with others to get feedback. As a junior software engineer, this will help you understand if your idea even makes sense and if it is solving a real problem that others have or are at least aware of. You can also get a sense of whether the scope of your solution is a good fit - Maybe you don’t need to build as much as you thought to have a real product. On top of this feedback, building alongside a community also helps tremendously with motivation, whether you’re just sharing progress with them or actually working with teammates. When you’re by yourself, it’s much easier to get burnt out or distracted, abandoning the project and leaving it stranded.

So the next time you’re building a project, build in public. Share your idea to get feedback and open-source the code (remember to .gitignore those credentials and tokens though!). Ask people if they would evolve the product the same as you would. I open-source pretty much all of my apps, even those with 100k+ installs, and I don’t regret it at all. It proves to users that my code can be trusted, and it helps both the overall Android community and myself. My ultimate goal as a software engineer is to build delightful products that help as many as people as possible. If someone forks my 100k installs app and turns it into a 1 million installs app, I have accomplished my goal even more (albeit indirectly) and I can reflect this on my resume.

Trying To Choose The “Perfect” Tech

I have been asked some version of this question more times than I can count: “What technology should I use to build my project?”. A lot of junior software engineers seem to believe that there’s some optimal technology for every scenario, and one of the perks of becoming more senior is that you get better at identifying that 1 perfect technology. This is not how software works.

In this modern day and age, there are dozens, if not hundreds, of ways to build a legitimately good solution to any technical problem. There is never any 1 technology that’s better than all the rest; if this were the case, software would be way too easy and developers wouldn’t be paid such cushy salaries. What usually happens is that there’s multiple options that are all good but for different reasons.

So what should you do if you can’t figure out what tech to use? Simple, just pick whatever you’re the most comfortable with. Do you have a lot of friends who are good with React? Then build your website in React. You want to build a back-end and you have some JavaScript experience? Then build it with Node.js. You built an Android app as a college project 2 years ago and had a lot of fun? Then do Android! You still have absolutely 0 opinion? Just pick anything, as long as it’s relevant (i.e. you see job postings and LinkedIn activity talking about it). As mentioned before, time is the only resource that matters, so don’t get stuck in the junior software engineer mode of decision paralysis for weeks or maybe even months. Choose something within a few days tops and start building.

You’re Probably Noticing A Common Theme Here…

In the end, the point of a tech company is to ship a quality software product that lots of people actually use as efficiently as possible, often despite lots of ambiguity and generally crazy circumstances. The 5 things mentioned above don’t help you demonstrate your ability to do this (often the opposite), and therefore don’t make you more appealing to employers.

So what you should do instead to level up your technical skills and move from junior software engineer to senior software engineer? As mentioned in several of the sections, you should just start building real products as soon as possible. You know how the point of a tech company is to “ship a quality software product that lots of people actually use”? Well, any developer can now do that from the comfort of their own home. Don’t know where to start? Let me help you. I have published 30+ side project apps with 3 million+ installs combined, all for fun and for free. Check out Taro's career advice on side projects to learn how I did that.