How to Land Your First Development Job in 5 Simple Steps

Footprints in the Desert Sand — Edward Musiak (CC BY 2.0)

When you’re just getting started, it seems like it’s impossible to break into the market. Everybody wants to hire somebody with experience. How do you get that experience if nobody will hire a developer with no experience? This article will guide you step-by-step to help you land and ace coding interviews. If you have the chops, nobody will care that you’ve never worked for anybody before.

Let’s start with what not to do. When I was hunting for my first software development job, I made every mistake in the book. I was a young teenager, fresh out of high school. I hadn’t started college yet. I wanted the experience of getting paid to write software.

I thought I was hot stuff. I was about 18 years old, and I already had more programming “experience” than most job listings were asking for. I started programming around 5–6 years old. I was still learning to read and write when I wrote my first program in BASIC. It looked like this:

10 PRINT "HELLO, WORLD!"
20 GOTO 10

My other programs got much more complicated, of course. Eventually I branched away from BASIC and learned Pascal, Assembly Language, C, and C++. I knew the x86 processor on a very low level. I loved experimenting with graphics and music with code.

I even wrote very simple programs in pure machine code. In other words, instead of bothering with a high-level language like Assembly (that’s a lame joke, but it’s higher-level than machine code), I wrote in hexadecimal code.

Hex code is basically the same as writing code directly in 1’s and 0’s. It’s just representing numbers in a way that’s more efficient for humans to read and type. It looks a bit like this:

49 66 20 79 6f 75 20 63 61 6e 20 72 65 61 64 20 74 68 69 73 2c 20 79 6f 75 27 72 65 20 68 69 72 65 64 21 20 4a 75 73 74 20 6b 69 64 64 69 6e 67 2e 20 42 75 74 20 79 6f 75 27 72 65 20 69 6e 20 61 6e 20 65 6c 69 74 65 20 63 6c 75 62 2e 0a 0a 47 65 74 20 31 30 25 20 6f 66 66 20 61 6e 79 20 70 75 72 63 68 61 73 65 20 66 72 6f 6d 20 68 74 74 70 73 3a 2f 2f 65 72 69 63 65 6c 6c 69 6f 74 74 6a 73 2e 63 6f 6d 20 77 69 74 68 20 74 68 65 20 63 6f 75 70 6f 6e 20 63 6f 64 65 3a 20 68 65 78 63 6c 75 62
Note: Don’t try to run that code, it’s just a hex dump of a secret message, not intended as instructions for any CPU.

Basically, I thought that if I could come up with an idea for a program and make it actually work by typing hex code that the machine directly understands, there was no challenge too big for me!

Tech investments were heating up, and well funded software startups were popping up all over. As any ambitious kid who knows nothing about software hiring would, I typed up a resume and stuffed it with every language I’ve ever coded anything in. It looked something like this:


Skills:

Over 10 years’ programming experience*
Photoshop, ACiDDraw, 3D Studio Max**

Languages

BASIC, QBASIC, Pascal, ASM, x86 machine language, C, C++, MS DOS Batch, Perl, AutoLISP.


*Remember, I was fresh out of highschool. True, I’d first coded more than 10 years previous, but my “experience” consisted of making silly games and goofing off on hobby projects.
 **How the cool kids designed user interfaces

This resume did get me interviews, but they didn’t go so well.

My First Code Interview

Impressed with my amazing list of skill keywords, I went into my very first code interview feeling totally rad about myself. The interviewer glanced at my resume, and said, “Take this piece of paper and write a class in C++ that keeps a sorted list of names. It should have two methods: add and list.”

My heart sank through the floor. When I add a new name to the list, I have to insert the name so that it’s alphabetically sorted by last name…

I was confident I could easily do this with simple functions in C, but I was honestly pretty new to C++ at the time. What was the class syntax again? How do I define the methods? Do I need virtual methods or static methods or public or what? What were the differences?

Of course if I was at home with my C++ book, I could just flip to an example and crank this out, no sweat! I always have my reference books around when I’m coding. This is totally unfair! I know I could do this job if they’d just let me consult a book.

And WTF?!!! Who in their right mind codes ON PAPER?! Seriously? Give me a computer and a book, and I’ll crank this out in no time.

I gave up and left the interview feeling TOTALLY CRUSHED.

Back to the drawing board.

Step #1: Unpuff your resume.

Let’s talk about everything that’s wrong with my first programming resume. Every experienced hiring manager can spot a puffed up resume from miles away. I wasn’t fooling anybody.

Resume Tip: Puffing up your resume to make up for your lack of experience isn’t going to help you. It’s going to hurt you. If you’re a junior developer, own it: “Jr dev with a passion for learning!”

