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.
