Guide to landing your first dev job

Introduction

Are you a student, hobbyist, junior developer or career-changer looking to find your first developer job? The season for applying to summer jobs in Finland is upon us so this article aims to guide you through some short- and long-term things that help you land your first position.

Couple of notes before we start

Since my blog's main audience is very international and varied, I want to preface this post by saying that this blog post is mainly aimed for and written from the perspective of developer jobs in the Finnish market. Some of the things may apply to your local market as well but it's very likely that not everything works the same way.

Also, there are many ways to find jobs and to showcase your skills. This is one account from what I have learned over the years but not the only one. I'm a "home-grown" developer who was a hobbyist first and then become a professional and that is just one experience so if your background or way you'd like to do things doesn't match this, don't worry!

Giving advice on job hunt has always felt really difficult for me. At the same time, I have a lot of insight into it through the work I've done and juniors I've helped but I've learned through it that for every advice, there's a recruiter who thinks the opposite. There are no universal truths when it comes to finding jobs, applying to them, writing CVs and applications, building portfolio and so on. There's a lot of luck involved in your application ending up on a table of a recruiter who values the things you do and the ways you are doing them.

I'm using the term "junior developer" or "junior" to describe someone early in their software development career. You might be a senior in other fields if you're a career changer, you might be a hobbyist or a student – or something else. Some companies might call you an intern or a trainee. It's just easier to use a blanket term to cover it all than repeating all the possible situations one might be every time.

With that said, let's get started!

Finding the companies & jobs

When you're looking for your first position, more is more. Unless you have very strong experience through hobbies or open source projects, you're in a situation where a lot of people with similar experience and skill levels are applying for a limited amount of positions in your area. That sounds a bit depressing but what I'm saying is that you should not be too picky when applying.

That said, if you've heard bad things about a company and there are big red flags, by all means, skip it. No job is worth that and there's plenty of good ones in the market.

Don't wait for the job ad

My first advice is to apply to companies even if they don't have an open position advertised anywhere. Maybe they haven't started their summer job campaign yet and you're ahead of the pack. Or maybe they hadn't thought about hiring summer employees or juniors but you could convince them that you're worth their time. Worst case scenario is that they are not hiring and even then, you may seem like an active and interested developer who might be considered in the future.

Many companies these day have some form of "Open application" in their career page because IT industry is pretty much always hiring these days. I've sent more open applications in my life than applications to advertised positions.

A good approach is also to list all the companies you know of or are interested in, rather than starting your search through job ad platforms. Prioritize companies you'd like to work in because if you get a job in those, you'll probably be happier.

Team up with other juniors

Do you know other people in similar situation? If you're a student, you probably have some student mates you could team up with to do the discovery process. If you're a career-switcher or a hobbyist not in an organized group with others in the same situation, reach out to different communities (I'll talk more about these a bit later in the networking/community section below) to find people to partner up with.

You can create a shared document: eg. a spreadsheet on Google Drive, an Etherpad or a Notion page to track companies your group has found and information about them, including links to their websites, job ads and so on. When I was looking for my first job back in university, everybody in my friend group had an interview in the same company within like two weeks or so. One or maybe two got a summer job there and ended up staying for years.

Where to find them?

If you are studying, keep an eye on the recruitment board of your student organization. Companies are often advertising there for their junior positions. The trick is to not only look for positions that are posted after you start looking for but dive into the archives for the past couple of years and list every company there. Similarly, companies sponsor the student organizations or their events – or other university/college events like career fairs. Go through past events and sponsorships and add them to your list.

Even if you're not a student with direct access to those groups, check the websites of student organizations in your area anyway. Often these are publicly listed. For example, my alma mater student organization Asteriski has a nice list of local companies listed as sponsors. For example in Turku, Finland alone, there's quite a few of these student organizations: Asteriski, Digit, DaTe, Infå, TIO and probably some more that have popped up since my student years. Don't limit your search to only your direct social group.

And student organizations are not the only places: local meetups, tech conferences and other organizations often organize activity sponsored by tech companies. Our Turku ❤️ Frontend community for example has 22 local tech companies listed as sponsors on our website. And we're only one in the bunch. Others might not have them listed on a website but you can take a look at past events on meetup sites like Meetup.com or Meetabit.com. To continue with the Turku theme, communities like Twig the Code, Aurajoki Overflow, TurkuSec, turku.py or Mimmit Koodaa work with a lot of tech companies. Same applies to events in your city as well.

And you're likely to know companies from other circumstances through: someone once said that "Every company is a software company" these days because everyone needs software to run their business. So you can look into companies that work on other industries as well: banks, healthcare, education and many other industries have teams of developers working for companies.

Write every company name that you find or run into to a list somewhere. It'll be handy, not only for your first job but in the long run as well.

Occasionally, others are also compiling lists and sharing them publicly! For example, in Finland Talented just published a collection of companies and their trainee programs and Juho has been collecting similar things on this open sourced collection.

How to showcase your skills

The big challenge most junior developers run into is how to show what you can do. When you don't have a long work experience in the industry and most people in the same situation have somewhat similar paperwork (for example, students who've studied the same studies). It's very difficult for companies to figure out what differentiates you from the others.

