Ken Mazaika writes that
It’s not uncommon to think that the expectations of a junior developer are massively different than they really are. This mentality sabotages the performance of many developers on the technical interview. Thinking the bar is higher than it is will lead you to exaggerate, embellish your skills, and ultimately not get the job.
It is sheer honesty and the acknowledgment of areas of improvement that separate the developers who get offers from the know-it-alls who do not. Here’s why:
Hiring junior developers is an investment in their long-term potential rather than an immediate payoff. Most companies that are good to work for will not expect their junior developers to ship complex features and not ask questions for the first couple of months.
The first three or so months as an entry level developer is all about learning. Learning how the team operates. Learning how to act in meetings. Learning how the codebase is architected.
Here’s how most companies onboard junior developers:
Your first challenge: Getting up and running
Applications that companies build are often very complicated, and just getting the application running on your work computer can be a challenge. You’ll need to install the programming language on your computer, and likely also different databases and services on that machine.
In order to do that, companies will grant you access to the codebase on GitHub, and your job is to get the program to run successfully on your computer.
This process can take up to a couple of days. Usually, the team will let the new developer take a crack at setting things up themselves, but more senior members of the team will generally check in and ask you if you need help if it takes longer than expected.
As a junior developer, if you ever run into problems, or feel like you’ve been stuck trying to do one thing for a while, you should ask for help. The other developers on the team are there to help you out.
Your first meetings: Dev team standup
Development teams that practice agile methodologies (that’s most companies) have a short meeting every day. That meeting is called standup. In that meeting, people stand in a circle and each person will give a brief (30-second to 1-minute) update to the rest of the team. In this meeting, you’ll explain:
What you did yesterday
What you plan to do today
If anything is preventing you from getting your responsibilities done
Since the entire team is present at standup, it should be brief. After the meeting, people often break off into smaller groups to talk about specific issues.
For example, the developer who built one feature might want to talk to another developer who is modifying that same feature because he or she has insight the other developer might not have.
Your first contributions: Small bug fixes
The next task the development team usually assigns to junior developers is a few small bug fixes. Initially, the bug fixes will be pretty simple to solve. Think things like:
Typos on landing pages
Fixes that only involve 1-5 lines of code
After you make a simple change to the application, your code will undergo the normal review process that every other team member’s code undergoes. Usually, one other developer will go line-by-line through the changes and make comments about better ways to do things, improvements, and potential problems the change could cause.
Having a code review ensures that even if you do ship code with a bug, you’re not the only one responsible for the problem. The other developer, who signed off on the code, is partially responsible for the bug as well.
If you’re working at a small company, you can expect your first contributions to be live within the first week. If you work at a bigger company, it can take a month or longer for your first changes to be shipped for the world to see.
The team will slowly ramp up the complexity of the features you’re expected to build.
Pair programming on larger tickets
In the course of your first weeks as a junior developer, you will end up pair programming with a senior developer who is working on a complex feature. What that means is the senior developer will usually sit in front of the keyboard and type out code, and you will watch the code they type. As they code, you can point out potential problems with their code (like typos they might make) and ask questions about why they’re doing certain things.
After your first weeks: Sprint planning
Most development teams plan out which developer is going to work on which feature either once a week, or once every couple of weeks. The process is generally called “sprint planning.” As a junior developer, you will attend the meeting and learn the process.
The process happens like this:
First, the features, bug fixes, and pieces of work are “pulled in” or selected to be completed within the next X working days (called a sprint).
Then, the development team will go through each of the items and assign a developer to each ticket, laying out the responsibility for getting every ticket done.
The more senior developers will generally push the junior developers to be responsible for the smaller, easier tickets. As the weeks go by, the complexity of the changes that you are assigned will slowly ramp up.
Some ambitious junior developers will quickly tire of the gradual increase in complexity. Because anyone can volunteer for any ticket, ambitious junior developers can ask for a ticket outside their comfort zone.
If a junior developer volunteers for something very complicated that must be finished quickly, it will likely be assigned to a more senior developer to ensure it’s done quickly and correctly.
If the time frame for the feature is not a big deal, the junior developer will be allowed to work on the ticket. But it’s not uncommon for it to be two or three months before the developer will work on the more complicated issues (these issues are sometimes epics).
Career growth: How to get the word “Junior” out of your title
The first few weeks of your first job will probably feel a little overwhelming as you’ll be learning an important skill: how to work on a team of developers that professionally codes 40 hours a week. This means understanding the different relationships and meetings, figuring out who enjoys pair programming (and who does not), and just being part of the team.
The members of your team likely have strong relationships with each other, and becoming a member of the team will involve building relationships with the other members.
But after a month or so, most developers get in the swing of things and everything gets a lot easier. At that point, you’ll likely realize that the next step in your career is to stop being treated like a junior developer, and to instead become a peer of the other members of your team.
To be treated as a peer instead of a junior developer, you’ll need to start acting like one. So a month or two in, you’ll want to start acting like the other developers on your team:
Always complete the work you’re assigned in the time frame you indicate you can. If you cannot, communicate the fact early.
Ask for help less, and start offering to help people out.
Volunteer for large programming tasks and start to “own” certain aspects of the codebase. (In other words, gain insight on certain sections of the code that nobody else has.)
When many developers are learning to code, they think they’ll need to be at this “mid-level” developer status on day one. Instead, your job as a junior developer is to learn, grow, and eventually lose that “junior” in your title. Your goal should be to grow to a level where you’ll be able to help out the next junior developer the team hires.
Getting to this level where you are on par with the other developers on the team is a process that generally takes junior developers anywhere from 3 to 6 months.
Because the company is investing in the long haul, often times the best developer isn’t hired for the position. Things like having more drive to learn and be mentored, and open-mindedness to different approaches to solving programming problems are often regarded as more important than actual skill. That means that as a junior developer, highlighting these character traits is important.
This also explains one of the reasons why most companies don’t care about a candidate’s experience with a particular programming language, but instead care more about their general ability as a programmer and facility to learn.
The path to your first position as a developer might be easier than you thought! The process is much less scary than you may have initially imagined— you don’t need to “trick someone” into believing you’re more skilled than you are.
AuthorKen Mazaika
Ken Mazaika is the CTO and co-founder at Firehose. Previously, he was a tech lead at WHERE.com (acquired by PayPal) and a member of the PayPal/eBay development team in Boston.