Throughout my career, I have conducted more than 700 professional interviews for various software engineering positions.

Successful candidates surprisingly share the same trait: the beginning of their careers was incredibly similar. I believe that when you are just starting, there should not be too much freedom, since tackling the right problems will define your path.

Stage 1: Learning to write production-grade code

Your main goal at the beginning of software engineer career is to learn how to transform your “writing code” abilities to “writing code for real users (production)”. This requires a lot more than just committing a code to a version control system. The list might vary between different companies, but in a nutshell, you should learn the following:

1. Code readability - how to write code for others to read
2. Teamwork - how to work in a team of other developers and QA
3. Code reviews
4. Pull requests
5. Development tasks/tickets/issues
6. Tests - how to write testable code and learn different types of tests
7. Deployments - how your code is deployed to production
8. Monitoring - how to monitor your code in production and make sure it works as intended
9. Coping with production problems (urgents) - how to handle problems in production that happen to real users

Countless books have been written on each of the topics above. While we won’t dive into them here, you must invest some time into learning more about all of them. This is the foundation to become a successful software engineer.

Stage 2: Learn how to build simple architecture

When you feel comfortable delivering code to production, we can go up a level: learning to design software architecture solutions. The best way to accomplish this is to start small and ask your team leader to give you less defined tasks. This creates an opportunity for you to brainstorm the potential solution, design it, discuss it with senior peers, receive feedback, and finally, to implement it. The emphasis at this stage is on suggesting solutions and receiving feedback.

Stage 3: Learn to design subsystems or their parts

This stage is a logical continuation of the previous one: we are moving from features to designing important parts of the system. This requires a deep understanding of the whole picture (system) and how the part in question, the one you are working on, fits into it.
The course of action is similar to the previous stage, in that you will provide solutions and receive feedback. However, now the scope of the project has grown. You should consider the overall architecture of the part, its API communication with other parts of the system, using industry standards solutions, different design patterns, etc.

Stage 4: Build service from zero to production

There’s no substitute for the experience of building a service from the ground up and delivering it to production. This is a rare opportunity, especially in well-established engineering companies. Thus, whenever you have the chance, be sure to jump on it!
What should you expect here? Ouch…. quite a lot.
• You should learn to evaluate different approaches to solve the problem you have, taking into account their advantages, disadvantages, and cost of implementation.
• You should also experience how to deploy a new service to production.
• If, in all previous cases, you could remain in one domain, e.g., front-end or back-end, at this stage, you should be able to cross them and start writing code in both of them, including DevOps for the deployment part.
• You have a chance to define and/or adopt coding standards for your project.
• Last but not least, you’ll need to understand how to monitor the behavior of the service in production and the load, as well as what metrics and KPIs to look at.

Stage 5: Build a product

Whether you are in a startup or your well-established company is discovering a new possibility, you should participate in building a product. You may be wondering, “How is it different from stage 1?”
We are always contributing code to some product. At this stage, you must shift your concentration from writing a good code to building a good product.
To achieve that, what do you pay attention to here?
You work with the product team is mainly where you will direct your energy. Why are you working on this or that feature? What customer problem does it solve? Have you considered all feasible edge cases? How will a certain feature perform under load?
Those are just a few among the many questions engineers should ask product people and themselves, too.
This is the step where engineering and business value finally interact.

Stage 6: From here to infinity

The easy part is now over. This journey usually takes around 3-5 years. This is when the ‘hard’ part begins. Nobody can tell you what your goals should be but you. You will have to decide for yourself whether you want to try the management path or go deeper into engineering craftsmanship.
Whatever you decide, the stage that starts here has no end.