You don't always have a choice between these different options, sometimes companies just tell you what they want and don't accept alternatives. But it's always worth asking: "I have some hobby projects I've built, maybe I could show some of those instead of a homework assignment?" or "I can't dedicate hours in the evenings besides work and family responsibilities to do projects, could I showcase my skills in an interview setting?"

Portfolio of hobby/side project(s)

One way to do that is to have hobby projects. These are projects that can be used to show experience before you have work experience. The downside of them as a general advice is that not everyone has time to work on their personal projects and that's perfectly fine too. We'll talk about the other options later.

How to come up with ideas for a project?

The more experience and skills you have, the easier it is to come up with ideas for what to build. You have gained understanding of what is possible and ran into ideas for what to build. But what if you don't have any ideas? Here are a few seeds of thought to get you started. If you already have built something, you can skip to the next subsection titled "How to showcase your portfolio projects?".

Build something you need. I find these to often be the best projects: you don't need to artificially come up with ideas for features because they stem from your own needs. Extra benefit is that in addition to gaining a portfolio project, you'll gain something that is inherently beneficial to you.

One of the examples from my hobby project library is 235, a command-line tool built with Rust that displays NHL results on the command-line. It's a tool that I built for myself to solve a need that I had and offered a great opportunity to learn a new language and to have a project I can showcase when applying for jobs. If it is helpful for anyone else too, that's just a bonus.

Build something for a non-profit or community. Doing work for free is not a great proposition. There may be short-term individual benefits of launching a career but it's only available to those who can afford it and it does the industry a huge disservice. But using your newly acquired skills in software development can be put to good use with non-profits and communities you're involved in.

Many communities run by people contributing whatever skills and time they have for the shared cause. And there's a lot that can be improved with software that there's no real budget to buy a solution from experienced professionals but are perfect for a junior's hobby project.

In my own hobby project library there's Gym Leader Challenge Decklist Validator which is a tool I built for the Pokemon TCG player community that I'm part of to help everyone out. I've also built websites and web apps very early in my hobby journey for other communities and I attribute most of my learning process and early career growth to those.

Finally, you can replicate something that exists. If you don't have any needs yourself or don't quite know what to build for your community, a good way to build a portfolio project is to take something that exists (for example, a photograph filter system like ones at Instagram and other services) and try to replicate the functionality without looking at any of the code.

It's important to be open and transparent about the fact that you are doing this as a portfolio showcase and that it's not your idea.

This approach lifts the burden of coming up with product design for something completely new – a skill not required by a junior developer – and you can focus on writing code and implementing something. The outcome is a code sample and example project you can show and discuss (more of that later) to your potential employer.

How to showcase your portfolio projects?

When you have built something, you have code. Even though code is the necessary part for a functioning software, it's not enough to  get the best out of your project.

If you send a company your CV, application and a link to a repository that only has your code, it's likely nobody will spend more than a few seconds looking at your project. It's daunting and nearly impossible to figure things out from the code itself.

Having a list of multiple projects can be a disservice to yourself too. Since sites like GitHub are not only a portfolio site but a tool that we use to build our software, it's likely that over time, you'll end up with many projects there. You want to direct the reader of your page into the best and most important ones.

