Some stuff I’d like to say to new developers

Sub title: Especially if you’re coming out of a boot camp

I took a very traditional route into Software Engineering. I got interested in computers and programming in high school, then got my B.S. C.S. in 2012 and my M.S. C.S. in 2018. I’ve been in the work force for over 8 years now.

With the rise of different programming boot camps and programs (like Lambda School) I’m seeing more and more people look to make the jump into the software engineering field. And with good reason! When you look at the labor statistics website it claims that software developers make an average of $86,000 which is higher than the median household income in much of the US.

Add to that sites like claiming astronomical salaries from some big name tech companies and it’s easy to see why people are at least curious to try out the field.

With all of that at play I have a pretty steady stream of people reaching out curious about software engineering and what it takes to get a job as a software engineer. I wanted to lay out a few thoughts that might help a wider audience from common questions I’ve heard

Can I get a job as a software engineer without a degree?

Short answer — yes! Longer answer — probably, but it’s not going to be easy.

Take a look at the Lambda School outcomes report for 2019. It clearly states that they are placing students with real jobs after they graduate from the school. Lots of big name tech companies have employee advancement programs that train existing employees to be software engineers. So yes, it is totally possible to get a job as a software engineer without a degree.

With that being said you should know that it’s not going to be easy. Even though there is a shortage of software engineers job postings for them tend to get an excessive number of applicants. Even small companies are often overwhelmed by the number of resumes and plenty of them are fake or inflated (more on that below).

So with all of those resumes flooding in, lots of them with great buzzwords, getting yours noticed and read without a degree will be tricky. Some quick tips

  1. Do show evidence of work — a github profile with actual projects, open source contributions, stuff you’re proud of
  2. Do show what education you’ve got and the initiative you’ve taken to try and get more experience(boot camps, classes, projects, internships, etc)
  3. Do not inflate your resume — I’ve interviewed people who lied on their resume and it shows in a hurry and I mark those applicants as don’t call back. Present your strengths honestly, don’t inflate.
  4. Be realistic — if you’re graduating from a 9 month bootcamp and no work experience shoot for junior dev positions, don’t apply to senior roles when you don’t have the experience or knowledge. You’re starting off from scratch and that’s fine! Just be ready for the level you’ll come in at
  5. Don’t get discouraged when you don’t hear back right way — keep trying. There are many, many reasons why someone might skip over a resume from a boot camp grad (maybe they’re team is over worked and they can’t take on a junior, maybe they tried a grad from another bootcamp and it didn’t work out, maybe they just have too many resumes and that’s an easy filter). But not getting the first job, or the 500th you’ve applied to doesn’t mean you won’t get the 501st. Keep expanding your experience, keep trying!

Ask yourself if you like programming

Hollywood likes to show programming as Tony Stark manipulating 3D diagrams and building flying suits, when in reality it’s slow, detail, often painstaking work. There will be times you’ll feel like a hero when you fix a bug that’s been plaguing your time, but there will be lots and lots of other times you are frustrated on a problem for days before you make any progress.

As you’re working through your bootcamp or trying some free programming tutorials ask yourself if you like what you’re doing. If you feel happy, curious, and enthusiastic when you solve a complex bug and get it to work you’re probably on the right track, but if you feel frustrated, tired, or discouraged you might want to take a step back and evaluate if this field is for you.

Not just because you should do something you enjoy, but because if you hate what you’re doing you won’t be a good software engineer. Unlike some fields where the problem is visible in front of you and you can work through it whether you feel like it or not, computer science is almost all in your head. You need to be ready to apply critical thinking, form connections between abstract constructs, and problem solve. If you hate what you’re doing you won’t want to do any of that and it will be much harder to succeed.

Don’t get dazzled by the money potential you see online, take your time to see if this field is right for you.

Your interview will probably involve data structures and algorithms, even if your job does not

A lot of programming is data structures and algorithms, and knowing when to use which of each of them. A crucial part of being a programmer is being able to reason about different data structures and algorithms, grasp the tradeoffs between selecting them and apply them to build software.

“But I’m a React Front End Developer!” I hear you say, “I do design and user workflow, I focus on user experience, why would I need to know anything about data structures?”

And you’re probably right, there are probably jobs out there that don’t require any DS/algo knowledge. You can probably write a lot of React apps just using hash tables or lists.

In my experience most interviews still involve some level of DS/algo question for two reasons

  1. They’re a relatively simple form of problem that tell me if you can reason about abstract concepts and problem solve
  2. They’re a great way to force you to write code

I’ve been in plenty of interviews where the applicant talks a great game, seems amazing, has all the right buzzwords on their resume, then we hand them a marker (or virtual coding space) and ask them to implement fizz buzz and they fall apart. If I ask you an algorithms question I get to see you actually write code, rather than just quote blog posts or tweets you’ve read.

All Software Engineers Feel Dumb Sometimes

Several times a week (if not once a day or more) I think to myself, “I have no clue what is causing this problem.” The severity of the “no clue” part varies pretty widely — it could be 30 minutes of figuring out why a build broke, days of debugging a dependency that’s failing, or weeks of tracking down transient issues. And I feel like an absolute idiot the whole time.

It’s only human — you wonder if someone else on your team could figure this out quicker, you wonder if someone else would know the problem better. Imposter syndrome is real.

So you’re not alone when you’re confused by a new language or framework. All software engineers feel dumb sometimes. Don’t get discouraged or down, remember that

  1. Software engineering is a great field to feel confused in — if you deep dive the code, read the manual, and dive in you can understand any framework or problem
  2. If you feel dumb, it could just be because this field is really, really difficult. If you find yourself struggling with a concept it could just be because it’s complicated
  3. Ask! If you’re confused, chances are someone else in the room is confused too. It may be a conversation that should be taken off line, but don’t be afraid to ask for clarification!

Be the deep dive guy!

If you want to show that you can contribute as a software engineer off the bat be the bug squashing, deep diving, code reading volunteer. Don’t wait for someone to show you the problem line, don’t ask for help before you’ve looked, clone that repo, grab the line number from that exception, and start deep diving!

That does a couple things for you right off the bat

  1. Shows you’re not afraid of code, you’re willing to go look and solve problems
  2. Gets you reading your teams code base, which is incredibly critical

Here are a couple tips for getting started doing deep dives

  1. Take notes — lots, and lots of notes! This will help you show evidence of your work, could help document some functionality that’s misbehaving, and lets you walk someone else through your rationale for a suggested fix
  2. Assume nothing! That function labeled multipleNumbers() might have a side effect that’s not obvious. Question all of your assumptions and go a little ways down each path until you’re comfortable with what it does
  3. If you’re spending a lot of time do regular check ins with a mentor or team lead to make sure they don’t think you’re too far off in the weeds (this is where your notes come in). Tell them what you’re thinking, ask if they want to redirect you. That shows that you’re a team player and gives them a chance to pull you back if you’ve gone too far down the rabbit hole.

We are so excited you are looking into software engineering!

Oh my word, I can’t even explain how excited we are that you’re here and looking into this! I love programming! It makes me excited to get up and go to work, it motivates me to blog about it, it keeps my brain cooking and trying new issues. Software engineering is a blast!

And you know what I need more of? Qualified coworkers who can do quality engineering! And that could be you! Just because I took a very traditional route into this field doesn’t mean you have to. You’ll bring in a different perspective and experience and that’s great!

Dive in, start learning, let’s build stuff!

Engineer, Cloud Enthusiast, Powershell Aficionado, Java Fan, Docker fan, other nerd stuff. All opinions are my own.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store