Tips from someone who interviews Junior Frontend Developers

I've been doing interviews to junior frontend developers to help at my current job. I also designed a technical test which candidates do before the interview.

I read through the code, check the repository, try the app and decide if the candidate would be a good fit. After that in the interviews I usually want to get to know the candidate a bit more and give them an opportunity to show me what they think would be appropriate that they have not yet shown in previous interviews or in the technical test.

Here are some tips I'd give to anyone who wants to get a job as a Junior Frontend Developer.

Use git correctly

Try to follow some standards like gitflow on your technical tests. Nothing fancy, some branch for development, and commits with prefixes like "hotfix" or "feature" would be enough for me. Just don't add the whole app in a single commit and be done with it.

What this shows me is that you know the basics of git, and you are trying to keep your repo tidy which is really important.

Do small commits / pull requests

Small commits and pull requests are easy to handle and isolate. I always say that I'd rather have 5 PR with one feature / bug fix each than 1 big ass PR with 5 features / bug fixes.

Easier to rollback if something breaks, easier to manage, easier to correct and give feedback on the PR. So, small PRs, clear commits.

Learn Separation of concerns

One recurring mistake I find is having your API access logic directly in components. Now you don't have to architect your technical tests perfectly just have things in their place. A few files to handle data access logic that are consumed by components is enough.

Try to write semantic HTML

Writing semantic HTML shows me that you've done your homework on HTML. Some junior developers skip learning HTML correctly because they jump directly to JS or React/Vue. Creating scalable component libraries depends on writing clear and simple code. Code that is easy to read is less complex and is easier to fix down the line. HTML is a big part of frontend applications and writing semantic HTML should be in your learning to-do list if you haven't already.

It also helps with accessibility and SEO.

Follow a pattern for your CSS/SCSS

What I mean here is don't just put a class on a div and fill it up with styles. Try to think this through a bit.

This will show me that you've also made your homework on CSS. You could use a utility class framework like Bootstrap or Tailwind. You could use BEM. You could just write the styles you need for your test but as utility classes.

Do some googling on this and try things out. There's no 100% correct answer here sadly 😅

I don't personally like utility classes because it bloats the HTML, but I believe they are really useful for creating scalable CSS codebases.

Don't repeat code

If you find yourself writing padding: 1rem; 15 times in your app that's repeating code.

If you find yourself writing

<div class="actions">
    <button>Cancel</button>
    <button class="primary-btn">Submit</button>
</div>

That's also repeating code.

Try to find those places where you repeat code and create components, reusable classes, or utility JS functions, so you don't have to repeat code.

Write some documentation

Google "how to write good documentation" or "how to write a good README".

Read the docs you really like and see what they add to their docs, what are they talking about, what questions do they answer, how do they structure the docs?

Having a basic grasp of this will go a long way when writing documentation. It will make you look superb to the engineers who will review your technical tests.

Learn some basic design skills

If you're not that great with design, and you feel like your UIs are kinda ugly (we all start there). I recommend you read some articles about design to improve your skills. There are tons of videos, articles, books and tools out there.

Why is this important? Aren't there usually designers who take care of that stuff?

Yes, good question me. But designers are people who can make mistakes too. It's nice to know that the people who are building the UIs also have some eye for the basics of UI Design.

Creating a good-looking app is something we all want and actually provides a lot of value. Makes your product easier to market. Makes people want to use your product. If you're able to help with that part you're providing extra value to your team. Go flex them design skills boi.

Use your package.json correctly

I always check the package.json file in projects to see the dependencies that are being used. Also, I check the different development dependencies to have an idea of what stack is being used, you could be using rollup, vite, webpack... I just want to get an idea. When you're installing dependencies make sure that you're adding them to the correct place.

Tests: good idea to add but don't go crazy

Yes tests are important and yes I'm glad that you wrote some. But you don't need an 80% coverage. If you write 2/3 unit tests that'd be enough. I don't want you to spend 8 hours on the technical test.

Make sure that your tests are actually useful and good and don't have false positives. I recommend reading Ken C. Dodds:

https://kentcdodds.com/blog/?q=testing

Prepare some questions

Show interest, show that you're also trying to find out if the company is a good fit for you.

I have a list of questions I usually ask here:

I wrote a list of questions you can ask

This article is highly opinionated

You will find interviewers that are not as flexible as me. You will find interviewers that are looking for a senior developer for the price of a junior (lots of these out there watch out).
You will find interviewers that just want to get to know you and ask you some questions about JS and will offer you a job.

You will probably go through 100s of interviews throughout your career so don't stress if one or two go wrong. Specially your first interviews. Use the interview as an opportunity to learn. Ask questions.

You don't have to be an expert in any of these things I listed

Being good at these things or even having a basic understanding of them will make you a great candidate for frontend jobs. I have hired people that didn't know some things in this list. But when I have a candidate who understands these things and another one that doesn't... the choice is usually pretty clear.

PD: Make sure that the company is a good fit for you just like the company is trying to learn if you're a good fit for them.

Follow me on twitter for more :)
Also check my recently launched newsletter: Zero to Frontend