I'm seven months into my first job as a junior backend developer. Most of my work has involved fixing bugs, writing tests, and implementing APIs from specifications provided by senior developers. They usually explain the expected inputs, outputs, and business rules, while I handle the implementation and receive feedback through code reviews.
This seems useful, but I'm worried that I'm progressing too slowly because I still don't feel comfortable with database optimization, system architecture, Redis, or other broader design topics. Is this amount of responsibility normal at this stage? How did you move from junior to mid-level and eventually senior developer? Should I ask to take on more ownership, such as designing a feature from start to finish? Also, is practicing algorithm problems still worthwhile if I want to apply to better companies?
5 Answers
You’re responsible for driving your own learning, but you don’t need to rush into architecture, Redis, or database tuning before you understand the fundamentals and the existing product. Use documentation, books, and small personal projects to explore those topics, and connect the learning to problems you actually encounter at work.
For algorithm practice, it can still help with interviews, especially at companies that use coding screens. It’s useful for that specific hiring process, but it won’t replace learning API design, databases, testing, observability, deployment, and how to make sound trade-offs in a real system. There’s no need to leave a job after seven months just to chase a title unless the environment is seriously limiting or underpaying you.
Try to look at each task as more than a ticket to close. After finishing the required work, write down one related topic you want to understand better—for example, why a query is structured a certain way, where a business rule belongs, or how a service is monitored. Read about it, then ask a senior focused questions while the task is still fresh.
You can also ask to take ownership of a small feature end to end. It doesn’t need to be a major redesign; planning the approach, identifying edge cases, implementing it, testing it, and helping deploy it will teach you much more than only receiving an implementation spec.
The main thing you’re missing may be decision-making rather than more advanced technologies. Ask why a feature is implemented a certain way, where its requirements came from, what happens when the data changes, and how the code will be maintained or operated. Understanding the full lifecycle of your work will gradually prepare you for design discussions.
You’re also allowed to build something small independently in your own time. It may not be production-quality, but choosing the design yourself—and then discovering the mistakes—can fill in gaps that guided work doesn’t expose.
Seven months is a very short time in a career that takes years to develop. You’re currently learning the product, business rules, frameworks, deployment process, and existing architecture. At this point, implementing well-defined work under supervision is expected, not evidence that you’re falling behind.
There isn’t a strict timeline, but many developers spend another year or more gaining independence before moving beyond junior responsibilities. Senior-level judgment often requires several years of experience, including seeing systems evolve and dealing with production problems.
That sounds completely normal for seven months into your first role. Bugs, tests, small features, business logic, and code reviews are how you learn the codebase and build trust. As your team becomes more confident in your work, you’ll usually get more independence and responsibility.
If you feel ready for more, tell your manager specifically that you’d like to shadow a senior on architecture work, pair on a design, or own a small feature from planning through deployment. Just avoid trying to optimize things based on guesses—first understand the system and confirm there’s an actual performance problem.
The business knowledge is a big part of becoming useful. Once you understand which systems and data are safe to change, and which ones have hidden consequences, you can take on much larger tasks.
I’d be cautious about treating four or five years as an automatic senior milestone. Some people reach it then, but becoming a strong senior usually takes deliberate practice, good mentorship, and enough time to understand the business and system—not just years on a calendar.