I'm a self-taught engineer with around 2–3 years of experience at a mid-sized startup, and I was recently promoted from junior to mid-level. I started coding when GPT-3.5 became available, so my fundamentals were never especially strong, but I've become good at building and shipping products. My company hired me because I had a track record of delivering successful work despite not having a traditional technical background.
In my day-to-day role, I work across the stack, AWS, databases, machine learning, Docker, system design, customer communication, and collaboration with other engineers. I'm comfortable taking an idea and turning it into production software.
Recently, I interviewed elsewhere and was given a basic coding problem involving stacks. I spent about 90 minutes struggling with it and left feeling like a fraud. What frustrated me is that I believe I could have done much better in a design discussion or a practical engineering exercise.
I'm starting to wonder whether I'm actually a weak programmer who is only good at the surrounding parts of software engineering. Practicing algorithm problems feels painful and disconnected from the work I enjoy, but it also seems like the standard requirement for getting access to better opportunities.
For people with more experience, should I deliberately spend time learning data structures and practicing coding problems, or should I continue focusing on building products and developing the skills that have already helped me advance?
5 Answers
The stack problem is still useful feedback. It doesn’t prove you’re a bad engineer, but it may reveal a fundamentals gap. Rather than jumping straight into random algorithm puzzles, work through a data structures and algorithms book or course first. Once you understand the core concepts, the interview exercises will be much less mysterious.
There are experienced engineers who still struggle with algorithm questions, so don’t treat one bad interview as a verdict on your career. At the same time, higher-paying roles often require passing this filter. You can treat interview preparation like learning a language: a small amount of regular practice is usually more sustainable than trying to force yourself through hours of puzzles.
LeetCode mainly measures how comfortable you are with a particular style of timed puzzle. It isn’t a complete measure of software engineering, especially the ability to design, collaborate, and deliver products. Unfortunately, many companies still use it as a screening filter, so you may need to practice it if you want access to those roles, even if it isn’t representative of your everyday work.
Shipping quickly is valuable, but moving fast without understanding the code can create cleanup work for everyone else. Keep building products, but use the areas that challenge you at work as learning opportunities. Taking structured notes about concepts, why they matter, common pitfalls, and where they appear in your codebase can help you improve without making learning feel like a second full-time job.
You’re not a fraud, but you may need to be realistic about the gaps that come with being self-taught. A practical approach is to keep a small learning repository and work through one problem at a time. Repeating the same problem several times in different ways can build familiarity without turning preparation into an exhausting cram session.
Related Questions
How To: Running Codex CLI on Windows with Azure OpenAI
Set Wordpress Featured Image Using Javascript
How To Fix PHP Random Being The Same
Why no WebP Support with Wordpress
Replace Wordpress Cron With Linux Cron
Customize Yoast Canonical URL Programmatically