Getting Your First Job As A Junior Developer: The Psychological Perspective

About the Author: Gilad Shoham - Dev and open source leader at bit (one of the largest open-source JS projects with +13K stars on Github) has spent the last 15-years in the industry, has held every role from Jr. Dev, Team-Leader, Sr Dev, to his current position. During this time Gilad has conducted hundreds of interviews, for every position, junior to senior, tech-hubs all over the world. (Israel, USA, +other) 

Congratulations, you’ve finished your studies to become a software developer. No matter if it was MIT or FreeCodeCamp - you’re onto the next challenge: finding your first junior developer job. Despite having sent a myriad of resumes, Linkedin messages, and posting your portfolio all over the web - you’ve received no interviews. Bummer.

This guide will present practical advice to overcome this common scenario facing Jr. devs, and likely even be relevant to mid-career & senior-level developers. By following these tips, and organizing your effort according to this strategy, I believe you can increase your chances of scoring the job by at least ten-fold. Lastly, having tread this ground myself, I understand & empathize that you’ve already put a lot of effort into your studies, but be warned: you're not out of the forest, yet. Finding a job is a full-time job, so it’s important to allocate your efforts efficiently and effectively. 

Please keep in mind my background: I’m a developer and leader, thus, I’m advising the adoption of these strategies based on my experience and perspective as a technical interviewer. Often regarded as the most intimidating part of the hiring process, during the technical interview, the candidate meets and undergoes evaluation by a delegated member of the dev-team for knowledge and skill-compatibility.  The following are my opinions on the best practices to pass this stage of the hiring process.

The Team-Leader’s psychology when hiring Juniors

First, there is a limited amount of meaningful data on which to evaluate Junior candidates. By data, I mean lines of code written for production-level projects. As opposed to seniors, having written many thousands LOC’s and have clearly delineated contributions to real-world projects, a junior’s work is undefined, thus, the qualities a Team-Leader is looking for are vastly different. So what are we looking for in a Junior? In a word: Potential. What is this potential? And how do we measure it? We’ll break down potential into Professional and Soft-Skill aspects.

Professional potential includes:

• The pace of your progress 
• Your upper limit 
• Ability to be independent. 
• How much time our senior developers need to invest in you.
• When you will start providing value 
• Level of code (incorrectly formatted, buggy code requires resource-intensive rewrites)
• Long term placement in the company a few years from now.

Soft Skills considerations include:

• Are you someone we will enjoy working with?
• Will you be a good mentee?
• Are you responsible, or do you cut corners?
• Do you know to receive feedback, and learn from it?

But how do we know these things? Good question! When I interview juniors, I try to find how passionate and motivated they are. And try to test how “gifted” they are. 

Despite this, hiring a junior is always a gamble. This is the fundamental psychology that drives the junior-hiring process. Beating other candidates requires you to augment the equation in your favor, maximizing the company’s upside while minimizing risk. 

Augmenting the equation in your favor - What to do:

A) Publish a real side project

Software development, while powerful and open-ended, are merely tools. The most important factor is the ingenuity of the craftsman. 

Thus, if you have an idea - start working on it. Working on something that interests you will give you the motivation to work on it, and ultimately provide a much better result. Publish your progress as a public repository on GitHub!

Cover and publish as many of the development steps as you can - from design, implementation, & UX, to Testing, CI & deployment. Publish and share everything. Did you compose a design document? Publish it. Did you draw a diagram of your project’s architecture? Publish it.

When hiring, Github Project Repositories are the first thing I investigate. Your side-project shows me your motivation, and what you love developing. I can see into your process, style and finished product.

Most importantly, I have real code-samples to look at! Lastly, I can see your attempts, failures, and how you dealt with them.

I recommend every beginner have a side project you’re enthusiastic about.

Choose a problem that you, or someone close to you, are experiencing, and build a product you’d use personally to rectify it.

It’s important to have a personal relation to this project, since:

1. You have a deep understanding of the problem, and a desire to fix it.
2. You will have the motivation to develop and maintain it. Generic projects are typically abandoned by Junior developers once hired.
3. You can explain it from the ground up. What were the needs, solutions, and why did they solve this problem.

B) Participate in an open-source project

Participating in an open source project is a fantastic way to learn new things and improve your skills. When you contribute code to an open source project, you’ll have the best developers in the world reviewing your code and giving you feedback, for free. It’s priceless. However, finding & contributing to an open source project is not an easy task. First, there are hundreds of OSS projects. I recommend finding a project that you are using during developing your side project. Since you’ll already know this project as a user, you’ll have  much better context about:

1. Why is this OS project interesting to me?
2. What is the purpose of this project? What problem did it solve?