Let's look at some things you can do to make your case better.

Make the code available. Start by putting your code somewhere online. Most common places are GitHub, GitLab or other code hosting site. Sending zip files as email attachment these days is not probably going to land well.

Write a good readme. Before anyone sees your code, they should get a good understanding of what your project is about.

• Give your project a name (doesn't need to be good or creative),
• Write a short description of what it is and what it does (for example, from my 235 project: "235 is a CLI tool with very simple design: one command that displays currently on-going or previous round's NHL games with results and goal scorers.")
• Write about the technologies you've used
• Write instructions for how to run your project in development mode (this is mostly for you, you'll thank me later)
• Optionally, write about things that you've learned doing this project

Don't hesitate to use screenshots or short videos as examples and if you have a live demo somewhere, link to that!

If you don't know where to start, there are a lot of templates like Othneil Drew's Best README Template that help you get started.

If you only do one thing from this portfolio section, do this one. A good readme will do wonders in getting people interested in what you've built and provide a way for them to understand it and navigate it.

Sharing your learnings is very valuable, especially for juniors. I'll talk more about that in the interview section of this post but it can be also written into the readme of the project.

Build a "product page" for your project. In addition to the readme, you can also treat your project as a real product even if you don't plan to sell it to anyone or gain users.

Take a look at Tailwind CSS's product page for example. It clearly communicates what it is, how to use it and so on.

You can use for example GitHub Pages to host your product page directly from your project for no cost or Netlify to host your website for free.

If you have multiple projects, my advice is to pick one project as your best showcase. Pick the one you're most proud of or most would likely to talk about and focus your effort on making that look great and interesting.

"Home work" projects

Some companies, especially if they are hiring more than one or two juniors through a summer job campaign or similar, have some sort of projects that you do on your own before you apply. And quite often, if they don't, you can ask for one if you don't have any existing side projects. In my opinion, the best companies let you choose between an existing project and their job application period but not everyone does that.

These are usually small projects that ask you to implement something with relevant technologies to the company you are applying to. They are meant to be projects that can be finished in an afternoon or a day (or some claim, in a few hours) but I've seen so much variety in how realistic those are. They are often written by experienced developers who estimate how long it would take them and add a bit more and that's often not super good estimate. I know because I've done that mistake myself when creating these sorts of assignments for applicants and have failed at estimating them.

Do your best at following the instructions. If you have time, you can add some flair to stand out but don't stress it too much. Don't hesitate to ask questions from the company if there's something you don't understand or are not sure about in the instructions or what is expected.

Live interviews

Sometimes it's not feasible to work on projects on your own time, especially if you are applying to multiple places and have other responsibilities in your life (taking care of family, another job, studies etc).

Another way to show your skills is to do a live coding exercise during an interview. These are often used and often not much liked by developers but their benefit is that it doesn't take hours of your free-time so I think they are great for some situations.

I'll talk more about the interviews in general and tips for live coding exercises bit later in the post.

CV/Resume & Cover letter

(I use terms CV and resume interchangeably here. It's a reference sheet of your experience.)

This section is the hardest one for me to give advice on because it's the one that has no right answers. For every advice someone gives, there's a recruiter who thinks the opposite and considers following that advice negatively. So take all of these with a grain of salt.

A job application often consists of two parts (+ the portfolio mentioned above): a CV/resume that lists your work experience, education and possibly skills and a cover letter that explains why you are applying to that specific position and why you'd be a great fit.

CV / resume

Writing a CV is hard when you don't have experience in the field. Before you start writing your CV, think about this: what are all the things that you've done in your life that could be helpful for this job.

There are many opinions about what to include but the above perspective has been my guiding light. Whether something is a full-time job, a non-profit community project or a hobby, it doesn't really matter. What matters is what experience and skills I've gained from it.

My suggestion is to put the most relevant and recent to the top of your CV. Usually work experience is more relevant than studies, so I most often list those in the top. For a student, this is especially true if you're applying locally in your area where most other applicants are from the same schools or universities.

When you have limited (relevant) work experience, you need to be a bit creative. If you've been active in your student organization (maybe as a board member or a tutor), absolutely write that into your CV. Have you built smaller projects for a hobby organization your part of? Into your CV it goes.

Some disagree with this, but I don't consider CV as a pure reference guide to your employment and academic history. It's a document that you use to present the best possible truthful image of yourself to potential employers. It means that the CV isn't always the same between all the companies you apply to.

If you have experience in being a cashier on a supermarket and you apply to a company building point-of-sale systems, absolutely make that experience an important factor in your CV. It brings valuable first-hand experience into the team that might not have any.

Cover letter

Here you should explain why you're applying, what you can do and what you want to do. I consider these all things that cannot be derived from the CV as that only describes your past – not your future desires.

A former colleague at Futurice wrote a blog post 5 steps to a great application a decade ago but it still holds a lot of wisdom. It's one company's (or more specifically, one person's) view but in my experience, following its tips will be beneficial in general.

Like the CV, the cover letter should be specific to each position. In it, you should put the spotlight and guide the reader's attention to the things that you think are the best of you and your work.

Early into my career, I built websites and small web apps as my cover letter. I wanted to show, not tell, what my skills were and that I understood where I was applying to. When I was writing a job application to Spotify for example, I made my cover letter a website that mimiced the layout of their desktop client (with real-time updating feed of what I was listing in Spotify).

It's not necessary to go that far but it's an example of thinking outside the box, getting the attention of the person reading the applications and sometimes it works, sometimes it doesn't.

What kind of cover letter and CV works for any given company depends completely on the company and the individual person reading your application. That's why it's so hard to give clear advice. I've always tried to think of ways that can help me gain their attention in a positive way that showcases my skills in the best possible way.

The goal of the CV & cover letter is to get you an interview.

It's then the interview(s) where you prove your case.

Interviews

This section is not an all-out guide to interviewing. Instead, I want to focus on one part: how to use your portfolio projects to the max.

One reason I really like having a hobby project in my portfolio when applying for jobs is that it usually enables me to drive the discussion to the direction I'm most comfortable with. I know my project inside and out: the why, the how and all that jazz. By bringing those projects up in the interview, I can explain my skills and what I've done in a way that I know the answers to up front instead of having to rely on coming up with good answers to surprising questions at the spot.

The reason this is so valuable is that job interviews are stressful. Even people with a lot of experience who can build amazing things can freeze up and forget simple stuff in the interviews. By having at least one path of discussion that you know well through experience helps you make sure you are able to showcase your skills and what you know.

And those projects don't have to be super impressive either. Even less so for a junior. A main concern for an interviewer when interviewing a bunch of juniors with similar educational history and no work experience is figuring out who knows what. So showing a project that you've built (and decided to build yourself, that's why school projects with given assignments are not the most effective but work if you don't have anything else) is very good.

Throughout my career, I've used different projects as my main discussion points in interviews. Once I had a very rudimentary prototype for a personal budgeting app that I had built few months earlier to discuss why I built it, what technologies I used, why I choe Vue.js + Firebase and what I learned from the project. It wasn't finished, it wasn't polished but it was a good discussion starter.

So what can you talk about in your project that showcases your skills and understanding?

Here's a non-exhaustive list (but you don't have to have great answers to them all)

• Why did you build your project? Talk about what sparked the idea to start building this (and saying: to learn this new tech is perfectly fine answer) and how did you design and decide what features to have in it.
• What technologies you used and why? This allows you to expand further than just some code to explain your understanding of underlying technologies, why some might be more suitable than others (once again, saying "that's the language I know best" is perfectly fine answer).
• What did you learn? It shows that you've learned new things and are able to recognize them and reflect on them. Crucial skill in software development.
• What would you do differently? Have you ever looked at your old code and cringed a bit? That's a good sign, shows you've improved! Being able to understand what you would do differently, even if you haven't implemented those changes into the code, is a good sign and can reveal a lot about your understanding of software development.
• What are you most proud of in this project? When someone talks about things they are excited about and proud of, regardless of the topic, it's engaging. You are in the driving seat so pick the things that you're most excited about and talk about them. Maybe you were able to optimize a SQL query to speed up your program execution by 50%: definitely worth talking about. Or maybe you made a really nice CSS animation to your frontend: share it!

The key to these questions is that they are things you can talk about even when not directly asked about. If an interview asks you to talk about a project that you mentioned in your cover letter, think about these as a framing for your answer. Or if they don't speficially ask about your project, you can ask if you could talk about it. "I don't have work experience in development but I've built this project, could I show it to you and talk about it?"

Don't think that you'd need some miraculously amazing answers to any of these. Saying that you built something because you wanted to learn something new or that you chose a technology because that's what you know best or saying "I don't know" to any question are all perfectly fine.

Long-term: networking & blogging

All above is what you can do right now when applying and interviewing for jobs. I put it out there up front because it's the more pressing one. If you want to have a long-lasting positive impact on your career, continue reading. These are all non-necessary ones: in fact, most developers who have great careers don't do them. But I've found them incredibly useful and beneficial.

Let's talk about my expertise: networking, communities and blogging.

Networking and communities

Networking may have a bit negative connotation but even if you're like "yikes, not for me", keep reading. Networking isn't (only) going out to events and handing out business cards to everyone you meet or maxing out your connections count in LinkedIn. In fact, I personally don't care about either.

Networking is things you do together with other people, and then some. For a student, a great place to start networking is your student organization and fellow students in your program. It can be getting involved in student guild or just hanging out in the events, studying together and making friends.

When I was a student and someone gave me this advice, I thought "what's the point of networking with people who are in the same situation as me". Now, over a decade later, all those friends I made during the studies are in senior and lead roles in companies all across the country and even the world. Whenever I apply to a dev job, I see them in these companies and end up having interviews with them.

Networking also isn't about "only making friends to benefit from them" or taking advantage of anyone. It's about doing things together, helping each other out and being a good person. The benefits in career are just a positive side effect.

Last year, I wrote a Developer's Guide to Communities that goes more in-depth into all of this.

Blogging

Writing a blog is such a powerful tool for a developer: it helps you improve your craft, it improves your communication skills, it can help as a refactoring tool, it builds a body of work that you can link to in your job application and sometimes you get great opportunities because people have been reading your blog for years.

One big mental hurdle many (me included early in my career) have about blogging is: "I'm not good enough to blog about this" or "Someone else has already written about it". Try to get rid of that thought. Frame it in your head as "I'm documenting what I've learned" and if your writing is useful to someone else, that's just a bonus.

Whenever you create something or learn something new, write a short blog post about it. Post it on your blog (more tips for getting started in the blog posts linked below), share it with your developer friends.

Write first and foremost for yourself: to help you make sure you understand the concepts you're learning and working on, to document things (I regularly go back to How to scrape a website with Python & BeautifulSoup to remind myself how to do it) and to keep a log book of what's going on in your professional journey.

I've been blogging on/off since 2013, more seriously and actively since 2019. I love looking back at my old posts, reading through to see how much I've improved both as a writer and as a developer and I'm so glad that the material is out there.

I have written more about blogging for developers if you want to dig deeper:

• You should start a blog today
• Your blog should have a RSS feed
• Blogging is my new favorite refactoring tool
• Over a year of weekly blogging
• Learning in Public

Wrap up

I hope this guide gives you ideas, inspiration and some pointers that will help you in your journey to your first job. Getting the first job in the industry is usually the most difficult one. After that, you start to have experience, references and more skills that make it easier in the future.

You'll inevitably get rejected a lot. Don't get discouraged. You'll get there one day. I'm cheering for you! You probably won't get good feedback from the companies on how to improve your application or interviews: sometimes it's because companies don't take time to write it but sometimes also because there's limited amount of junior spots and they had to pick one or two people.

Josh Collinsworth wrote a great, in-depth article with his advice for job hunting in tech. It discusses some of the same topics as I do but also a good chunk of things that I did not talk about and all in all provides extra perspective to things.

One advice from Josh's post I want to highlight is to create a behavioral story bank:

Your behavioral story bank might be your single most important resource. It’ll help you write your cover letters, applications, and resume, and it’ll give you solid answers to interview questions.

Good luck!