I'm a self-taught software engineer with around two to three 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 things. I've helped deliver successful products, which is what led my company to hire me despite my lack of formal technical education.
In my day-to-day work, I do full-stack development, AWS, database management, 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 LeetCode-style stack problem. I spent about an hour and a half failing to solve it. I left feeling like a fraud, even though I believe I would have performed much better in a design discussion or practical engineering exercise.
If I'm being honest, I feel weak at writing code in isolation, while being much stronger at design, communication, product thinking, and actually getting things shipped. Practicing algorithm problems feels frustrating and disconnected from the work I enjoy, but it also seems like a requirement for moving into more competitive or higher-paying roles.
For people with more experience, should I accept that I need to practice data structures and algorithms to pass these interviews, or keep focusing on shipping products and building projects? Is there a balanced way to improve my fundamentals without treating algorithm practice like a second full-time job?
5 Answers
The criticism about LeetCode is fair, but struggling with a basic stack problem is also useful feedback. It may point to a real gap in data structures and algorithms rather than proving that you’re a bad engineer. LeetCode is often a poor way to learn those topics from scratch, so start with a good data structures and algorithms book or course. Once you understand the concepts and common patterns, the practice problems should feel much less mysterious.
LeetCode mostly measures how comfortable you are with that particular style of problem. It isn’t a complete measure of programming ability, and it says even less about software engineering skills like delivering products, making tradeoffs, or working with customers. Still, these exercises are often used as a screening filter, so learning enough to pass them can be worthwhile if you want access to certain companies or compensation levels. Short, consistent practice is usually better than cramming.
There’s a difference between being bad at interviews and being bad at engineering. Someone with extensive professional experience can still struggle with algorithm puzzles, and someone who is great at them may not be able to maintain or ship a real product. That said, interviewers may use these questions as a convenient filter, whether or not the filter is ideal. You don’t have to love the process, but learning the common patterns can be a practical investment if changing jobs is important to you.
You’re not a fraud, but you may be overestimating your experience level a little. Two or three years is still fairly early, and gaps in fundamentals are normal for someone who learned on the job. A useful approach is to create a small learning project for data structures and algorithms. Work through one problem at a time, then revisit the same problem several times using different approaches and in the languages you use professionally. Repetition builds familiarity without requiring huge study sessions.
You’re not alone in feeling behind, especially when AI tools make it easy to avoid wrestling with code directly. One way to improve without creating a separate study job is to turn your normal work into a learning loop. When you encounter an unfamiliar concept, write down what it does, why it is used, common pitfalls, and where it appears in your codebase. Reviewing those notes later can gradually strengthen your fundamentals while staying connected to practical work.
Exactly. Treat it like learning enough of a language to pass a test rather than as a verdict on your worth as an engineer. A little practice every day is much more sustainable than trying to master everything at once.