Skip to content

Get your first software developer job

Tips, tricks, and general advice for how to get in the door in tech.

Artwork: Ariel Davis

Photo of Cassidy Williams
Contenda logo

Cassidy Williams // CTO, Contenda

The ReadME Project amplifies the voices of the open source community: the maintainers, developers, and teams whose contributions move the world forward every day.

Also in Developer Stories

Lift as you climb

Hello! My name is Cassidy Williamsand I'm a software engineer who's been in the industry for quite a while. I've been on all sides of the hiring table (as an interviewer, an interviewee, a resume reviewer, a resume writer, a hiring manager, an applying candidate... the works) and I want to give you some tips to stand out and get your first job as a software developer, and some information about how your search is probably going to look.

Searching for a role

Get your resume and cover letter ready for applying to a LOT of roles. I don't exaggerate when I say that you should apply for several jobs a day when you're on the job hunt. It's tedious, but it's a numbers game.

Your resume

Your resume is your personal summary sheet. Your resume is the thing that gets your foot in the door. When an application reviewer (engineer, recruiter, or otherwise) is looking over your resume, don't make it difficult for them to understand who you are and what you know.

If you have online profiles like GitHub, LinkedIn, social media, or even your own personal website, put it on your resume. Don't make them have to search long and hard for you online if they want to know more!

As you illustrate what you've done, avoid buzzwords and be clear. Talk about the tech that you used, impacts you made, and relevant things that you would bring to the table. I should be able to skim your resume in less than 15 seconds and understand what role you want and what your experience level is. Often, that's the most someone will look at your resume when deciding if you should be getting a call.

Your cover letter

I can't tell you how many people skip the cover letter when they apply. As someone who reviews applications, I always look for a cover letter when people are applying. Not everyone will read it, sure, but you might as well show the effort upfront.

A good cover letter follows a simple formula that you can apply to every single job you apply for: Who - Who you are. Easy enough. Where - Where you're coming from. Why - Why you're interested in this company, and show that you researched them. What - What you can bring to the table. When - When you're available to start, and when they can contact you. How - How they can reach you.

Here's a cover letter sample that you are free to take and run with:

Dear [company name, or hiring manager name if you know it], I hope your day is going well! My name is [your name], and I'm a [who you are] at [school, current workplace, anything]. I am very interested in working for [company name] and can start [when you can start]. Your commitment to [company value] and [another company value] that I saw on the website inspired me! The products you build and the values you stand for make [company name] seem like an ideal workplace for me. A little about me, I [insert relevant work experience, extracurriculars, and projects here]. I think these experiences would make me a great candidate for you. Please let me know if there's anything else you need from me. I look forward to hearing from you! I can be reached at [email] and [phone number]. Best regards,

If you get a good flow going, you can ship off your resume and cover letter to at least a couple dozen companies a week.

The process

The interviewing process varies a lot from company to company. At a very (very) high level, this is typically what happens:

  1. You apply online

  2. You talk to the recruiter, who assesses generally what you know, and what you're looking for

  3. You talk to the hiring manager or a team member about the role more in-depth

  4. Technical screen

  5. Onsite (usually consisting of technical and non-technical interviews)

  6. Offer

Now, each of these steps can look different depending on the company.

For smaller companies: The technical screens will likely be more practical. Questions will be more relevant to the technologies and what you'll be using on the job and what they need to hire for.

For large companies: The technical screens will likely be more theoretical. Think data structures and algorithms. Know your graphs and binary search trees and Big-O complexities!

For remote companies: The "onsite" will probably be a bunch of video calls spread across a couple days or so, rather than one big day.

Approaching non-technical calls

When you're about to talk to a hiring manager or recruiter or team member, they will often have some goals in mind. They could be looking for:

  • What kind of team player you are

  • How you deal with conflict

  • Do you have any prejudices against groups of people

  • How you approach problems

  • Why you're interested in their team

  • What you value in a job

  • Would you be a good culture add to the team

  • ... and more!

In these calls, try to assess why someone might be asking you certain questions. That will help you answer them more clearly.

Usually after the team asks you questions, you get time to ask them questions. Always take advantage of this! Ask them about their day-to-day, about work/life balance, about what they like (or don't like) about working there. Ask what matters to you if you were to get an offer.

Approaching technical calls

Technical calls can be so nerve-wracking for a software developer role! I won't get into what algorithms you should practice or what side projects you should build to prep here, but rather how you should approach the calls themselves.

Whether you're at an onsite in person or sharing your screen, you'll be faced with a technical question that will likely involve writing code. When you are asked that question, don't write anything at first. Start by talking out your solution with the interviewer. Use them as your rubber duck! Talk about how you plan on solving the problem and about test cases. Ask them if what you're saying makes sense, or if they think you're missing anything. Involving them in the process makes it a better conversation, rather than a one-way street.

Only after you are both on the same page, start writing your code. Talk through it as you write it. It's okay to have silent moments, but you want them to know your thought process as much as possible.

I can't tell you how many times I've interviewed someone who goes straight to the whiteboard or editor, and just starts writing silently, and doesn't involve me at all. I shouldn't be trying to pull words out of you as an interviewer!

Once again, after the screen, you'll likely get a chance to ask questions. And, once again... do it. Don't pass up on the opportunity to get more information!

The offer stage

At the offer stage, usually you will be contacted either by the recruiter, or the hiring manager. They'll lay out the benefits (healthcare, dental, commute, a desk budget, etc.) as well as your salary, any bonuses, and any stock benefits.

Afterwards, you'll be asked how you're feeling about it. At this stage, I would say: be grateful, say that you need some time to think about it, and then be ready to negotiate. Depending on the company, they might be more or less open to this. Chances are you don't want to work for a place that doesn't negotiate, but not everyone has the ability to say no to a role. But, if you feel you can do it, always try to ask for more.

Getting rejected

When you're job hunting, it's very easy to feel down if you don't hear back from companies, an interview goes poorly, or you start comparing yourself to people. It's a tough field we're going into.

Mark Twain once said, "Comparison is the death of joy." When you start to compare your skills to others, it's hard to not feel as good about your own, or to get a little too competitive about your work and interviews. Work hard and don't let others get you down. It's remarkable how significantly that can improve both your work and your interviewing experience!

Start that gig, and give back!

I have one final thing for you. Once you've gotten that software developer job, be a resource for those still looking. A mentor of mine once said to me, "lift as you climb." As you get new roles and move up in your career, try to pay it forward and make it easier for those less experienced than you to get a leg up. Interviewing is such a stressful process in general, and you never know who could use your help.

With that, good luck!

Hi, I'm Cassidy! I'm based in Chicago, and I love coding, jokes, and mechanical keyboards. ⌨️  My favorite thing to do is help others to be the best that they can be, and I pursue that through teaching, building demos and starter projects on my GitHub, speaking, my newsletter, my live streams, mentoring, advising startups, and even just by making memes. 🤪 You can check out most of these things here. Building for the web has been a blast for me since I was a teenager, and I have no plans of stopping anytime soon!

About The
ReadME Project

Coding is usually seen as a solitary activity, but it’s actually the world’s largest community effort led by open source maintainers, contributors, and teams. These unsung heroes put in long hours to build software, fix issues, field questions, and manage communities.

The ReadME Project is part of GitHub’s ongoing effort to amplify the voices of the developer community. It’s an evolving space to engage with the community and explore the stories, challenges, technology, and culture that surround the world of open source.

Follow us:

Nominate a developer

Nominate inspiring developers and projects you think we should feature in The ReadME Project.

Support the community

Recognize developers working behind the scenes and help open source projects get the resources they need.

Thank you! for subscribing