How to be a Good Junior on Your First Job and Succeed…

We all have been there as the junior developer on the first job. The getting used to the office, trying to fit in and not mess things up while absorbing everything. This is it and we want things go well, so how can we do good?

“I wanna learn”

A lot of Juniors pretend to know things and thats unattractive. Everybody knows you lack experience(we can tell by the way you are overly excited). Nobody is judging…relax!

Others make it pretty clear they don’t know much but too much of that also gets old quickly which makes other devs avoid working with you so they don’t spend a lot of time explaining EVERYTHING to you. It also make them appear to lack confidence.

Be confident and sell yourself on the things you know(that’s why you got hired) but, also make people aware of when you need guidance as well. Don’t play hero and try to watch all videos you can find on youtube while trying to do something you dont know because you claimed to have done it before.

“Where are the Docs?”

On the first 2 weeks, I recommend you to learn about the documentation system of any place you land the job at. Learn about how they work, whats documented, best practices and infrastructure, how and when they document stuff, the style of code, etc.

The goal in the beginning is to know as much as possible about how they operate and not trying to get coding done. No rush! You will get to coding eventually, but first learn how they would like you to do it. This is the onboarding phase which also includes learning about the company as a whole.

If a job pushes you into writing code on the first days it can be a red flag. They either dont write documents, work too fast to care and can be an intense place to work at. In that case ask around and take notes. Start your own documents if necessary to then ask for manager review so it can help others that get hired after you as well.

“Explain to me the workflow”

Every place have a workflow they follow to get things done. It is either a 2 weeks sprint, daily standup, occasionally backlog grooming, biweekly sprint planning, quarter PI planning and sometimes all the above.

Whatever they use, learn about it. Ask about deadlines and policies on working extra. What to do when you starting to fall behind, peer programming, who to go to for what? What tools they use to track things. Do you need to log time?

Ask about git repository and about the writing code flow. Learn about git enough to submit your code, create PRs, etc. Ask about their code reviewing rules and guidelines.

They may have a QA team so learn how they test stuff, the rules about writing tests and what tools they use to track tasks and bugs. The people that test stuff will know the most about how things work and the tools they use to track and test things.

“Who should I talk to”

It is important to find a person to attach to for guidance. Some places assign you to someone but it is always good to get an idea of who are the experts in what so you know who to talk to later on. Take notes!

Try to talk to everyone to get an idea of who they are and what they do. Get comfortable approaching people for help. In the beginning it will feel like you are bothering people but dont let that scary you. It’s worse to not talk to anyone and play hero trying to figure things out on your own.

People will also send you around to talk to someone else a lot in the beginning .Thats how you get to know the experts and the easy ones to talk to. Make them your mentor and source for guidance.

“Manage your time well”

If you ask for help and someone is deep 30 mins plus with you unexpectedly, it’s probably a sign you are bothering people. Whenever “ask for help” becomes into a session, take the initiative to stop and schedule something for another day or time.

This will help others allocate time for you and gives you enough time to research something else allowing them to do their work as well. They will love you for it, I promise!

Don’t take too much of someone’s time unless they tell you it’s ok to continue.

People will try to be nice and not let you know you are preventing them from doing their work so, manage your time well, put things on the calendar ahead of time and dont wait for people initiative to come tell you how to do your work.

“I want to join”

Volunteer yourself to things so you get exposed to more ideas, opportunities and connections. Developers team are normally composed of very weird and particular people which makes it hard to connect, in a sense of belonging sometimes.

It will take some time to get used to you so, grab lunch with the group or someone, introduce yourself in the kitchen area, show up for game nights and any social activities.

If you dont like these things make it clear instead of making up excuses. Not everyone can do these things but they will appreciate the effort.

“I would like to try this”

You don’t have to claim to know anything you don’t but you must show willingness to learn. Don’t reject things because “I don’t know” or “I never done it before”. Great developers adventure out of their comfort zone all the time.

Take that task but ask who you should talk to if you have questions. When you get the task, schedule something in the calendar with that someone first thing. Calendar will be the most reliable way to get someone to spend their time with you.


You will be fine. Congrats and Good Luck!

Blog & YouTube Channel for Web, UI & Software Development -

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store