What We Expect From Software Developers on Each Level

Photo by Markus Spiske on Unsplash

I described in a separate post details about the process we’ve been doing recently in our engineering department, where we started working with levels for our engineers and QA. After discussions in our tech directors forum and review of the expectations by every member of our department, we ended up with the below list.

I hope it can help you, junior developers who want to understand better if “you’re there yet”, or managers who want to get inspiration.

Every level’s expectations include the expectations from levels below it. We expect people to meet about 80% of the expectations per level, as opposed to all of them, because people are different.

We added tags to expectations: requirement, level-up opportunity, etc. In the below text, everything is labeled ‘required’ unless mentioned otherwise. The most interesting tags are Baseline and Level Up Condition.

Entry Level

1. Be able to present and discuss what they have done, and their progress.
2. Be interested in and perform learning and exploration of the tools they work with (Level up opportunity).
3. Be able to reproduce bugs and to fix UI layout issues.
4. Learn and practice clean code (Level up opportunity).
5. Manually test the flows / bug-fixes created by them (to have full accountability for commits).
6. Given heavy mentoring, execute tasks outside of their level (Level up opportunity).
7. Understand the CI/CD tools and flows, and with mentoring can deploy to production.
8. Contribute to code documentation and readability (by renaming or adding comments in unclear places. Level up opportunity).
9. Be able to improve after feedback (given constructive and specific feedback. Baseline).
10. Be able to ask for help when needed — use the team to deliver.
11. Review and understand code reviews of others.

Junior Level

1. Can plan and take responsibility for their own time.
2. Be able to solve a bug from production (reproduce from report, investigate, fix and deploy).
3. Write unit tests, given the framework is in place (Level up opportunity).
4. Share knowledge — by writing in a channel, giving an internal talk, recording a short video, writing a blog post (Level up condition).
5. Communicate about status of tasks daily.
6. Attend tech meet-ups and forums (Level up opportunity).
7. Understand the team members’ updates in the stand-ups and if not — follow-up offline and make sure to understand in high level.
8. Understand the time expectations, raise flags about blockers or delays daily.
9. ​Estimate tasks by time that takes me to fulfil (e.g. 1.5 days). Not including breaking a story to tasks. The precision isn’t important, rather engaging in estimating and improving over time.
10. Engage with their personal growth plan (identify with help what are areas of improvements and work towards it).
11. Assists in setting up CI/CD (Level up opportunity).
12. Pair or Mob with more experienced colleagues (Level up opportunity).
13. Be able to maintain (as a single developer, but with mentoring) a small project after it’s been released to production (Level up opportunity).
14. Participate in the documentation of the solution, such as repository README, process descriptions and system descriptions.
15. Perform code review — ​according to the team’s review guidelines.
16. Be proactive in making sure they get enough code reviews.

Mid Level

1. Can deal with reasonable context switches.
2. Implement a story (incl. breaking the story to tasks and estimate).
3. Has good grasp of implications of architecture decisions (Level up opportunity).
4. Complete devOps tasks related to their features: adding monitors, modifying CI/CD pipelines, changing DB backup.
5. Can execute tasks independently (incl. asking for suggestions from the team when needed).
6. Be familiar with best practices, like design patterns. Know to identify them in the code and use them when writing new code.
7. Assist in system architecture design (Level up opportunity).
8. Be a source of information to the team in (at least) one subject (one library, one practice, etc).
9. Setup tests framework and write tests with little to no mentoring.
10. Lead Pair or Mob programming sessions with more junior developers (I disagree with this one being in a mid level, I think it should be in senior. Level up opportunity).
11. Coaching of junior developers.
12. Can setup a development environment on their own (level up condition).
13. Can refactor code modules for readability and maintainability.
14. Perform code review to others.
15. Understand the full lifecycle of an application.

Senior Level

1. Can design a software solution from scratch within their field.
2. Can implement CI/CD Tooling incl. selection and setup of infrastructure.
3. Be accountable for readability, scalability and maintainability for a platform in a project.
4. Choose a stack for a project after research and consideration with their team.
5. Mentoring mid and junior developers.
6. Tests: choose stack, decide what should be tested.
7. Have knowledge of modern software architecture patterns and can work with them within their field.
8. Can capture requirements and discuss implementation details externally and internally.
9. Be active in the API specs (contracts) creation (both ends).
10. Analysis of complex bugs within their domain.
11. Can think about the software solution in general outside the scope of their tasks.
12. Define code reviews standards.
13. Keen to learn new technologies, follow trends and incorporate best practice (baseline).
14. Will feed into the devOps tasks and be familiar with the internal model.
15. Be able to research and present a solution for an identified business or technical problem.
16. Understand the whole stack used in the projects (level up opportunity).
17. Has an eye for possibilities and knows how to meet the needs of the clients.
18. Accountable for the documentation of the solution, such as repository README, process descriptions and system descriptions.

Tech Lead (IC path)

Our tech leads are 80% senior developers in their projects, and 20% responsible on advancing the technologies they work with. We will have tech leads per technology, for example: Android Lead.

1. Giving internal educational and inspirational talks.
2. Advising on growth plans.
3. Be involved in the community of their domains in Stockholm/online.
4. Radiate knowledge internally & externally.
5. Involved in interview process and sit in on interviews.
6. Give directions and recommendations on integrations with client systems.
7. Build own and team understanding of the client, their business model and users.
8. Thinking and communicating about the challenges we will face in the next 6 to 12 months in their domain.
9. Advise about reducing complexity in projects, services, systems and processes from their domain point of view.
10. Design system architectures with good UX, information design, scalability and security that are cost efficient for the client.
11. Domain knowledge on platforms/frameworks.
12. Be responsible for the tech radar in their domain, and communicating about it.

Tech Director (manager path)

1. Defining and follow up on our coding practices in projects.
2. Define and lead solution and system architecture practices.
3. Attend and contribute in external technical forums in used areas.
4. Ability to understand clients business and factor this understanding into solutions.
5. Part of defining the dept. strategy — culture, stack, etc.
6. Create trust relationship with the client and cultivate a close relationship with tech people of the client.
7. Remove technology blockers from the team.
8. Identify cases of being bottle necks and change the structure to fix them.
9. Mentor team members according to their growth plan.
10. Work on the team dynamic to maximise abilities, growth, collaboration and innovation.
11. 1:1s with tech team members.
12. Work with design and biz directors to achieve the goals for that studio.
13. Resolve conflicts in the team.
14. Strategic advisory towards the client.
15. Maintain a constructive feedback culture.
16. Support in building a culture of a community.

Summary

Every organisation has different needs, and the fact that these are ours doesn’t mean that they need to be adopted exactly by another organisation — on the contrary. I highly recommend reading about the process of how we introduced them.