If I had to rate my skills with all these things at the time on a scale of 1–10, I’d rate them like this:

  • Photoshop: 8
  • ACiDDraw: 3
  • 3D Studio Max: 2
  • Actual graphic design skills: -10
  • BASIC: 8
  • QBASIC: WTF? Group with BASIC, poser.
  • Pascal: 8
  • ASM: 6
  • x86 Machine Language: 1 (only tiny, rudimentary programs possible)
  • C: 6
  • C++: 1
  • MS DOS Batch: 9
  • Perl: 3
  • AutoLISP: 2
Resume Tip: If you would rate yourself less than a 5 on any skill, don’t put it on your resume.

I was ace at Photoshop. I spent a lot of time in it and I really knew my way around the features and menus, but since I’m a terrible designer, all the technical Photoshop know-how in the world wouldn’t help my employer much. Why set myself up to disappoint people (including myself)?

After some brutal self-honesty, let’s see what we’re left with:

BASIC, Pascal, ASM, C, MS DOS Batch

Resume Tip: If nobody is hiring for it, and you’re just bragging about a worthless skill, leave it off your resume.

Now we’re down to Pascal, ASM, and C.

This isn’t to say that my other skills weren’t valuable. But listing all my skills/passing interests indiscriminately certainly wasn’t helping hiring managers understand my core competencies, or what I really wanted to do.

Now let’s sort the skills by relevance. My perception was that Pascal was mostly a learning language, and it was still used, but in decline in the job market. I really wanted to get a job coding in C. At the time, a lot of software needed to be hand-optimized in Assembly when there are hot spots that need optimizing, so Assembly was still a useful skill:

  • C
  • ASM
  • Pascal

Ah, much better. And now it’ll fit in a little summary at the top of my resume:

Passionate junior software developer skilled in C, ASM, and Pascal.

Step #2: Practice until you can live code on the spot.

In your new role, you’re going to be asked to write code on the spot every day. You need to be ready to prove you can do it when you walk in for the interview.

My Second Programming Interview

With a revised resume, I was in a much better position to pass an interview. I was confident enough in C, x86 ASM, and Pascal that if they asked me to code on paper or on a whiteboard without any books available, I could do it.

My second programming interview was much different from the first. As the CEO was giving me a tour, he got called away unexpectedly, and left me to hang out with some other developers. When he returned, I was busy helping them. I got hired on the spot, stayed the rest of the day, and came into work first thing the next morning. Best interview ever.

At that job, I got to use C, Delphi (basically Pascal++), and C++. That’s also where I was first introduced to Java, and eventually, a cool new in-browser web scripting language called JavaScript. I had no idea how important that would be at the time.

How was I able to start contributing right away during my second programming interview? I came prepared. I had the skills I needed to make an immediate impact.

The fact is, you’ll learn most of what you need to know to be productive on the job, but the sad reality is that employers don’t care. They want you to hit the ground running, even as an entry level junior developer.

If you’re fresh out of a dev bootcamp, or you’ve got less than a year or so of experience, that’s really an unrealistic expectation, but if you want to land the job and avoid washing out, that’s what you need to be prepared for. You need to learn as much as you can before you step into the interview.

A fresh bootcamp grad will probably need a couple months’ full-time work experience building apps to really hit the productivity pace employers want to see.

After you get through training for roughly 1,000 hours on code exercises and practice projects, you’ll need an additional 320 hours or so building more complex apps at the edge of your abilities.

What do I mean by “more complex apps?” I mean that they should be larger projects, complete with user logins (preferably passwordless), and an app framework (I recommend React + Redux. Angular 2 is also popular. If you go with Angular 2, check out ngrx/store).

Need app ideas? Check out “The Best Way to Learn to Code is to Code: Learn App Architecture By Building Apps”.

Best case scenario, you need at least 1320 hours of practice to really be prepared for your first programming job.

Step #3: Study up.

In addition to being capable of building real apps, you’re also going to need to impress in the verbal interview, and have a good understanding of some core fundamental programming concepts.

Generally speaking, that means you’re going to need to read some books and blog posts, or watch some videos, or take some courses. But don’t study aimlessly. You should have a direction in mind. Check out “10 Interview Questions Every JavaScript Developer Should Know” and my blog post series, “Master the JavaScript Interview”.

Learn the common questions asked in job interviews, and approach the interview with a good understanding of the concept. That means you’ll need to learn about each concept and get some practice applying it in real code.

For example, when the interviewer asks “What is a closure?” you should not only know the definition, you should be able to list multiple use-cases for closures, and explain why they’re useful.

