When you start out, things seem pretty simple. You’ll start applying for jobs when you feel comfortable to do so. Somebody tells you HTML is important, so you learn that. CSS is related to HTML, so maybe you learn that too. You feel like you’re on fire! You’re great at this stuff! But then there comes a point when it feels like every step forward is 2 steps back. You start to gain awareness of the vast depth of knowledge you don’t have.
Maybe you’re not as good as you thought after all?
At the beginning, you’re much like a toddler – ruling your household and in control of everything within your domain. But then, your parents open the door to the outside and expose you to a whole world outside. That world is scary, and you go from being someone who is completely in control and comfortable in their environment to someone who is helpless and insignificant in the grand scheme of things. Many people say they feel this way when learning to program computers.
On week #1, you’re coding with gusto – ready to conquer the world, and confident you’ll be ready to crush it in no time. After a couple months, you start to realize you’re not in wonderland anymore. You become aware of how deep the rabbit hole really goes down – although you don’t even fully understand the rabbit hole yet.
“You’re telling me I should be comfortable to start applying for jobs soon? Are you kidding me?”
So when will you be ready to get your first job as a junior web developer?
First, let’s zoom out and talk about the big picture that you’ll need to understand to land your first job. Then we’ll talk about the details.
The High-Level Approach You’ll Need to Take
In most situations, you’ll get hired based on two criteria:
First, you’re able to bring value to the team and help the team achieve their goal.
Second, the people you’ll be working with will like working with you.
And that’s it! So it should be a piece of cake to get a job!
In order to get a job as a programmer, you will need to reverse-engineer the outcome that you’re going for. That means all the energy you spend coding should be focused on accomplishing those two criteria.
Let’s hone in a little and talk about the second point. There are certain characteristics that make a person likable. People like people who are funny. People like people who are smart. But there are a couple traits that you will need to over-index during a job interview, and smart and funny aren’t what employers are looking for.
Honesty and authenticity are the personality traits potential employers want to see most throughout the entire process.
The fact is, “I don’t know,” is an acceptable answer to a question. Don’t lie. Don’t make something up. The probability of you randomly guessing the right answer is so small, but the damage it does to your character is so high.
If you lie about some random fact that doesn’t matter in the grand scheme of things – how can anyone trust anything that you say?
So instead of slick-talking your way through the answers, having an honest and genuine conversation is how you need to proceed. And you’ll need to be comfortable saying, “I might not know everything that’s out there, but I’m curious enough that I’ll try to learn, and I am someone who can bring value to the team.”
If you’re upfront, you can say things like, “I’m not sure, but I can tell you how I would guess it works if you’re interested,” and walk through your problem solving abilities— one of the things that matters the most— without the potential damage to your reputation.
The key takeaway is to be humble and honest in the interview. As soon as you show a hiring manager deep-down and honestly that you can bring their team value, you’re ready to start looking for a new position.
So How Can You Bring Value to the Team?
Given the massive depth of knowledge you’ll need to pick up about programming before applying for work – you’ll want to stay focused and attempt wholeheartedly to get the specific abilities you need, although surprisingly, there are few things that matter.
These abilities – although abstract – will allow you to bring value to a team. All the other skills are a lot less important.
You Need to Be Capable of Solving Simple Problems on Your Own
There are certain problems that are easier to solve than others. Think about features like changing text on a web page, or making a link go from one place to another. Really what we’re talking about here are tasks that can be done with 1-4 lines of code that aren’t incredibly complicated.
As a junior developer, you should be comfortable solving these problems. They might take you longer than someone who has more experience, but you should be able to solve these problems on your own.
You Need to Be Capable of Breaking Down Medium-Sized Problems Into Simpler Ones
There are certain problems which, while they might sound like a lot of work, are really just a lot of simple problems strung together that you’d easily be able to solve. They are usually phrased a bit more abstractly: “As a user, I expect to have the last page I visited be displayed on my user profile page.”
This task can break down into:
- In the database, add a field for the last URL a user visited.
- Between each request, store the URL the user visits in the database.
- Add a link to the page the user last visited to their profile.
Each part of this broken-down problem is a task that most self-sufficient programmers would be able to solve. Most of the tasks junior web developers tackle are either small details, or things that break down into a few different small problems.
You might not know the way to do things right off the bat, but someone who is self-sufficient would have the ability to figure it out.
You Need to be Comfortable Working With Code You Didn’t Write
Generally, if you’re working together with a team of engineers, there are a lot of other developers who are working on the same codebase as you. Because of this, other developers will write code that you personally didn’t take part in and might not fully understand up front.
This means that one critical skill on the job is learning how to understand and read other developers’ code. Reading code you didn’t write and figuring out the “what” as well as the “why” is an important task.
Hopefully, this code is well-written, well-tested and makes sense. But in the real world, nearly all projects will have a bit of code that is poorly written, untested and makes no sense. (In most cases, the author of the code will agree with you on all accounts.) Getting comfortable reading code you didn’t write – if it was at least written in a reasonably sane way – is an important skill of a developer.
You Need to Be Capable of Being a Productive Member of the Team
This means you don’t cause the other members of the team headaches. The team follows certain processes, and they expect that you will follow the same processes as well. The team expects you not to cause unnecessary drama. The team expects you to work genuinely with others and help your co-workers solve problems, even if you don’t need to and nobody asked you to.
That means if the team has decided that they will test their code, you will too.
That means if the team has decided to have a short meeting every day at a certain time, you’ll be there.
Really, this is all about conforming to the team. Usually, they’ll want you to act as a member of their agile team.
Skills You Don’t Need to Have
Generally, junior-level engineers aren’t expected to solve every single problem that presents itself to the team. There are many abilities that junior engineers don’t need to have, and aren’t expected to have.
You don’t need to know how to solve massive problems
As a junior engineer, you won’t be faced with seemingly insurmountable tasks like, “build a song identification app like Shazam – run with it.” Breaking massive tasks into large tasks, which are then broken into medium tasks isn’t what you need to be worrying about.
Instead, you’ll need to keep your head down and focused on the tasks and tickets that are in your court. Initially, the team will trust you with small tasks. Quickly, you’ll start working on medium tasks. And then eventually, you’ll begin grabbing bigger and bigger tasks, and before you know it you’ll lose that “Junior” word in your title.
You don’t need to know how to do it perfectly right away
Many times as a junior engineer, you’ll propose a solution to a problem and a more senior engineer will propose a much better way to do it. Maybe it’s faster. Maybe it’s fewer lines of code. From a high-level standpoint, you got the solution right, but some of the details might not be perfect. That’s okay.
You don’t need to know exactly how to do things perfectly at first – that’s why other engineers will review your code before it’s accepted. But, what is important is after getting the feedback, you can take it and improve your solution while also learning from it. The next time you face a similar situation, you shouldn’t be making the same mistake again.
You don’t need to do it all by yourself
Asking for a little bit of help is a good thing – in employees both junior and senior. Rather than acting like a know-it-all and someone who disregards other people’s opinions, you should be proactive and seek out the feedback and help you need when you need it.
You should consider asking for help a strength, not a weakness, but you need to make sure to learn from every answer you get. Just like responding to feedback about your code, once you ask a question once, you should take note of the answer and be sure not to ask the same one again.
So when will you actually be ready to be a junior developer?
This is a pretty straightforward answer. You’ll be in a position to be a junior developer when you feel like you can honestly say:
I am capable of solving simple problems by myself. I can break problems into smaller, more manageable problems, which I can deal with on my own. I’m comfortable reading code I didn’t write, and I’m comfortable working on a team, knowing I won’t step on anyone’s toes, and if I do, I know how to work it out with them. This is something I 100% believe, and while I might not know [whatever buzzword], I feel confident I will add value to a company – and learning [whatever buzzword] is something I am willing to do if I need to.
So when will you feel comfortable looking for a position?
The answer, which will disappoint you, is probably never. At least not until you’ve been working at a company as a developer for a long period of time, and have a track record of being able to get things done.
And it’s not because that’s how long it takes to master some hyped technology out there. It’s because that’s what it takes to grasp the fact that you will never learn everything there is to know about this programming thing. There’s just too much stuff to learn.
Instead, the process is all about being able to be productive in a world you don’t fully understand. There’s chaos in this world. And bugs. And nobody really fully understands it. People who know more than you will try to help you learn, but everyone has limits to their knowledge.
Given the way software is built, it’s amazing that anything on the Internet is working at all. If you’ve never written software for a company, you probably think the process is a lot like launching a spaceship. First, from a laboratory, the ideal solution is crafted up by meticulously taking measurements, building a prototype, and running a series of complex tests on the prototype— then you can engineer the rocket. Then the rocket will be built, and you can launch it and celebrate the success.
The fact of the matter is, at first, nobody is ready to careen downhill in a broken go-cart going 45MPH with nothing but duct tape and WD-40 to fix it. You can spend years studying the properties of different brands of duct tape, and all the novel ways to use it. Though you might figure out how to make the raddest vest out of duct tape – it’s not going to help you when your tires blow out:
In this way, the feeling people wait for to start putting themselves out there is one that isn’t going to ever come. You might think that if you learn AngularJS or the latest technology that Rube Goldberg wrote, it will make you feel more prepared. It won’t, and instead you’ll just be more distracted by the fact that you don’t know some other unimportant detail.
This means that if one company tells you no, you shouldn’t take it personally. Instead, you should have the self-confidence to keep going, when other people would have given up.
When You Start as a Junior Developer, You’re Not Expected to Have All The Answers
So don’t act like it. Feel comfortable being vulnerable and honest. Feel okay going outside your comfort zone.
Inaction is one thousand times worse than rejection.
If you think you’re in a position where you’re able to break down problems and contribute on a team, and you are a self-sufficient developer, you will be able to hit the ground running from day #1 at a company and you should start putting yourself out there.
Ready to start your journey to becoming a web developer? Check out our free 2-week Software Engineer Intro Course.