Are you on the hunt for your first job as a junior developer? Is the response to your job applications below your expectation? Whether you’re a graduate from a coding bootcamp or an accredited educational institution, many folks are surprised by how difficult it can be to get started in the industry. After all, you were informed that people with tech skills are in high demand. That statement isn’t false, but that doesn’t imply you won’t encounter competition when applying for your first job as a technologist. So how do you stand out? That’s where I come in. I’ve been the hiring manager of tech based roles for over a decade. Over that span I have seen hundreds of cover letters, resumes, code repositories, and personal websites. My hope is that I’m able to impart some wisdom on how to enhance your submission for junior developer jobs.
Tip 1: The importance of README files
Most code repositories don’t have a README file. Why is that important? There are a slew of reasons, but I’ll solely focus on those related to job hunting. A good README file provides general insight into the code base and, if applicable, the problem it’s trying to solve. It also demonstrates that you naturally value high-level documentation. Authoring documentation isn’t sexy, but whether you like it or not, it’s a key component to being a good technologist. It will be a requirement throughout your career in tech. Lastly, and perhaps most important, the absence of a README file practically guarantees the code repository will be ignored by the person reviewing your job submission. Why? You have to understand that when a hiring manager schedules time to review job submissions, they may only have a set amount of time to review a set amount of applicants. For example, I may only have thirty minutes to go over 10 applicants. That implies that I have three minutes, per applicant, to look at a resume, personal website, and code repository. If your code repository doesn’t have a README file, I usually skip it. From conversing with colleagues in similar capacities, most do the same. The exception is when a candidate is a referral from a friend/co-worker. It isn’t because we don’t value your submission, but the tendency tends to be that if there’s no README file, the code most likely won’t be properly commented. That leads us to the next tip.
Tip 2: Comment your code
What does “beautiful code” mean to you? When it comes to how you interpret that, if code commenting isn’t part of your definition, then you’re at a disadvantage. If time wasn’t a constraint, somebody reviewing your code could figure out your uncommented code. Again, it isn’t a matter of your code being too difficult to decipher, but rather the lack of time to do so. When it comes to applicants for a junior position, if I encounter a repository with thorough and consistent code commenting, I spend more time looking at the entirety of their submission (resume, personal website, etc.). How do you know what to comment while not going overboard? A simple rule of thumb is whether you’ll remember the objective of a code snippet, six months from now, if it lacked proper comments.
Tip 3: Finish projects highlighted in your personal website and/or resume
This happens quite frequently and it baffles me. Incomplete projects show a lack of follow through. If you’re going to list a project anywhere in a job submission, make sure it’s in a semi-complete state. Most projects from candidates applying to junior roles focus too much on the login mechanism and not enough on the rest of the project. Realistically, as a junior member of any team, it’s very unlikely you will touch the login mechanism early on in your career. Thus you should spend more time on the rest of your project…UI/UX, functionality, form factor, and most important, ensure that your interface behaves as expected across all major browsers. That isn’t to say that your login mechanism isn’t important, but it should definitely bare the same weight as other aspects of your project. If you’re unable to institute a working login mechanism, do yourself a favor and eliminate that functionality. It may have been critical during your bootcamp, but the lack of a login/registration mechanism isn’t something a person reviewing your job submission cares that much about. If you’re unable to complete other aspects of your projects, it may be in your best interest to figure out why you’re incapable of doing so, for it may be something that comes up during the interview process.
Tip 4: Blog about your passions, whether tech related or not
This isn’t a necessity, but I do love reading thought-out blog posts from junior candidates. Your writing can provide insight into several elements that may be critical to a role. For example, problem solving, passion, perseverance, and personality are some general traits that can be construed from a blog post. I particularly enjoy reading stories along the lines of “I solved X and this is what I learned.” Other blog posts that may be of interest to those reviewing your job submission,
- How you collaborated with others on X.
- A detailed account as to why you’re passionate about X.
- Your thoughts on a particular framework or programming language.
- Your struggles with a problem that you were ultimately able to conquer.
Again, writing blog posts isn’t for everyone, but it can certainly help you stand out from the crowd.
Do you have any tips for junior developers venturing into the tech world for the first time? If so, I’d love to hear about them in the comments.
Top comments (1)
Thanks for this, I’m currently struggling my way through this process, luckily I do write a masochist readme for all projects even small, and comment lots all through my repos.
Off to a good start hopefully