Step #4: Build a portfolio.

Designers and photographers are expected to show up with a portfolio: a collection of sample projects they’ve completed to demonstrate the quality of their work.

These days, it’s more and more common that hiring managers expect the same of developers. It’s extremely helpful to us if we can glance through some code that you’ve already written. Is your GitHub account full of learning projects and little practice apps? Great!

This gives us a good indication of where you are at in terms of your skill development. If you don’t have a GitHub account, and you’ve never publicly released any source code or contributed to any open source projects, that tells us something about you, too.

Maybe you think you don’t have time. Do you think you’re the only person with a family, or the only person who has signed NDAs with companies and written code we’re not allowed to share?

You’re not. Time is valuable to everybody else, too. But your career is important. Demonstrating your commitment and your passion is important. If you fail to have a portfolio that we can look at, that’s definitely a red flag. Maybe you’re not passionate enough? Maybe you don’t actually like to code enough to do any of it in your spare time? (If that’s the case, you should consider finding a career that is more in-line with your interests and passions).

Maybe you think I’m judging you unfairly. The reality is that others will, too. Some will toss your resume right into the trash if they don’t see a GitHub link. Do you really want to take that risk?

Stop making excuses for yourself and carve out the time. This is your career. This is what you’re going to spend a huge share of your waking hours doing with your life. Take it seriously. Put in the work. Get it done.

Step #5: Work on your people skills.

The stereotype of the socially inept geek is played out. Those days are over. That doesn’t mean you have to be an extrovert. What it does mean is that you need to treat other people with respect at all times.

You need to know how to make friends, collaborate, and present yourself well. If you want to make friends fast, learn to recognize and show gratitude for opportunity. Showing appreciation for other people is probably the fastest way to get in their good graces.

Learn and practice empathy. Make it part of your personal brand. Empathy is the most important skill a software developer can have. Without it, you have nothing.

Without empathy, how will you put yourself in the shoes of the software user? How will you begin to understand the needs of the business team, or your manager, or your coworkers? If you can’t understand what other people need, why they need it, and how you can work with them to deliver on those needs, life is going to be a lot harder for you.

Empathy is something that you can practice. When you’re interacting with others, especially when you disagree, make a conscious effort to put yourself in their shoes. Try to understand why they feel the way they feel, and what you can do to help.

Master your personal elevator pitch. Understand your strengths. What sets you apart? How can you present yourself well in the first few seconds? Every time you move from one job to another, meet new people, or take on contract work, you’re going to need to sell yourself.

Recognize that in today’s society, everybody has a personal brand, whether you consciously think about it that way or not. It’s reflected in your social media, the way you express yourself through style, and the way you communicate.

If you’re going to have a personal brand, you might as well own it, shape it, and manage it. What kind of person do you want to be? How would you like others to see you? Give it some thought. Write down a list of traits you want to be known for, and then get busy developing and practicing those traits.

Make sure they’re visible every time you communicate with others.

Empathy is the most important developer skill. Practice it.

Conclusion

  1. Unpuff your resume: You’re a junior dev with a passion for learning. Own it. Use it to your advantage. Dev teams need to hire junior developers. Your inexperience is part of your value.
  2. Practice: Real, deliberate practice with laser focus and a game-plan. You need to put in about 1,000 hours in coding exercises, and another 320 hours or so building real applications. Do that, and you’ll be prepared for most of the live coding challenges you’ll face in interviews.
  3. Study: Read books. Check out an online course. Most importantly, get familiar with common interview questions and be prepared to ace them.
  4. Build a portfolio: In addition to being a great tool to assess your skill level, if you don’t have a portfolio, it will make the hiring manager question how seriously you take your development career, or how passionate you are about programming. Time to stop making excuses and get it done. This is a great place to put those apps you’re going to build for practice. (See #2).
  5. Develop people skills: Empathy is the most important skill for software developers. Maybe the most important skill for life. Practice considering other people’s perspective. You’ll build more user-friendly apps and have better relationships with your coworkers and team leads.

Want to get on the study fast-track? I’ll help you cross the chasm between junior and mid level JavaScript skills to advanced JavaScript application development.

Learn The Two Pillars of JavaScript (prototypal OO & functional programming) in depth, along with critical skills like TDD. Watch me code real apps, too.

Learn JavaScript with Eric Elliott


Eric Elliott is the author of “Programming JavaScript Applications” (O’Reilly), and “Learn JavaScript with Eric Elliott”. He has contributed to software experiences for Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, and top recording artists including Usher, Frank Ocean, Metallica, and many more.

He spends most of his time in the San Francisco Bay Area with the most beautiful woman in the world.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.