Five Things to Look for in a Junior Role
I’m going to preface this piece by saying, finding your first job can be difficult. An employer has to be willing to take a chance on you, and not many employers can or do, further more, there’s a higher demand for senior developers, which makes the job market that much harder for juniors. Your first job may very well be a take-what-you-can-get situation which you can use as a stepping stone into the industry. Saying that, that doesn’t necessarily mean the following points are useless or not applicable to your second/third junior role.
1. Can the team support a junior?
This is an important one, you want to make sure that the team you’re joining can properly support a junior developer. Have they had other, succesful, junior developers? What’s the onboarding process like for juniors? Do they pair program? Do code reviews? Who do you consult if you have questions? Is there an opportunity to receive and give feedback? These are key questions when looking for a junior role because essentially the answers will let you know if the team you will be joining actually have the capacity for a junior developer.
2. Manage expectations
What kind of support do you expect from the team? What do they expect from you? What does your role comprise of? Be clear about this from the onset. Any confusion about this can lead to miscommunication and mismatched expectations down the line. Your team may think you more capable or not as capable of doing certain things, or you may demand more than your team is able to give, or maybe not demand enough.
3. Personal development
Your personal growth and development as a developer is important not only to you, but should be to the team as well. The more you know and learn, and can experiment, the more you’ll have to give to your team. Do you have time/room to experiment with new ideas and technologies? Is the team encouraged to share ideas away from the desk either through learning lunches, talks or presentations? How does the team foster learning that may not be directly tied to the company’s product?
4 . Continuous improvement
How does the team handle mistakes? What’s the plan for when things go wrong? Is there a space to revisit the past week/fortnight (in the form of retrospectives) to improve on the past weeks? Having structures in place for when things go wrong on both a technical and interpersonal level is extremely important. Most companies succeed on the former, but many fail on the latter. It’s important for mistakes to be corrected in a non-confrontational, constructive way, and the team should always be striving to make the environment comfortable, and foster learning and growth.
5. Room for progression
Depending on how long you see yourself at the company, and your reasons for joining (are you using it as a stepping stone or something more permanent?) this point is not necessarily vital. However, I think it is good to know how other developers have progressed through the company. This may be tricky to spot at first if it’s a new company or start-up, but if you’re looking at more established companies, this is definitely something to look for. How often do developers move through the ranks? At what pace do developers move through the ranks? Are you expected to progress in a similar way? When you’ve been at the company for a while, it’d be fair to ask your CTO what they look for in mid-level developer, and ask them to be clear and spesific, so that when you’re ready, you can start moving towards that.