After you have few potential OSS projects, go to their home repository & investigate how to become a contributor. Consider these factors:

1. Is the setup easy?
2. Is the documentation for new contributors detailed and complete?
3. Does the maintainer accept and promote new contributors? (by being responsive & welcoming & by reviewing Jr. Developers’ code)
4. Do you have the technical skill required for meaningful contribution?

Keep in mind that contributing to an open source doesn't necessarily mean code, either. You can open issues, comment on threads, help with Q/A for new releases, edit documentation and many other tasks required.  Infact, contributing can be very simple. Have you found a bug while using an OS-Project? Don’t be lazy - open an issue about it! Describe the bug well, being sure to include a clear way to reproduce it. You’re a contributor! Working on OS projects, you’ll meet great developers - a few may even choose to mentor you. An invaluable asset on the path of becoming a world-class developer.

As an interviewer, I glean a lot from your open-source contributions:

1. Code you’ve written for a real project.
2. Motivation for developing.
3. Your dedication and diligence
4. I know you’ve already started learning from the high-level developers.
5. Your progress and how your contributions evolved over time.
6. Your teamwork & how you’ve responded to comments on your issues or PRs.

C) Write a blog

Writing a technical blog soon after graduating your formal studies sounds strange to many new-hires I’ve mentored, usually quipping along the lines of “I’m not knowledgeable or experienced enough” or “I have nothing interesting to teach.” I completely disagree. Sure, you don’t have 10 years of experience; but neither do you need it. Here’s why:

1. The strategy here is topic selection: Focus on a small, nuanced topic at first and explain it clearly. Not all posts are deep-dives into the internal machinations of git. Rather, there’s lots of room for small, yet focused blog posts.
2. As a junior (looking for your first job or developing your side project) your challenges are very similar to that of other juniors. As such, these folks are eager to learn from another experience. Again, topical subjects are equally valuable and interesting, Not everyone is looking for heavy, complicated topics.
3. Write a blog post with yourself as the main audience. This will help you make commitments to learn a topic, and is also a great way to track your progress. Lastly, studies show that knowledge retention is above 90% while teaching material. Publicly publishing your thoughts on recent lessons will help you learn it much better. Furthermore, try embedding some code examples in your post, this cross-platform synthesis will have you advancing much faster than other methods.

Truly, writing a blog is easier, and far more rewarding, than most think.
Lastly, as an interviewer, I can gather an incredible amount of information from your blog.

1. Motivation, again.
2. Ability to communicate what you’ve learned & know (Critical when working on a team).
3. Work ethic.
4. Study process and methodology. 
5. How deep you’re going when learning a new skill / technology.

Highly recommended.

D) Presenting at Meetups

The resistance I get from juniors about blog-posts it’s nothing compared to the freight they display when I instruct them to present live at Meetups. 
Public speaking is the most-cited fear per capita, so I understand why. I, too, not many years ago, was afraid of public speaking - as such, my rule is not to push them. That said, being able to perform public presentations in an invaluable skill in the Tech Industry. So, if you’re already comfortable talking in public, you’re at an immense advantage. To address the oft-quoted rebuttal, “They won’t accept me.” I say: This is unequivocally false.

Having coordinated 100’s of meetups, I can tell you firsthand: it’s a difficult task to find speakers. Filling the card often requires vigorous recruitment, thus, anyone volunteering is given a look.

Secondly, there are tons of meetups, probably more than you think. Especially in Tech-hubs! 

If you’re living in one of these places, I can nearly guarantee there’s an opportunity for you. 

Lastly, understand: a nearly universal goal of meetup organizers is to help their community, and often will see giving juniors a platform as a promotion of such. You’ll find them to be much more encouraging than you may have imagined. 

Perhaps most importantly, though - being scheduled to present at a Meetup is a serious commitment, one which will force you to master and rehearse the topic at hand, thus greatly improving your fluency in whatever you have selected. Also, usually, it will give you access to a team who will help you deliver your presentation, a sizable perk indeed.

Finally, being a presenter is a fantastic networking opportunity; Which is doubly important as a junior, because people and companies are often looking for talented juniors, and might even offer you a position on the spot. Even if a job offer doesn’t arise, chances are, as you move around your local tech scene chances are someone will recognize you, recommend you, or perhaps even offer invaluable mentorship.

E) Participating in Hackathons

Hackathons are programming competitions where teams, starting from scratch, sprint to produce a POC / demo, often pertaining to a relevant, or charitable cause - such as helping the disabled, or lately, COVID19. Participating in a hackathon is an all-around great experience. Hackathons themselves are often very fun, social events, but are also very helpful in getting hired.

Here’s how:

