You're looking for your first junior software engineer job, now what?

Getting that first job as a junior can be tricky. Companies are loath to train up developers on their time, under the assumption that it will use up time that could be spent being productive. In my experience, junior developers are just as valuable as seniors. Seniors have the experience to guide a project or workflow, while juniors have the inquisitiveness to question how and why we do things.

Let’s think about 3 parts of the job process: screening your CV, the culture fit interview, and the technical interview. There’s more to it, depending on the company, they might invite you to a get-to-know-each-other event, they might get product or UX or the CEO to interview you. But we’ll not cover those here, and instead focus on the first steps.

Before we get into that, though: remember that there are many, many, many companies out there, and developers are in demand. If an interview process doesn’t go well, reflect, learn, and move on. You will probably get a bunch of rejections before you get accepted - and you shouldn’t always settle for the first that accepts you. And that’s okay, because eventually you will find a job. Keep your head up!

Interviews

Screening your CV

The first step your potential employer will do is screening of your CV. They’ll usually look through what you submitted in your job application, to get a feel of what projects you’ve worked on, what tools and languages you know, and why you want to work there. For most juniors coming out of university or bootcamp, you probably have mostly just used languages your institute taught. These tend to be Java, Python, and some Javascript. Companies that target new graduates specifically tend to use one of these languages, to make your transition to working life easier. Alternatively they might be set up to onboard you to a new language when you join, if they are using a more obscure language like Elm, for example.

CV formats is a big question, and the best thing to do would be to look at what CVs look like in your market. Some parts of the world would expect a phone number, some expect a picture of you, etc. You should be clear to state: which programming languages you know, interesting projects (either from education or personal), your education and then maybe your location and languages you speak. Those last two are important if you’re applying to a job somewhere other than your current location. And, sad to say, if you have a name that doesn’t fit where you’re applying - be clear about them. You might be a native with an unusual name, but the assumption is that unusual names are from other countries. Unusual in this case means anything like a Welsh name in Norway. Junior job posts get a lot of applicants, so being able to prioritize those that don’t require visas is sometimes important.

The companies you’ll have the toughest time applying to will be those who expect you to already know X language or Y framework. There’s only one way to get around that: learn X and Y. Fortunately, there’s a few ways to do that. The first is a little recursive: find a company that uses it already and hires inexperienced juniors. The second is similar: find a company that offers internships for students during your summer breaks. Finally, work on a project in your own time. The first two options are pretty straightforward, and there’s not really a secret to getting them other than applying to a bunch of positions. But working on your own projects is the one you have the most control over.

A project doesn’t need to be complicated. You are aiming to build muscle memory, and an idea for how code can fit together. See a game get popular in the news like Wordle? Start thinking about how you might make your own. How would you display each row of guesses? How would you validate if the word entered is the correct one? How would you animate it? These are the kinds of questions experienced developers are able to at least take a rough guess at. Maybe they have a preferred way of rendering frontend code. Maybe they have a preferred approach of iterating over results. Maybe they know enough about CSS animations to attempt it. You don’t need to know the answers to all of these: but get familiar with both not knowing the answer, and doing research independently to figure enough to achieve what you set out to do.

Your code will be messy, you won’t follow best practice, you probably will have errors that you don’t understand and spent more time reading stack overflow than you did writing code. But that’s okay: you don’t need to know the answers right away. Your approach to the problem itself is more important than your approach to the code. You can also get involved with the community: learn how to ask questions on IRC, Discord, Twitter, Reddit. This ability to ask questions will help you when it comes to interviews.

So be brave, start a bunch of projects using tools that you see companies demanding, and start building a list that you can refer to when someone asks you “Do you know how to use Next.js?”. Stating these in your CV is key to passing screening. Bonus points if you have them up Github or Gitlab for people to both see the code and the deployed version. If you don’t need a backend, Github Pages is a great tool for hosting frontend projects for free.

The culture fit interview

Every company does culture fit a little differently, which is inherently due to the fact that every company has a unique culture. They might be more diverse and focus on that, they might speak a particular language at work, they might prefer home office and remote work over office work. They might go for beers every Friday and each lunch together.

There’s not really much to this interview: try to be yourself as much as you can. What does that mean? Well, try to represent your personality and interests to the interviewer. If you’re interested in the news, talk about what you read and why. If you enjoy playing piano, you can mention it. Ask questions back to the interviewer. It’s difficult in an interview context to be completely natural, but the more natural you are, the better the interviewer will be able to figure out if you’ll fit into their team. This to your benefit: being in a team where you don’t fit will mean you won’t enjoy your job as much as you could. And why spend 40 hours a week being either just okay or unhappy at work when you could be around people you fit in with instead?

As such, it’s important that you ask about things you care about. It might be your first job, so you might not be 100% sure on what a team you’d like would be, but try to think about what interests and motivates you. You should try to identify if they have had any juniors previously, and if they have the setup for training and onboarding new developers. If they’re a team of only mid or senior developers, they might have trouble with mentoring practices or getting you up to speed on what you need to know.

