Table of contents
1
Who am I
2
Who is this book for
3
Required technical skills
4
Creating a portfolio
5
Creating a CV
6
Creating a cover letter
7
Online presence
8
Finding the job and applying
9
Handling the initial call
10
Solving the recruitment task
11
Handling the on-site interview
12
After the interview
13
Bonus chapter - proactive job search
14
Resources
1
Who am I?
About me
You may be wondering why you should listen to my advice.
Actually, I hope you’re asking such a question. There are
thousands of sources to get front-end knowledge, and your
time is precious, spend it carefully.
I’m a self-taught front-end developer with six years of
programming experience. For the last three years, I’ve been
responsible for recruiting junior front-end developers to my
company.
My path to programming was a bumpy one. From the kid
discouraged from pursuing the career by people claiming that
my mediocre mathematical skills are not enough, a serial
reject from junior front-end positions, to the software
developer and eventually co-owner of a software house.
I was on both sides - candidate and interviewer. I was rejected
from junior positions, sometimes in a humiliating way. That was
hard. And that taught me how to apply. How to create a
convincing resume, how to study and present yourself in a
positive light. How to win the interview game.
After a few years in the software development industry, I
started to interview the candidates. I learned the most
common errors the candidates make. The things that make
recruiters reject them. I learned what differentiates successful
candidates from unsuccessful.
Enough about me. It’s time to start thinking about you.
2
Who is this
book for?
Who is this book for
The sole purpose of this book is to help you find a front-end
job. It may be your first job or the second one, the critical thing
is that it covers the steps for junior roles. Higher-level positions
have different requirements.
There are many books on similar subjects (I'll recommend
some of the best in the resources chapter) but what makes this
book unique is that it focuses on junior roles. Landing first job
is a unique experience - the criteria are often different than for
more experienced developers. That's why most of the typical
advice you can find may not work for you or even waste your
time.
The book revolves around web front-end jobs. When applying
for mobile front-end positions, you can use my advice, but the
details (especially the tech stack you need) will vary slightly.
Keep in mind that this book is especially beneficial when
looking for a job in a smaller and middle-size company. This is
because I combined my experiences with the experiences of
other recruiters working in companies of different sizes, but
generally not the biggest ones. This book is the essence of this
knowledge.
Recruitment processes for FAANG (Facebook, Amazon, Apple,
Netflix, Google) and other giant companies are different. So
often, it's good to have a book or tutorial precisely prepared
for the company you aim to work for. That being said, I'll cover
all of the typical recruitment process's possible steps, even
those used only in big companies.
The good news is that most jobs you can reasonably expect to
find as a junior front-end developer are in smaller companies.
“
Front-end is new.
It's been around
for around 20-30
years. And it's
moving fast.
Getting a job in FAANG without a degree requires you to
spend months preparing for the recruitment process. The
months you could spend on building applications and solving
real-life problems.
So my advice is to start with a smaller company. Even if you
dream about working at Google or Facebook, start small.
When you land a job and start getting paid to code, you can
switch your attention from getting a job to getting a dream
job.
This book aims to give you all of the tricks and tested
resources I know to make your recruitment process more
manageable. Your job is to prepare for everything they may
have for you.
Good luck!
3
Required
Technical
Skills
Required technical skills
Before you can start applying for junior positions or
internships, you need some minimum technical skills. The web
overflows with advice about what is necessary and what isn't. I
mean really overflows. Unfortunately, most of the advice is
based on misperception, information from typical job
postings, or a hunch.
In this chapter, I’ll outline which skills you actually need, which
are nice to have, and which can give you an edge to get a job.
Keep in mind the front-end is new. It's been around for around
20-30 years. And it's moving fast. The tools you're using now
will change. Being a software developer is a process of
constantly updating your skills and expanding your toolbox.
But there are some essential skills you'll need to get a frontend job in the foreseeable future.
Must have skills
Three technical skills are critical for every front-end developer
- HTML, CSS, and JavaScript. The common question is - what
skill level is enough to get a job. It will change from company
to company, but the rule of thumb is - you need to have a solid
understanding of those languages and the ability to write
them at least partially by hand. But you don’t need to know all
of the specifications by heart.
Your skills are easiest to assess in the case of HTML. To
become good enough in HTML, you have to know around 3040 most popular HTML elements and their semantic meaning.
You should know what element is semantically correct in each
use case and why it matters - that means at least partial
knowledge on accessibility and SEO. You should know the
basic rules of nesting - which elements can and can't be
parents of other elements. Also, you should create a few pages
using only HTML and see how they look in different browsers.
Knowing enough of CSS is a bit more tricky. After a week or
two playing with it, you may feel comfortable. At this same
time, after a year of working, you can suddenly discover you
know nothing about it. To know enough of CSS, you need to
create at least a few different pages. An excellent way to test
your skills is to try copying the sites you like (but no cheating,
don't copy their code, you can only get colors and images).
Other things you have to know are responsive design and what
properties are supported by browsers (use Can I use to check
it). You should also know and be able to name a few CSS
frameworks and methodologies.
It's hard to measure your JavaScript skill and know when
you're ready to start applying for jobs. But there are some core
concepts you need to know for sure. The critical thing for you
to learn is DOM manipulation. You'll probably use a framework
in your daily job and don't interact directly with DOM, but you
need to get this basic knowledge to work effectively. Some
other things you need to understand deeply are:
• Scope
• Closures
• Array methods (especially map and filter)
• Asynchronous JavaScript - promises and async/await
• Arrow functions
• Destructuring
This isn't, by all means, an exhaustive list. But it should help
you understand what's needed to use JavaScript comfortably.
Take into account these are the topics you have to know
deeply, not just read about them, but use them in real projects.
The concepts above introduce us to the final tech you need to
know to find a job - one of the JavaScript frameworks.
One and only one.
There's no point in learning multiple frameworks when you're a
junior. Find out what framework has the most job postings for
junior developers in your area and focus on that one. You can
always switch later.
How deeply you have to know a framework to apply for the
job? You need to feel comfortable building projects. It means
you should have at least 3-5 projects, and one of them should
be non-trivial.
Non- trivial project is the project you're proud to show others.
If you don't have an idea for such a project, we'll get to it in the
portfolio chapter.
v
Additional skills you can pick up fast
If you look at the job postings, you'll realize that four critical
skills are not everything they require from the candidate.
Luckily, you can pick up many of the additional skills fast.
For the interview purposes, it’s usually enough to know
something about them and be ready to dig deeper if
necessary. The most common of these skills are:
Version control - you should use version control (Git) in all of
your projects. It will give you enough knowledge to apply for
junior positions.
CSS preprocessors - you can use them or not; the crucial thing
is they're easy to learn.
CSS-in-JS - like the above, some people love it, some people
hate it. But it's pretty straightforward to learn.
Command-line - try using the command line from time to time.
Even simple things like creating and removing folders and files
will do. Also, try using Git by the command line.
Bundlers - you should know and use some of them, but it's
improbable you'll need to configure them by yourself as a
junior developer, so superficial knowledge is enough.
“
You need to have
a Git repository
and a portfolio
website.
Skills to stand out
Showing the bare minimum of skills is often not enough. To
attract attention, it's good to add something extra - the one
bit of skill that makes you stand out amongst other candidates
for the job. It's perfect if the skill aligns with the requirements
for the job, but even if it's not on the list, it's good to show
you're ready to go the extra mile.
Here’s the list of extra skills to consider:
Serverless - it's all the rage now. Serverless allows you to build
full-stack applications without backend knowledge, which can
enhance your portfolio greatly.
Accessibility is an area many developers struggle with;
empathy for the users is a good sign for any developer.
Design systems are gaining popularity, especially as the
competition grows, and delivering software as fast as possible
is crucial.
Testing - everyone talks about testing; nobody's doing it. If you
understand the value of tests and can implement them, you'll
be welcome in any team.
Performance - optimizing performance is a must in any clientfacing application. It affects SEO and user experience, so
every developer needs to take it seriously.
Design - everyone likes beautiful things. If you can make your
portfolio eye-catching, you've got a great chance to be
4
Creating
a portfolio
Creating a portfolio
Your portfolio is a critical part of your job seeking. If your
portfolio is excellent and you'll get lucky, you might get an
invite for the interview even without sending an application.
And if you send an application and get through the first
resume review, an impressive portfolio is what lets you stand
out amongst dozens of other developers.
Software developers portfolio is made of two major parts - Git
repository and portfolio website. You absolutely need to have
both - one allows the recruiter to see your code, and the other
the final effects of your work.
Building great Git repository
Your Git repository is a record of your growth and the projects
you've made. It's a significant selling point, so you need to
make it work in your favor.
The best place to have your Git repository is GitHub. It's almost
an industry standard, and getting practice using it will come in
handy. To make your GitHub stand out, you should follow a few
rules. Firstly, make small, frequent commits. Some recruiters
look at your activity and seeing someone who commits a lot is
impressive. Also, making small commits is a good practice in
real-life projects.
Consider hiding your first projects and the projects you didn't
finish or are not proud of. As long as you have at least few
projects, it's better to show only your best work. If you don't
want to hide projects, at least pin the best ones. It will make
them stand out. You can find the instruction on how to pin the
projects here.
Remember each project should have a readme file. Include
technologies used, what the project is, and how to run it.
Always have the live versions of the projects, so anyone can
quickly see how it looks in action. Link to the live project
should also be in your readme!
The final thing you can do to improve your GitHub is to pimp
your profile. You can make it pretty by adding a readme file to
the root of your profile. Here you can find instructions for
doing this. You may add images to your profile page, links to
your social media, or add technologies you use. Treat the main
profile page as your developer resume - add anything relevant
(for more tips, check out the resume chapter of this book). You
can even add your GitHub stats or get your latest blog posts (if
you have a blog).
A portfolio website that stands out
The portfolio website should look good. Good is not equal to
fancy - its goal is to showcase your work, so the projects
should be the main focus. Go for the clear and clean design,
and watch out for simple errors (for example typos or lack of
favicon). Host your portfolio using some free solution like
Netlify. It's good to have a custom domain, so consider
spending a few dollars on getting it.
If you want to add some extra visuals like animations - go for
it. But make sure you don't overwhelm users. The visual clutter
destroys the excellent effect. Your portfolio is about
showcasing your projects, not impressing with every animation
skill you have.
The portfolio should be responsive and include a contact form
or a chatbot - you want to make reaching out to you as easy
as possible. Validate the inputs if you're using a contact form otherwise, some people will make fun of you by sending empty
messages.
The question I get asked a lot is whether you should use CSS
frameworks or not in your portfolio. The answer is - it depends.
“
Pick interesting
projects for your
portfolio!
Frameworks will make creating clear and responsive designs
easier. But if your special skill is being great with design, you
should go with custom design and CSS.
On the other hand, If you're focused on JavaScript and are not
skilled with design, you can go for frameworks and stand out
some other way. Your portfolio needs to impress somehow, but
it doesn't need to be a design.
As for the rest of the tech stack of your portfolio - it doesn't
really matter. Pick anything that works for you - it may be a
JavaScript framework, WordPress, or whatever else you like
using.
Always remember that the crucial thing in the portfolio are the
projects. Make them stand out, especially the ones you're
proud of.
Picking great portfolio projects
Picking interesting projects to your portfolio is a perfect way to
stand out from the crowd. I still remember seeing a simple
puzzle game in one of the portfolios - our entire office started
to play it. We invited the person to the interview without a
moment of hesitation.
Your goal is to do this same - build something impressive
enough for the company to invite you.
Avoid making apps that everyone does - weather apps, tictac-toe games, or to-do lists. They're great projects to learn to
code but not good enough to make into a featured app in your
portfolio. You need to be more original.
If you attended a Bootcamp, you probably had to build some
final project. As a rule of thumb, avoid using this project as the
main thing in your portfolio. Bootcamp projects tend to be
inspired by teachers, and because of that, they're often
repetitive. In my experience, I could recognize the Bootcamp
projects at first glance - many candidates were finishing these
same Bootcamps with similar projects.
That being said, if you believe your project is unique or you
added a lot of great features, feel free to feature it.
To find an idea for the great app, think about the things you're
interested in. Are you a lover of Netflix? Make a Netflix clone
or a movie database like IMDB. Like playing card games?
What about writing a poker game in JavaScript? Interested in
investing? Build an app with stock data visualized as charts.
You can easily find a free API to get the data about almost
anything; check this or this list if you don't believe me.
An additional benefit of picking the project that’s interesting
to you is that you won't be discouraged easily. So choose
wisely.
The other way to make a great app is to solve someone's
problem. Maybe you've got a charity you like, but they don't
have a website? Make it for them. They will get a great new
page, and you can add testimonials to your portfolio. Nothing
sells better than other happy customers. The possibilities for
new apps are endless!
If you need some more project ideas, here's the list of websites
that can inspire you:
https://www.frontendmentor.io/
https://github.com/florinpop17/app-ideas
https://github.com/tastejs/awesome-app-ideas
https://github.com/karan/Projects
You don't need to have many projects in your portfolio - the
recruiter will probably just glance at it. The tricky part is to
make the projects really great. Make sure to have a clean
design and make it responsive. Give the users the best
possible experience irrespectively the device they use.
Pay special attention to the quality of your code - remove
obsolete comments or console logs. Test your application in
Lighthouse - try to achieve perfect or near-perfect scores in
every category. Check out the quality of your HTML using tools
to analyze the semantics of the page like W3C Validator.
Don't forget about the social media metadata. You want to
share your portfolio on different platforms, so make sure that
the links look beautiful.
These may look like tiny details, but they matter.
When you've picked and coded your best projects. It's time to
present them.
For every project, you have to make a description. It should
contain information about the tech stack you picked and the
project functionality. If your project has some additional
features, like tests, add information about it. This same would
go with external libraries; if you used something complex, like
D3.js, write about it and justify your choice.
It's also a good idea to highlight what you've learned in the
project. If you're building a single-page application, you
probably had to master client-side routing. If your app uses
some external API, you've learned to handle asynchronous
requests. Whatever it is, write it.
5
Creating
a Resume / CV
Creating a CV
You may think that CVs, or Resumés are obsolete now.
Especially for the software developers, their skills should be
more important than their education or previous experience.
And in truth, skills usually are more important, and you're
accepted or rejected based on them.
That being said, unfortunately, resumes (or CVs, I'll use the
terms interchangeably) are still the starting point for many
companies. You won't get through the initial screening (done
by the machine or a human) without the resume.
So like it or not, you have to know how to build a good CV.
Going through computer scan
Many companies, even smaller ones, use the applicant
tracking systems (ATS). They're used to track applications, but
what's more important from your perspective is they're often
used to do the initial screening of the candidates. ATS job is to
filter CVs so the recruiters will see only the most relevant
candidates and save time.
So your first goal is to make your resume ATS friendly - you
need to get through initial filtering to have a chance of
landing a job. To outsmart the algorithm, you need to know
how it works - it looks for the candidates who meet the most
criteria from the job posting. So your task is to make yourself
the best candidate for the job.
“
Have someone
else read your
CV/Resume.
How can you do it?
Firstly, look for the keywords. Every job posting has several
requirements - it may be technologies used or personality
traits. Try to include as many of them as you can in your
resume. Of course, you have to be honest; you can't just
fabricate the skills. But make sure you include everything you
honestly can from the job description. Remember to use exact
words - if in the job description they're looking for the
JavaScript developer, don't say you’re a JS developer - say
you’re a JavaScript developer.
The above also means you can't use one CV for all of the
applications - you have to tailor it to the specific job.
You may have heard advice on how to "fool" the ATS - for
example, by copying the keywords (or the job description) in
white text. Don't do it. In the worst-case scenario, the software
may ban you from all of the future recruitment processes, and
in the best case, the recruiter can notice it and judge you as a
dishonest person.
To make your CV ATS friendly avoid using images or charts.
They're difficult to scan for the machine, so using them can
hamper your chances of going through the screening process.
To make your CV easily scannable, remember to send it in the
proper format. Many job postings state the expected format,
but if they don't use .docx or .pdf. Don't send resumes in any of
the image formats, as they're hard to scan.
To make your resume better, you can use some of the online
tools that calculate an ATS score of CV. Using this information
you can improve your resume to get a better score. Some of
these tools are Skillroads, Jobscan, Resume Worded, or
Skillsyncer.
Going through people
Your CV is good to go through the machine scan, but now it's
time to optimize it for humans.
You'll find two types of people looking at your resume - HR and
technical staff. They may look at the different things, so you
need to optimize for both. Luckily, most of the tips below are
helpful no matter who's assessing your CV.
Your CV has to obey one central principle - the person who's
reading it will not devote much time. Some studies claim the
average resume is analyzed for 6 seconds. Whether it's true or
not, you can't expect anyone to devote more than a minute.
What does it mean to you?
Your CV must be clear, concise, include only relevant
information, and you can't have any errors. Make your resume
as clear and readable as possible. If you're not sure what
makes a CV easily readable, here are some basic guidelines:
• use at most three different font sizes
• use at most three different colors
• keep the most relevant information near the top
• make sure the sections are clearly separated from each
other (there is enough whitespace between them)
• the document flows from top to bottom (not diagonally or
sideways)
To avoid any typos, use a spell checker. Even small mistakes
look unprofessional and may make the difference between
being accepted and rejected.
You should improve your grammar and flow of the text. The
easiest way to do this is by reading the CV out loud. If the
rhythm of the text feels awkward or you stumble somewhere,
you probably found a great place to improve. Reading out
loud also helps to find chaotic and too-long sentences.
Writing is hard, and probably the first draft of your resume will
be mediocre. To help you cut out the confusing sentences, it's
good to give the resume to someone else. Ask if they can see
the most relevant information at first glance. Later ask them
to read the resume more carefully and make sure they can
understand everything.
When you're applying for a junior position, your CV should be
short. One page is almost always enough. At most, it can be
two pages, but it's improbable you've got so much information
to include if you don't have relevant job experience. The
recruiter doesn't need to know you're a certified chiropractic
or used to be an Uber driver five years ago. Include only things
that can help you.
When you add information about your education or job
experience that is not connected with IT, add some context. By
context, I mean extra information which highlights your
experiences/achievements or what you've learned. Maybe you
are a natural leader who runs a non-profit organization in your
spare time or a compassionate helper in the local shelter.
These are all good things to include. On the other hand, the
fact you like football is probably irrelevant.
The most important part of your CV are your technical skills.
List all of the technologies you know relevant to the job
posting. But don't list every single technology you've ever
seen. All of your skills have to be backed up by the projects
you can show. So the ideal CV has a list of technical skills and
a list of projects where you put these skills into practice. The
projects should have links to the live version and Git
repository. You can also add brief descriptions.
Your CV should include your email address (please, make it
professional) and links to the relevant social media accounts it's probably Twitter and LinkedIn. Still, there may be other
important social media in your country. The last part of the
contact info is a link to the Git repository.
As a bonus, here's the list of tools you can use to make a
beautiful and readable CV:
• Canva resume builder
• cvmaker
• VisualCV
6
Creating
a Cover Letter
Creating a cover letter
The first thing you need to know about the cover letter is that
you don’t have to write it.
Seriously. People who get hundreds of applications will not
read your cover letter. But sometimes, the job posting requires
you to write one, so it’s better if you know at least the basics
about writing it.
The critical thing for cover letters is - make them short. You
only need to write what position you are applying for, what you
are doing right now, and why you’re a good fit for the position.
The crucial part is where you explain why you should get the
job. Treat it like an expanded version of your CV, highlight how
you meet the requirements from the job posting, and any
previous experiences that allowed you to learn the skills
needed.
If there are some skills you don’t have, express the eagerness
to learn them. In general, the tone of your letter should be
enthusiastic and optimistic. You can also write a line or two
about what you find impressive about the company and why
you want to apply. But be honest, if they made an application
you didn’t even bother to download, don’t say how much you
like it.
If you don’t want to write a cover letter but still want to add
some personality to your application, you can add a short
description at the top of your CV.
“
Blogging will
make you
a better software
developer and
help you find
a job.
It could be 2-3 sentences that state your career goal or the
most significant accomplishment.
But beware of being cliche; in the resumes I receive, this part is
usually identical - everyone wanted to become a software
developer as a child, but something stood in the way; they
went on another path and started learning to code.
The above description may be accurate (it was true in my
case), but it’s so common that it doesn’t add anything
meaningful to your application. So unless you can write
something out of the ordinary, it’s okay to skip this part of your
CV.
7
Online
presence
Online presence
Being visible online is not necessary to find a job, but it can
significantly improve your chances. You can be active in the
programming community in many ways, and the relevant
social media can differ depending on where you live. In
general, in the US and Europe, the primary social media you
should be aiming at are Twitter and LinkedIn. Additionally,
you can have your own blog, be active in open source or
answer the questions on Stack Overflow.
Some of the ways of showing yourself online can be easier for
you than others. For example, I have had my LinkedIn profile
for years, and I updated it. But on Twitter, I started to post
anything just last year. It’s a huge missed opportunity cause I
could have a lot more success if I started earlier, but I just
didn’t feel comfortable on Twitter back then.
In this chapter, I’ll highlight the benefits of different social
media and give you some tricks on how to start. Picking which
social media platform to use (if any) is up to you.
LinkedIn
LinkedIn is one of the easiest ways to get a front-end job. If
you’ve got a good profile, there’s a chance recruiters will
contact you without having to do anything. And even if they
don’t, it’s good to attach a link to your profile on the CV.
You should treat LinkedIn as an expanded CV. Add every
relevant detail about technologies you know and skills you
possess. Ask everyone who knows you’re a great programmer
to recommend your skills.
Like on the CV, keywords matter a lot. Many recruiters will look
for years of experience, and you don’t have it. So focus on
adding all of the languages and technologies you know, so
you’ll tick every box you can.
Use the About section to write something about your goals
and skills. And remember to add links to your portfolio and git
repository.
Your profile photo should look professional. It’s good to use
this same photo in all work-related social media accounts. This
way, if someone notices your profile in different places, there is
a higher chance they’ll recognize you and want to connect.
It’s a good idea to have your tech stack in your headline. This
way, it’s enough to glance at your profile, and the recruiter will
know if you have experience with the languages and
technologies they need.
Active accounts get more traction, so you should post
everything work-related on LinkedIn. Share interesting articles
and the things you learned. LinkedIn is not only a CV display,
it’s a social media, so try to be social.
Twitter
Twitter is one of the places on the web where programmers
hang out. It’s more casual than LinkedIn and not as careeroriented. Its best advantage is that many great developers are
active there. You can follow them to get their insights, as well
as to check out the latest trends. What’s even better is that
everyone on Twitter is just a click away - you can send a
private message to anyone.
While following the prominent programmers can teach you a
lot, it is unlikely to help you much when seeking a job.
Fortunately, you can use other techniques to improve your
chances of getting a job. One that’s especially effective is
learning in public.
The main idea of learning in public is sharing your progress.
Every time you hit some milestone, even the minor one, share
an insight or two. You should also talk about your failures and
doubts. You’re very likely to find a group of like-minded people
who will help and support you in your learning journey. They
may offer a word of encouragement and advice or even
connect you with someone who has a job for you.
If you’re unsure how to start, look for hashtags with challenges,
like #100DaysOfCode, or look for your community like
#WomenInTech. I’m sure you’ll find your place, and by sharing
your progress, you’ll make many connections, some of which
may become valuable to further your career.
Blogging
I’m pretty confident you should have a blog. It serves so many
purposes. You can use it as a diary of your progress and
growth. You can learn a lot from writing about the things you
are learning. The process will solidify and organize your
knowledge. You can help others who face these same
problems. Maybe you’ll even find a job or build a community.
Just blog.
I didn’t start a blog until I was five years into my programming
journey. It’s one of my greatest career regrets.
If you don’t have an idea for the blog you can start with taking
public notes. They may serve you as a reference point, and
maybe help others who are struggling with these same
challenges.
I understand this advice is hard to follow. The internet is
overflowing with blogs, courses, and comments, so you
probably feel you have nothing to add, right? I’ve felt the
same way.
The trick is to treat writing as a tool for your learning — not as a
resource for others. If other people want to use your work and
find it valuable, that’s even better. But even if you’re the only
one benefiting from your teaching, that’s great.
Every time one of the candidates for a job in my company has
a blog I take a look at it. If it’s regularly updated the candidate
is almost certain to get an invite for the interview.
Open source and Stack Overflow
You may have heard that contributing to open source is great
to improve your programming skills. It is. It’s also an excellent
sign for your future employer — it shows you’re active in the
programming community, can use version control, and
understand the software creation process.
The best part?
No one is doing it. In the hundreds of junior developer resumes
I’ve seen, maybe a handful of candidates contributed to open
source. And guess what? They got invited to a technical
interview.
I know open source seems scary to junior developers. You may
have many doubts. How can you provide any value? Where do
you start? Will they judge you? Don’t worry; the programming
world is friendly and always happy to help beginners.
To help you get started, take a look at this GitHub repository. It
includes many tips on how to start and a list of beginnerfriendly projects. This guide will smooth your transition to the
open-source world.
This same goes with answering the questions on Stack
Overflow. It’s hard and may require a lot of time, but the
impression you’ll make by having upvoted answers at SO is
hard to beat.
8
Finding the job
and applying
Finding the job and applying
Looking for a job can be scary. Many job postings have a huge
list of requirements. It’s underwhelming, especially for junior
developers. But I’ve got good news for you - you don't need to
meet all the requirements from the job advertisement.
Often the list of requirements is bloated by HR or lack of clear
priorities. If you've got experience in a few of the main
languages/technologies, you're good enough to try. The
perfect job advertisement may never come, so take the risk.
Additionally, the more applications you send, the more likely
you are to succeed. Sending applications increases your
chances of finding a job and allows you to gain experience in
recruitment tasks and technical interviews. With a few of them
under your belt, you'll feel more confident and relaxed.
How to make an initial contact
You've found the job you want to apply for. Your stack is similar
to the requirements, and you feel you're going to be a good fit.
It's time to make the first step and contact the employer. The
first impression is crucial, so make sure you seem professional
and enthusiastic. Use the professional email address from a
trustworthy domain. Your message should be short and to the
point, but never send empty emails with attachments only.
Attach everything listed in a job advertisement. Usually, it's a
CV and portfolio. Even if there is no requirement for a portfolio,
add links to your GitHub and portfolio website. If you're
looking for a job, you should have an account on LinkedIn or a
similar site. Make sure to add a link to it.
If you need to have a cover letter, take some time to write it.
It's your chance to stand out, so never send an identical letter
to different employers. Do some research about the company
and description of the position you apply for. Use that
knowledge to highlight your most relevant skills. Remember to
keep your letter brief. They may no read it carefully, so don't be
afraid to bold the vital parts.
Always remember all the jobs you're applying for; it's helpful to
have a spreadsheet with all of them and the step of the
recruitment process you're in. It's also a good idea to add
some relevant notes. Someone from the company you're
applying for may call you, so you should be ready to discuss
the details, and there is no better place to store that
information than a spreadsheet.
One thing to remember is the job offers are everywhere - not
only on the job boards. You can find them on social media (like
Twitter and LinkedIn), Stack Overflow, or even HackerRank.
One final tip - the easiest way to get a job is getting a referral.
That's when your social media activity can help immensely. If
you make some friends online or get noticed, you may be
recommended to the company and skip many recruitment
process steps.
“
There's nothing
wrong with not
knowing the
answer as long
as you're
enthusiastic
about learning.
There are bonuses for recommending a good employee in
many companies, which makes it profitable for everyone - you
get a job, they get a premium, and a company gets a great
employee.
Keep that in mind, ask for referrals if you make friends, and
never underestimate the power of social media.
9
Handling
the initial call
Handling the initial call
(phone screen)
The phone screen is an optional part of the recruiting process.
Some companies want to do short phone calls to determine
two things - are you communicative, and do you have a basic
knowledge of the tech you're going to use in a daily job.
This is supposed to be a low-stress and low-effort part of the
process. The call should take approximately 15 minutes and
consist of two parts - general questions to make you
comfortable and basic technical questions.
This chapter will be short, as these same questions are likely to
be asked in the further steps of the recruitment process
(technical phone interview and on-site interview), and we'll
deal with them in more detail in the on-site interview chapter.
How to prepare for the call
Preparing your environment for the call is essential. You need
to be focused, and no one should interrupt you. Try looking for
a quiet place with a comfortable chair. Make sure your phone
is charged and your connection is of good quality. Don't do the
call hungry or straight after the meal - it will make focusing
harder. Also, go to the restroom before the call - usually, these
calls are short, but you never know if yours won't be longer.
Remember to read your CV and all of the communication you
had with the company before the call, so you don't forget
anything important (like your projects). Also, read a little about
the company - have an opinion about their products and be
ready for a question about them.
Consider dressing up; you may feel more urgent and
professional if not wearing sweatpants. During the call, turn
your computer off - otherwise, you'll be tempted to google the
answers, and if the recruiter hears you typing, you are already
lost. Try speaking professionally and calmly, take notes if
necessary.
General questions
When the interview starts, you're likely to get some general
questions. They should warm you up and make you
comfortable. But the recruiter will also want to reveal
something about you - what is your attitude towards coding,
this particular job, etc. They may want to know how you work,
what's easy and hard for you.
With every answer, you want to show you're a reliable person
who is fun to work with and is concerned about the quality of
the code. Also, try to be enthusiastic; they need to know you
want this job.
One of the dreaded questions you're likely to have at the start
is: "Tell me about yourself." You need to prepare for this one. In
the ideal answer, you should include:
• why do you want to become a software developer,
• what do you know, and what would you like to learn,
• why do you want to work for this company (and how it may
help you achieve your goals)
• Other typical questions you're likely to get are:
• What projects have you worked on recently?
• What is your specialty?
• What is the project you're most proud of?
• What do you know about our company?
• Why do you want to be with us?
• How do you stay up to date with the latest tech trends?
You should prepare answers to these questions. Usually, you
already have most of them in your CV - check it before the call
and be ready to praise your best projects and name the
technologies you used.
“
Ask your friend or
a family member
to do a mock
interview with
you.
Technical questions
Technical questions will require you to prepare a little more,
but they should still be relatively straightforward. The goal of
the call is a negative selection - it should find the candidates
who can't communicate or don’t know the basics.
So your goal is to get to know the basics. And that's quite easy.
Google most common questions for JavaScript/React/
Angular or whatever else is required for the job. The first page
of Google results will be enough. Later learn to answer those
questions. You don't need to memorize everything; just make
sure you can say two or three sentences about everything.
Some of the questions you can get for a junior front-end
developer role are:
• What's the difference between let, var, and cost?
• What is 'this' in JavaScript?
• What is event delegation?
• What is a prototype?
• What is a Worker?
All in all, the list contains probably a few dozen concepts you
have to know of.
In this part, you can also get some algorithmic questions or
questions about your coding preferences. Examples of these
questions are:
• What is a Stack and a Queue?
• What is a Big O notation?
• What was the last tricky bug you had, and how did you fix it?
• What features of the language you do/don't like?
When answering a question, you should stay positive. Even if
you don't like a particular feature or library, don't be blunt
about it. Just say you're using a different approach but are
interested in learning that one. Or that you don't have
experience yet, but you're eager to try. Staying positive is the
key!
If you don't know the answer to some questions, be honest.
There's nothing wrong with not knowing the answer as long as
you're enthusiastic about learning.
The questions on the phone screen are not supposed to be
tricky or deceiving. They should test your basic knowledge and
approach to problem-solving.
If you're getting questions about the trivia or some JavaScript
quirks (like is `!!([])` true or false) that's a huge red flag, and you
should consider if the company is worth your time.
Below you can find some of the best places with the
fundamental questions for the front-end developers:
https://github.com/h5bp/Front-end-Developer-InterviewQuestions
https://github.com/yangshun/front-end-interviewhandbook
https://github.com/sunil12738/frontend-developerinterview-questions
Ask questions
The last part of the initial call are your questions. You should
have a few of these prepared; it makes a professional
impression. Some questions you might consider are:
• How long is the recruitment process?
• How many steps it has?
• How big is your team?
• Are there other teams in the company?
• What is the culture like?
• What projects you usually work on?
10
Solving the
recruitment task
Solving the recruitment task
Some companies, especially the smaller ones, have an
additional step in the recruitment process - solving the
recruitment task. Usually, you'll need to implement a simple
algorithm or create a user interface based on the design. You
do it at home and have a reasonably extended deadline maybe a week or two.
...
These kinds of recruitment tasks are controversial in the tech
community. It usually takes some time to finish them, and
occasionally companies use this kind of task to outsource their
real work and use the applicant's code in their products. On
the other hand, these tasks are great for good developers who
are stressed when coding live. Also, the tasks you can do at
your own pace and with the help of the Internet are more
similar to real work conditions - so they may do a better job in
assessing the developer skills.
...
Whatever you think about the recruitment tasks, you may
need to do some if you want to participate in every possible
recruitment. To make sure you're not being used as free labor,
analyze the task you got. Does it look like something created
only for the recruitment process? Or maybe it's more like a
part of the application? How long will it take you to complete?
If it's more than a day, it's probably too much. Also, ask if you
can use the solution in your portfolio - they shouldn't have any
problem with it.
If anything is suspicious or you don't like the task for whatever
reason, you don't have to do it. Many companies are looking
for junior developers, and not every offer is good for you. You
can also email the company saying you can't / don't want to
solve the task but would love to have a phone or on-site
interview. They may agree; you never know.
Ask questions
The company should define your task as extensively and clear
as possible. But in reality, usually, there are some pieces of
information missing. It's not a bad will - it's hard to be very
specific in describing tasks. If you misunderstand your task,
you may spend hours or even days doing useless work. To
avoid it, use your special weapon - questions.
Make sure you understand what exactly you need to do and
what technologies you should use. Ask about the deadline and
how to submit your work. Find out what will be evaluated. Do
you need to make your UI exactly like a design, or is there
leeway? Should the UI be responsive, and what breakpoints to
use? Do they provide you with assets? If not, which ones to use.
If you have even a slight doubt about anything, you need to
ask. It saves time and helps you to provide exactly what's
requested.
How to solve a task
When you're sure you understand the task, execute it
accordingly. My main advice - do your best. I've met many
applicants who delivered sloppy code. When asked about it,
they said they would do better in a real job, but it's only an
exercise they didn't care about.
Instead of showing how good they are, they said they didn't
care with a straight face. As you can imagine, they didn't get
the job. And with this attitude, I doubt they ever became
decent programmers.
Your main goal is to make the code work according to the
specifications. But remember you'll be compared with other
candidates. So treat your code as a business card, take your
time to polish it.
Make your code as readable and easy to understand as
possible. Remove all of the console logs and other debugging
parts of the code. Remove the commented parts of the code
also. Your code has to be clean.
As far as the architecture goes - don't overcomplicate it. Try
going with simple solutions that do the job. Comment your
code where necessary - in fact, it's better to add more
comments than you would typically do. This way, you can
make reading the code easier. Don't import too many external
libraries unless it's required.
“
If you've got
enough time, it's
great to add
something extra,
some feature
that wasn't
required.
Add something extra
If you've got enough time, it's great to add something extra,
some feature that wasn't required. It shows you're involved
and ready to take the initiative.
Possibilities for extra features are endless. If you need to
choose one of the different algorithms for your code, write a
comment explaining why you choose that one. If you're
implementing UI - you can add some subtle animations. Make
sure not to go overboard - you're looking for light touches of
extra quality, not to show off with useless distractions.
Unit tests are always a great addition. So if you know how to
write them, add testing to your code. I'm sure this will impress
whoever is assessing your code.
When you send your solution, always ask for feedback. It
doesn't matter if you've aced the task or failed miserably. You
need the assessment from recruiters to grow as a developer.
Asking for feedback also shows you care about selfimprovement.
Treat recruitment tasks as a chance to learn something new
and get a job in the process. This way you can make it both fun
and useful.
11
Handling the
on-site interview
On-site interview
Here we are, the final step of the process. It will decide if you
land the job or not. On-site interviews are the most dreaded
part of the process - they’re stressful and demanding. But
they're also the best moment to show your technical skills,
personality, and attitude.
On-site interviews are almost always part of the process.
Sometimes they're supplemented by phone/online interviews.
The preparation and execution of phone interviews are
virtually identical to the on-site interviews. Still, I'll add some
advice specific to the phone interviews at the end of this
chapter.
General information
Every company has a different process for the on-site
interview, so you can never be sure what to expect. Luckily, the
main parts of the interview are usually the same. First, there is
a technical interview with some coding exercises or questions.
The second part is a behavioral interview, determining if you're
a good fit for the position. These two interviews can be
separate, but usually, one meeting is enough for both.
In the on-site interview, you'll be talking with one or more
senior developers. Sometimes there is also a person from
Human Resources present.
You need to prepare for both parts of the interview. Don't
assume that learning for the technical part is enough.
As a general guideline, keep in mind that your attitude
matters a lot. You should look eager to learn and be interested
in the company. Many recruiters will assess you in the first few
minutes, so a good first impression is critical. One time I
rejected a candidate almost immediately, as he was slouching
on the chair, seemed bored and disinterested. He could have
been a sound software engineer, but I was sure I would not like
to work with him. Don't repeat his mistake and stay alert.
Making a good first impression is hard, because in an
interview, you're often stressed, and you've got only half an
hour or so to prove you're a good candidate. But I’ve got a few
simple tricks to help you.
The essential thing is you have to think before you answer. It
always seems you have to respond immediately, but that's just
your mind playing tricks on you. The interviewer is ready to
wait for your answer, so take your time to consider the
question.
If you're working with the code, explain what and why are you
doing. Your approach to the problem is more valuable than the
answer. Recruiters want to see how you think, not just if you've
got an answer.
Even if you solved your task correctly, always ask about
alternative answers. Maybe there are some better, faster, or
more structured solutions from which you can learn. Be
interested if the things work and why they work. You should
look like someone who wants to learn new things from every
assignment.
Tell the interviewer about your mentors, inspiration sources,
and interests. What technologies are you excited about and
what you want to learn next. You should emphasize you're up
to date with discussions in the programming world, and know
what path you want to follow.
The next thing to remember is to be friendly. People seldom
hire people they don't like. So even if you're bored or tired,
don't let the interviewer feel it. Be respectful, and show you're
taking the recruitment process seriously. If you're not at your
best during the interview, no one will believe you'll become a
valuable employee.
Before the interview, you should also prepare some questions.
Usually, the excellent time to ask them is at the end of the
interview, but you can ask questions anytime. If you don't
know what to ask - don't worry; I've got some tips for you at
the end of this chapter.
One more critical thing - don't lie on the interview. If you don't
have experience with some technology or don't know the
answer, just say it. Everyone has knowledge gaps; it's nothing
to be ashamed of. But make sure you deliver it right - be
engaged and ready to learn anything required to do your job.
Technical part
The technical part of the on-site interview is the most
challenging step of every recruitment process. You may face
different kinds of tasks - theoretical questions, algorithmic
exercises in the editor or on the whiteboard, or some tinkering
around small parts of code (improvements or debugging). You
can also hear questions about your technical decisions in
portfolio projects or recruitment tasks.
I'll start with basic preparations for the interview day. You
should expect it to be long and stressful. So make sure you are
well-rested and don't have interviews scheduled day by day,
as you'll need some time to rejuvenate. Usually, the interview
lasts up to an hour, but in case it's longer, get water and
snacks with you.
In the interview, you can expect two main types of questions:
• about the tools and languages you'll use in your job,
• about the Computer Science (mostly algorithms and data
structures)
They may be theoretical or practical - in a code editor or on
the whiteboard.
Tools needed for a job
As a junior, your focus should be on the first type of questions.
Some companies, especially the bigger ones, have some
Computer Science questions or even whiteboard interviews,
but usually, they are used in recruitment for higher positions.
That's good news, as the questions about the tools are the
easiest ones. The best way to prepare for theoretical questions
on essential tools is to google the most common interview
questions in a given technology/language. For example,
search for "react interview questions" and make sure you can
answer questions from the first few results.
This is a great tactic, as many interviewers don't have time or
will to craft their questions. So they'll do this same - search for
popular questions. Also, if you can answer the most common
questions, it means that you at least had enough motivation
to cover the basics.
Learning the answers may take you some time, but it will be
beneficial. Not only can you reuse this knowledge in different
interviews, but they're also likely to improve your
understanding of the tools you're using.
If you're still unsure where to start with basic questions, we've
got some resources on the most popular front-end
technologies in our resources chapter.
Preparing for the coding part of tools and languages, you'll
use in your job is more tricky. The first step is eliminating the
things you're not likely to do - as the time is limited, you
probably will not need to implement any User Interface.
Bundlers and version control are other unlikely tasks.
There is a big chance you'll get a simplified sample of the
primary tool you'll be using. For example, if you're applying for
the role of junior React developer, it will likely be a challenge
using React. To prepare for this, make sure you know the most
popular use cases and challenges. You should have some
familiarity with it, so you probably know what the trickiest
parts are.
As a rule of thumb, you can expect some tasks connected to
managing state, making asynchronous calls, or debugging the
most common errors. Again, Google may prove helpful, as
there is lots of information on the pain points of every
technology that's widely used.
Computer science
As I've said, it's unlikely you'll face computer science questions
trying to land a junior front-end job. But it can happen, so you
have to prepare.
First of all, you need to relearn the basics of Computer
Science, especially algorithms and data structures. The best
way is, as always, to google it; I'll also recommend some
materials in the resources sections. Then, devote to it a few
hours over a few days at least.
It should be enough to handle theoretical questions on the
junior level. Remember you don't have to know everything.
Feel free to dismiss details; you just need to explain roughly
what is stack or queue and the benefits of different sorting
algorithms, etc.
For the coding challenges, especially the dreaded whiteboard
interview, you have only one solution - practice. So go to one
of the pages with code challenges like Leetcode (you'll find
more alternatives in the resources section) and start
practicing. Solving 2 or 3 challenges a day should be enough,
especially if you start it a month or so before looking for a job.
These challenges will make it easier for you to think about
algorithms and improve your problem-solving skills. After
solving each challenge, take a moment to see how others
tackled the problem. You can learn a lot by looking at other
people's code, especially if you put the work first and
understand the main challenges.
“
Take the
opportunity and
ask some
questions; saying
you have no
questions is often
perceived as
unprofessional.
Whiteboard interview is so difficult not only because we don't
have a code editor to help us but also because we don't have
experience. So train for it! Try implementing some basic
algorithms on a whiteboard or using pen and paper. This way,
you'll get used to it, will make fewer mistakes, and the
interview will become less stressful.
Getting practice with interviews helps not only with the
whiteboard part. Ask your friend or a family member to do a
mock interview with you. Even better if this person is a
software developer, but even if they’re not, ask them to google
some questions and interview you. After a few such sessions,
you'll be much more confident and ready for an actual
interview.
If you prefer to have strangers interview you, some platforms
can help. They're not free but may improve your chances
significantly, especially if your interview is remote. One
example of such a platform is CodeInterview. As always, you'll
find more examples in the resources chapter.
Keep in mind that each interview is also a training session.
You'll get better with every one of them, so don't beat yourself
too much if you fail one.
How to answer the questions
Answering the question is an essential skill that many
candidates neglect. The way you answer the question or solve
a problem is often more important than the answer itself.
Even before you start answering, make sure you understand
the question. The best technique is to repeat it using your own
words. Later clarify:
• What is the goal you need to achieve?
• What is the optimal result?
• Are there any edge cases?
• What tools are at your disposal?
To give you an example. First, you can get a question, "how
would you implement state management in the React
application." Before you start answering, ask:
• Is it's an existing application or built from scratch?
• How big is the application?
• Can you use external libraries/tools?
• Are there multiple API calls and side effects to be managed?
Do you see what we are doing here? Even before the answer,
you show you’re a professional. You're anticipating potential
problems and challenges. So you ask questions until
everything is clear to you.
When you start answering the questions, try to show your
thinking step by step. Don't just provide an answer, but add
some context and thinking process. For example, for the
questions above, don't say, "I would use Redux because I'm
familiar with it." Instead, say something like:
"I could use React state, but it may get hard to manage over
time with many nested components. The second option is
using Context API, but it can have negative performance
consequences. So I'd probably go with some state
management library like Redux to handle most of the
application state. For the strictly local state, like forms, I would
use the standard React state hooks."
This detailed answer tells the recruiter you know what you're
talking about. You know multiple options and assess how good
they are. They may disagree with your judgment, but they'll
appreciate your thinking process.
Take this same path with coding challenges. Explain every
step you take and the reasons behind it. If you're not sure and
are just evaluating some approach - say it. The interviewer
wants to know how you tackle the problem, not only if you
know the answer.
After you answer the questions or solve the problem, ask the
interviewer if your solution is good. Then, regardless of the
outcome, ask if there are other possible solutions, what could
go better, or how you can improve. This will show you're
committed and want to grow.
Behavioral part
The behavioral part of the interview is critical, especially for
junior roles. In truth, many candidates for the junior positions
are similar in skill - they finished these same Bootcamps or
learned from these same resources. Unfortunately, it's not that
easy to stand out, so you'll often be accepted or rejected
based on how you fit the company.
Preparing for the behavioral interview is often challenging, as
you can expect everything - the recruiter can ask so many
different questions. Luckily, some evergreens are almost
guaranteed. By preparing for them and branching out the
answers, you can become reasonably confident in nailing the
interview.
Cover the basics
The basic preparation for the interview is learning everything
you can about the company you're applying to, and if
possible, the recruiter. Learning about the company, its
products and approach will help you discover its priorities,
culture, and requirements.
“
The interviewer's
job is to calm you
and allow you to
show your best.
If they're
purposefully
stressing you out,
it's probably a
toxic workplace.
For example, if you're applying to a design-focused company,
you need to be extraordinarily precise with your user
interfaces. The companies which are proud of making blazing
fast applications will focus on performance, so it's good to
learn some basics in this topic. On the other hand, when
applying to the companies focused on the backend which
have a small front-end team, you can expect to be working
with CSS frameworks, but there will be much more focus on
clean code and design patterns. Discovering these small
details will help you immensely in the interview - they'll know
you've done your research and take the job seriously.
It's a good practice that a company tells you who will be
present at the interview. If it's the case, try searching for
information about them. Maybe they have a blog or a huge
online presence. You can engage with them on social media
before the interview or just read some of their articles or see
interviews or courses. Mentioning it in the interview is almost
guaranteed to help you - everyone likes to be noticed and
praised.
Besides the company, make sure you'll research yourself. It
may sound funny - after all, you know yourself. But in a
stressful situation, it's easy to forget some information from
your CV or some of the projects you made. Make a quick
reminder so no one can surprise you.
Common questions
Let's go through some of the most common questions you can
face. Preparing answers for those questions will help you get
ready for almost everything they can throw at you. For every
question, you just need a few sentences to answer. Try to show
yourself in a positive light as a curious and resourceful person.
But don't shy away from your weaknesses; it's okay to have
weak points as long as you try to improve on them.
Tell me about yourself
It's a low-ball question to warm up. You have to prepare for it.
The ideal answer tells why you wanted to learn to program,
how you do it and how motivated you are. Consider talking
about your background, especially if it's interesting; for
example, you had an original career path before. Try not to fall
into cliches like "I wanted to become a programmer since I
was a kid."
What do you know about us
Here's where your preparation matters. Tell the company what
you like about them or their products. I interviewed dozens of
people who had no idea what my company was doing. They
didn't want to work with me; they wanted any job they could
find. Of course, I understand this sentiment; when you start,
you're often ready to work anywhere. But recruiters prefer
people who have some specific reason to join their company,
not just random developers who'll jump to the other company
at the first opportunity.
What's the most challenging problem you solved
Another evergreen question. This is something you have to
prepare upfront cause you will not be able to think of any
answer on the spot. Look through your projects and try to
recall what was difficult. Maybe you had to use some
algorithm or a complex data structure? Maybe there was
some nasty bug that you debugged. Or you're incredibly proud
of one of your architectural choices. Another option is using
one of the complex libraries or cloud solutions. Whatever it is,
describe in a few sentences what was difficult and how you
approached solving it.
Tell me about your personal projects
For these questions, you have to assume the recruiter doesn't
know your projects. Briefly summarize your best projects what is their functionality, what tech stack you used to make
them, why you chose this stack, and what were the challenges
and things you learned during the implementation of the
project.
“
No matter how
well you prepare,
there are some
things you might
improve.
When do you think the product is finished
It's a tricky question. You can work on your personal projects
forever, but sometimes you have to decide it's time to stop and
move on. If the project is for the client, the reasonable answer
is that you stop when the client is satisfied with it and all of the
agreed features are implemented and working. For personal
projects, the good time to finish the project is when you've
learned everything you wanted from it, and now is the time to
start another project and get different skills.
How do you stay up to date with front-end
This question is designed to check if you're interested in
programming or just decided to switch careers to earn some
money. You should be able to name a few teachers and their
blogs or Twitter accounts. You can mention some courses or
books you're using in your learning. Anything that you know is
of high quality. If you noticed your interviewer has a social
presence, now it's the best time to mention it.
What excites you about software development
Another low-ball question. The only wrong answer is saying it
doesn't excite you. Other than that, you can say you like
solving puzzles, and programming is similar. Or that you love
building things, and programming allows you to build them
using only a laptop and internet connection.
Or you love to help people by creating software. Whatever it is,
say it enthusiastically.
Your questions
Usually, at the end of the interview, it's time for your questions.
You should take this opportunity and ask some; saying you
have no questions is often perceived as unprofessional. You
should prepare many questions because topics are often
exhausted during the interview, so if you've got only a couple
of questions, they may have already been answered.
You want to ask about everything regarding the job, team,
and growth plan. Here's the list of questions to get you started:
• Who is the perfect employee for this position?
• How are design decisions made? Will I be responsible for
choosing tools and design decisions or someone else?
• What's the size of the team I'll be working with?
• What are the biggest challenges of the job?
• When can I expect to get feedback?
• How will my performance be measured?
• What's the salary?
• How often can I expect a raise?
• Do you have regular performance reviews?
• What are the working hours?
• Is the job partly or totally remote?
• What's the dress code?
• What's the company structure like?
• What technologies are you using?
• Do you test the code?
• Do you do code reviews?
• Do you have a mentoring program?
• What's your turnover rate?
Phone/online interview
Some companies are ditching on-site interviews for phone/
online interviews. It has the benefit of saving time and money.
And is also popular when a company is recruiting for a remote
job.
Techniques to nail the phone interview are the same as in onsite interviews and in the initial phone screen. So make sure to
be well-rested, eat some snacks, and find a quiet place with a
stable internet connection. For more detailed advice,
reference the initial call chapter.
The unique thing about online interviews is that you may be
required to code live. To ace it, you need to get used to coding
live. Before the interview, ask what environment you'll be
using. You may be required to write code in a text editor like
Google Docs. It's similar to a whiteboard interview.
Alternatively, you may be using an environment more suitable
for code, like HackerRank or Coderpad. Whatever the
environment, make sure to play with it a bit before the
interview.
Getting familiar with it is a massive part of your success or
failure. Especially make sure if it is possible to debug your
code.
When solving the task, remember to communicate with the
recruiters! It's so easy to get pulled into your world and forget
about others, avoid this mistake.
Red flags
An interview is a conversation, not a monologue. The
recruiters are assessing if you're a good fit for the job. But you
also determine if it's a good workplace for you. Some red flags
may indicate the work environment is toxic, and you shouldn't
start working there. Things like:
No answer for some of the questions from the questions
section
The company should give you a complete insight into your
future job and a team. If they're reluctant, they're probably
hiding something from you.
They press you to accept the offer immediately
You shouldn't accept an offer during the interview. You'll need
some time to reflect if it's a good fit for you. Pressuring you for
taking a job is a bad sign.
Your role or terms of employment are not clear
Before accepting a job offer, you should know exactly what's
expected of you. If it's not, the company is unprofessional.
“
Look for the
company you
want to work for
and apply there
— even if they're
not recruiting.
They seem disinterested in the interview
Interviewers expect you to do your best in the interview. You've
devoted time to prepare and get to the interview, so you have
the right to demand the same.
They are not prepared for the interview
The interviewer should know everything about your future
position. They should also have or have seen your CV and be
ready to answer any questions.
They're late
If they don't respect your time now, they'll probably not
respect it when you start the job either.
They're trying to stress you
The interviewer's job is to calm you and allow you to show your
best. If they're purposefully stressing you out, it's probably a
toxic workplace.
They're rude
Everyone has to treat you with respect. If they're rude during
the interview, it will be even worse when you start the job.
They have a high turnover rate
If the employees are leaving the company fast, it's a sign it's
not a good workplace. You should reconsider applying to work
there.
12
After the
interview
After the interview
You're done. The on-site interview ended, you've done your
best, and now you're waiting for the reply.
But are you really done? No. After the interview, it's time to
write a follow-up email.
You may think it's not essential, but it is. Often candidates are
similar in skill, so you need some leverage, which lets you stand
out amongst the crowd.
A follow-up email is a great way to do it, and it costs you
almost nothing. Your only goal is to thank the recruiters for
their time and express your enthusiasm for the job.
The best time to send the follow-up emails is the same day the
interview took place. You only need to write a few sentences,
and you’re done.
To make a great follow-up email, customize it to the interview.
Don't use bland scripts from the web. If you can send this same
email to multiple companies, it's not a good email.
An example of a good email you can send after an interview to
get a job in my company may look like this:
Hey Szymon,
Thank you for meeting with me today. I appreciate your
feedback and advice. It was great to learn more about your
company.
Knowing more about your projects and team, I'm even more
excited to join you than before.
Working in such a quality-oriented company would be an
incredible learning experience, and I would love the
opportunity to prove I'm a great fit for the role.
Here's the link to the blog about the CSS I mentioned; it looks
really slick!
I look forward to hearing back from you!
Regards,
After sending the email, your job is done; you can relax now.
Learning from a rejection
The sad truth is that you can do your best and still don't get a
job. There are dozens of skilled candidates, and besides being
prepared, you need some luck.
You will fail most of the interviews. If you're one of the hundred
candidates what are your chances? You can bend odds in your
favor with preparation, but even if there are just two best
candidates, your chance is 50%.
It means you'll lose a lot. But it also means you can learn a lot.
And get closer and closer to the job with each interview. As
they say - sometimes you win, and sometimes you learn. And
you have to win just once.
So how can you learn from rejection and win next time?
Don't take it personally
The company can hire only one person, and usually, they have
hundreds of candidates.
They don't hate you and your skills; they just had to choose
one person out of many. It's not you, it's the maths.
Maybe someone was slightly better than you, or the recruiter
had a bad day when you met. Whatever it is, don't treat it as a
personal failure but as a learning experience.
Find out what you can improve
No matter how well you prepare, there are some things you
might improve and don't repeat the same mistakes. Analyze at
what step of the recruiting process you were discarded. Then,
think about what might have impacted that decision. Maybe
you didn't know the answer to the technical questions? Or was
your attitude not right? Or you don't feel like a cultural fit.
Whatever the reason, think about how you can improve. It
might be spending more time preparing or choosing the
companies you'd fit better. You can always refine your jobseeking process.
Sometimes you're not sure what went wrong. In this case, it's a
great idea to ask. Send a short email, explain you're grateful
for the opportunity to take part in the recruiting process and
you're wondering what you can improve to get better results
next time. Not only will you receive helpful feedback, but you
can also build a relationship with a company and maybe get a
job there later.
Don't give up
It's easy to get discouraged after you analyze all of your
mistakes. So now is the time to celebrate your victories. If you
were rejected at the later stage of the recruitment process,
you had to do some things right. Why did you get a phone
screen or interview? Maybe your CV and portfolio are great.
Or you solved the task exceptionally well. I bet you had some
successes.
Not every company is meant for you, and you're not meant for
every company. Sometimes it's good to be rejected.
Companies rejected me, and now when I look at them, I'm
happy. Cause, in the end, I got to the place I wanted to be.
And you'll get there too.
13
Proactive
job search
Proactive Job Search
Bonus chapter
Finding a first front-end job is tough. You have to spend
months or even years learning and later compete with dozens
of other candidates for one vacancy. The odds are stacked
against you.
But I've got a special trick for you. The trick that helped me
and many of my colleagues. This is not advice on how to get a
FAANG job or to work for another huge company. Big
companies have complex recruitment processes and need
different approaches.
This is advice on how to find one of the millions of software
developer jobs at smaller companies.
The advice is simple: look for the company you want to work
for and apply there — even if it's not recruiting.
My story
As we're closing this book, I want to share with you my story of
getting a front-end development job. I hope it can be inspiring
and informative to you.
I'm a self-taught software developer. In 2015, I quit my job and
bet on learning to code. After ten months, I had spent most of
my savings and had no job.
I felt like I knew how to code, but I couldn't land a job. I sent
many applications and had a few interviews and even one
workday trial—all for nothing. There was always a better
candidate, and I was on the brink of depression.
At one company I applied to, the recruiter accidentally sent a
rejection email to all candidates using CC — not BCC. I could
see everyone's emails, and I discovered how many candidates
were discarded. There were almost 70 of us. No wonder I was
rejected. What were my chances of beating so many skilled
junior developers?
That day, I decided to turn the tables.
I stopped replying to job postings. Now, it was me who would
pick the employer — not the other way round.
I looked for companies in my area that built cool things and
asked them if they needed a junior's help. I sent five emails
and had two interviews, both ending in job offers.
I became a professional software developer.
Advantages of Being Proactive
Being proactive is so advantageous because you cut through
the noise. You don't need to compete with dozens of other
developers. You just need to convince a company you'll bring
value.
What's more, by being proactive, you show your future
employer you're resourceful, care about the company, and
appreciate its products.
But the greatest benefit of applying to a company that's not
recruiting is it’s good for the company.
I'm a developer responsible for the recruitment of new
developers. I can tell you the recruitment process is a hassle.
I need to create a job posting and recruitment task. Then I
have to skim through hundreds of emails and CVs, check
dozens of solved assignments, and give everyone feedback.
And in the final stage, I have to conduct a handful of
interviews.
The whole recruitment process of a junior developer takes
days or even weeks. Usually, I end up with a few similarly
suitable candidates and need to pick one of them. I could roll
the dice, as there are many great junior developers.
Because recruitment is so taxing, many smaller companies
don't do it until they have no other choice. These companies
could use some help — at least part-time — but don't want to
spend time recruiting.
These are the companies you should target.
How to Apply for a Job
Find companies in your area that are using your tech stack. Try
to be specific. If you're working in React, find companies
specializing in React — not just any company doing front-end
development. The goal is to convince them you can provide
value without too much training.
When you've got a list of companies, it's time to select a few
standouts. Pick only the ones that impressed you. Maybe they
have a great product, amazing landing page, or host some
developer community event. Whatever it is, you should be
honest. Companies can tell when you're excited to work with
them.
The next step is crafting a short email. Nothing fancy.
Something like this:
Hello,
I'm a junior developer specializing in X. I love your work. I'm
incredibly impressed by Y. Do you need the help of a junior
developer/intern? I'd love to be a part of your team.
Here are my portfolio and resume.
Regards,
Some companies won't respond, but usually, a short and tothe-point email does wonders.
If the company is interested, great! You have a considerable
chance to land a job. You aren't competing with anyone, and
the employer is already interested. You just need to confirm
you're good enough.
If you're rejected, you should have a follow-up email ready. Its
content depends on what they wrote, but you want to achieve
two things with the email: leave a good impression and learn
something.
14
Resources
Resources
CSS browsers compatibility:
Can I use
MDN
Git repositories:
GitHub
Bitbucket
GitLab
Prettify your GitHub:
Pin GitHub projects
Add readme to profile
Add GitHub stats
Add latest blog posts to GitHub
Free APIs:
Public-apis
Api-list
Application ideas:
Frontend mentor
App-ideas
Awesome-app-ideas
Projects
Application quality check tools:
Lighthouse
W3C Validator
GTmetrix
Wave
CV scanners:
Skillroads
Jobscan
Resume Worded
Skillsyncer
Online mock interviews:
CodeInterview
Pramp
Frontend interview questions:
Front-end-Developer-Interview-Questions
Front-end-interview-handbook
Frontend-developer-interview-questions
Reactjs-interview-questions
React-interview-questions
Vuejs-interview-questions
Angular-interview-questions
CV makers:
Canva resume builder
cvmaker
VisualCV
Notion Portfolio
Open-source contributions:
Guide on first contribution
FreeCodeCamp guide
Find job posts:
Stack Overflow
HackerRank
Indeed
Remoteok
Algorithms and data structures:
Leetcode
HackerRank
Codewars
Spoj