1. Networking - Hackathons are rife with top-tier developers, some with vast experience and connections. 
2. You will better understand team-development and what is expected of the members.
3. Hackathon projects sometimes become long-term, viable products, which can present itself as an opportunity.
4. Hackathon achievements, especially winning, are fantastic resume pieces.
5. Projects (usually high-quality because of experienced team-members) can be mentioned on the resume, or at the interview.

Lastly: Participating in a Hackathon shows me, the interviewer, that you really like developing, and that you understand that development is a tool to serve a larger cause.

F) Expanding your network

Networking is always important. 

When you have a wide network, oftentimes your contacts will refer junior-opportunities to you. Most importantly, however, when you target a specific position to apply for, having someone on the inside pass your resume, along with a recommendation, is peerless.

This is perhaps the single best method for beating the Applicant Tracking System (ATS) algorithm. Getting human-eyes on your resume is half the battle, and if your resume comes with a personal recommendation, I automatically give your resume and projects more review time - thereby offering you a better chance to impress the hiring team. Also, a strong recommendation often leads directly to an interview offer.

Improving your network is guerilla warfare. You cannot afford to be shy.
Go to meetups & conferences and talk with people. Help others when you can. Join online communities. Github, Slack, Discord, anything relevant. Send messages. Spread the word among your connections that you’re looking for a job. 

Oftentimes, the best opportunities come from your personal network, not an agency or HR firm. 

To reiterate: Having someone inside your target organization is the most powerful tactic a junior can employ. Always look for this move. 

G) Find a mentor

Finding a mentor could be considered the most difficult item on this list to accomplish, but should you succeed, your effort will be rewarded in leagues. In fact, a good mentor is the single most valuable asset a junior can possess.

From your technical skill, interview preparation, code review, bug squashing, architecture guidance, to networking --- a mentor can help you with all these things, and more. Simply put, there is no replacement for one-on-one help with an industry veteran. There are many books written about how impactful mentorship is, and it’s the same for software development, if not more so.

During my career, I’ve heard many senior developers express their desire to give back and help others. Use the network you’ve built to communicate that you’re looking for mentorship. Be relentless in your search. 

If you manage to be co-opted as a mentee, be respectful and appreciative of their time.

• Senior developer time is a premium resource, often given for free to mentees. 
• Be sure to come prepared and on-time, ready to absorb the lessons and feedback.
• Set your agenda and share it with your mentor. If you’re asked to prepare something, do it.

Always think about what you can give back to your mentor. If you have another skill, offer it.

What not to do:

A) Put too much importance on salary

When looking for your first job, salary should be one of your lowest priorities.

I offer two considerations to support my assertion: short and long term. We’ll start with the latter.

As a junior, your main objective is to master your technologies and grow out of your junior title. 

The pay increases significantly; easily double-digit percentages, and oftentimes a full-doubling. A savvy junior will prioritize this, and pick a company where they can get mentored and grow. Having to do a variety of tasks, at this stage, is a significant advantage.

To prove my assertion in the short term, we’ll conduct some simple math.
Let’s assume the lower-echelon of a Jr Developer salary is X. A fortuitous salary offer would be about 1.3X, and the upper limit at about 1.5X. In most places, after about 2 years (usually much less, but we’re building in a safety margin) you can expect to receive about 2X. This is the premise of our equation.

For the initial 2 years period, having accepted X, instead of 1.3X, you will lose 24 * 0.3 = 8X. However, courting a better offer often takes 2-3 month, leaving a difference of 5-6X and costing 2-3 months towards doubling your salary. Thus, if you try negotiating, do so gently. 

Don’t blow the deal because of it. If you have multiple offers, choose the company where you will learn the most.

B) Put too many buzzwords on your resume

Please, you’ve just graduated -- those 50 technologies on your resume that you allegedly know? C’mon. 

As an interviewer, l can tell you:

1. It’s outright harmful to your credibility.  
2. Obfuscates what to focus on during an interview - hugely wasteful of my time.

So. Just. Don’t. 

Only write your best weapons: The tech you prefer to use, and really know.
If you’re uncomfortable answering technical questions about it during the interview - leave it out. 

Conclusion

There are many, many, ways you can improve your chances of landing your first job. Focus your energy strategically, and you will be rewarded.

The tactics above will help bold your knowledge, motivation and passion.

Always remember: The goal is to augment the company’s risk/reward equation to your favor. 

Our senior dev time costs a premium, we need a respectful team-member who’s ready to learn. Play nice, but play hard. 

I hope you’ve enjoyed reading, if you have any questions - tag me in the comments. 

If you found this useful: please share it with your friends. Last but not least - don’t forget to hit the love button, it’ll help others find it. 

((P.S. You are welcomed to say hi on twitter.com/shohamgilad ))

((P.S.S Coming soon: How to prepare for an interview ))