If you’re an immigrant, there’s a few additional concerns: do they use a language you can speak, do they socialize, do they sponsor visas? I would place additional emphasis on the social aspect - as a newcommer in their country, you’re going to be unfamiliar with the language, society, and the history. Your colleagues will be your main contact point for learning all of these, at least in your first few weeks.

The technical interview

There’s typically three approaches to tech interviews: 1) a challenge you’re expected to complete in your own time and then go over together with some interviewers, 2) an interview where you are live coding with an interviewer as a pair programming session, or 3) a whiteboard interview where an interviewer will ask you about some problem they might have.

The takehome, 1, is the typically accepted interview process used by most companies these days. They will likely email you a README which gives instructions on what you should do and what tools to use, along with a time deadline usually like 2-3 hours. Read the README twice before starting, make sure you’re going to solve the right problem. For example, at Aftenposten we might ask you to focus on making a frontpage: so don’t spend time on making an article until you’re done with the frontpage. Also make sure you’re using the right tooling. They might’ve told you to use Typescript, for example, so if you use Javascript instead it might give you some negative points. If you want bonus points, use Git to track each change you make. It’ll really set you apart and demonstrate one of the forgotten aspects of software development: good, clean commits and their messages.

Once you submit, they’ll probably take a quick look at it, and if you passed some of their requirements, they’ll call you in for an interview where you’ll go over the code together. Familiarize yourself with the code. You don’t need to have a full understanding of everything, but you should know why you used particular things. If you used useEffect, for example, you should read the documentation about it and some examples to ensure you get the rough idea of when to use it. The interviewer will ask you some specific questions about your code, like why did you do things a certain way. Be inquisitive: feel free ask or say when you weren’t sure about something. Again, you are a junior, you are not expected to know everything. But asking the right question is an art form, and one as a junior you should master. They might ask you to implement a new feature, or just ask you how you would implement it. Be ready to think on your feet.

Live coding, 2, in an interview technique where the goal is to assess how you are to work with as a programmer: are you good at listening? Do you know when you Google or ask for help? Do you know how to debug? For this, my best advice is to get involved with internet communities. Get into their online chats and started asking and answering people’s questions. Help them out, and learn from them. In the old days IRC masters would give you endless tips on how to ask good questions, along with being great sources of knowledge. Maybe there’s a language or framework you found interesting? Jump onto their Slack and get involved.

Apart from that, calm yourself and relax. Act like a human, and you’ll do fine. Juniors have a tendency to either over focus on the code, or get transfixed by some minor detail. If you’ve not said anything for the last 5 minutes, vocalize what you’re thinking about. “I’m thinking about X” is enough to give the interviewer something to work with: they might prompt you with something they consider more important, or give you an answer you might need to progress. Don’t zone out.

Whiteboarding, 3, is less common these days. The premise is simple: you, an interviewer, and a whiteboard are in a room. The interviewer will ask you to implement an algorithm in psuedocode (or real code if they’re cruel), and then ask you questions like the size and speed considerations of the algorithm, or when you might use alternatives, or about how you implement a data structure. For these kinds of interviews, you should express when you’re unfamiliar with something - for example, you might want to say “I’m unfamiliar with merge sort but I know how quick sort works”. A good interviewer will not penalize you for not memorizing every available algorithm and data structure, but will reward you for knowing some computer science background, along with describing the algorithm or data structure to you so that you could discuss it. This interview format has the habit for being abused by big companies that get thousands of candidates, so you might find it more stressful and unfair than the other two formats.

Next steps

I haven’t heard anything from the company, now what?

Some companies can be pretty slow at screening and setting up interviews. My advice would be to reach out the recruiter - email or linkedin, and let them know you are in processes with other companies. They’ll do their best to either let you down kindly, or speed things along.

Note that some companies just don’t reply at all if you didn’t pass screening, so that might be the case. Never mind — onto the next one!

So I got an offer, now what?

If you pass the whole interview process, you’ll get a job offer. You should reach out to your classmates from university or bootcamp, and compare what they’ve been offered. Don’t be afraid to hold out til you get an offer that matches your expectations, but also be reasonable with your expectations. Asking clearly in your first interview about salary and benefits is a great way to manage expectations. Likewise, Glassdoor is a good tool for figuring this stuff out.

If it suits you, accept! And congrats on your new job.

So I got rejected, now what?

If you got to the interview stage and had a rejection, feel free to reach out to your interviewers to ask for feedback. Done politely, interviewers generally like giving feedback if they have time. They might specify some questions you got messed up, or some tech they expected you to know, or a lack of experience. Listen to it, learn from it, and don’t argue. By this point the decision is already made. But, with that in mind - you can always apply again in a year or two. Companies change a lot in that time, and so will you. Don’t be disheartened by rejections. It’s a natural part of the process, and one rejection now does not mean you are un-hireable.

Summary

I hope you found this useful. These are some tips I’ve picked up after years of doing interviews on both sides of the table. It’s a daunting part of everyone’s career, but you can take steps to prepare for it. Best of luck!