Ep. 32 - How you can start a career in a different field without experience

05/28/18 • 43 min

Austin had a biology degree, a poor GPA, and a job in the medical field, but he wanted to transition into tech. He had no experience, but he figured out how to gain it quickly and landed offers from his dream companies. In this episode, he shares his advice and methods so that you can do the same.

Written and read by Austin Belcak: https://cultivatedculture.com

Original article: https://fcc.im/2LydTlZ

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Transcript:

In this episode I’ll show you how to quickly gain experience in any field, as well as how you can leverage that new experience to land job offers in that field.

I personally used this strategy to transition from the medical field — where I was working in hospital operating rooms — to the tech industry, where I received offers from Google and other tech companies (along with a 200% raise).

Myths about things you DON’T need when switching fields

Before we dive in, I think it’s important to address a few “myths” about changing industries:

You don’t need an extensive network of contacts. In fact, you don’t need any contacts at all — you can make them all on your own.

You don’t need a degree in the field you want to switch to. Perception is reality, and results speak volumes when it comes to perception. They are worth more than any degree or previous job title. More on that later.

You don’t need money. Everything you need to know can be learned for free. In fact, I’m going to show you how this process can actually help you generate a second stream of income.

Next, I’m going to outline the exact steps I used to land a job in a totally different industry so you can make it happen for yourself.

Part 1: Painting a picture of the perfect candidate

The good news about entering a completely different field is that you are a blank canvas. You can choose your skills and mold yourself into the perfect candidate.

What does perfection look like?

In order to become the ideal candidate, we must first understand what “ideal” looks like in the eyes of the people who will be hiring you. There are two ways to accomplish this:

Job descriptions

Job descriptions are essentially resumes in reverse. They spell out the exact skills you need in order to be successful in that particular role. That sounds obvious, but we are going to be looking at this from an atypical lens.

Let’s take a look at this Growth Marketing Analyst role that I grabbed from Facebook’s site:

Responsibilities

Leverage data to understand our products in depth, identify areas of opportunity, and execute projects to drive growth and engagement of Facebook users. - Drive projects focusing on new user growth, mobile usage, and revenue — working closely with design, product, engineering, and data teams. - Work both on core Facebook products like news feed, notifications, and mobile, and offsite marketing channels like SEO, SEM, and email. - Use tools like Hadoop/Hive, Oracle, ETL, R, PHP, Python, Excel, MicroStrategy, and many other internal tools to work efficiently at scale.

Minimum Qualifications

BS or MS in Engineering, Computer Science, Math, Physics, Statistics. - 1+ years experience with SQL. - 2+ years of quantitative or statistical analysis experience. - 1+ years of experience managing a project. - 1+ years of experience in marketing, advertising or growth. - Ability to process and analyze data sets, and interpret them to make business decisions. - Communication skills and ability to manage a project or product.

Preferred Qualifications

Software development experience. - Internet Marketing experience. What do you see here? What does the ideal candidate look like? What do they need to get hired?

My guess is that you’re thinking, “Ok, they need a degree in computers or math. Then they need at least two years of experience coding and managing projects at a company.”

Well, here’s what I see:

Facebook is looking for someone who understands how to identify trends/patterns within big data that will have a direct impact on revenue. That person also has enough knowledge of programming to efficiently make those discoveries and present them in a simple, concise fashion.

The main issue a lot of people have is that they think the only way to get “experience” is to work at company or have fancy degrees. This is one of the biggest myths when it comes to job searching.

In order to understand it, let’s take a step back and think about why companies hire.

They want someone who will come in and have a large, positive impact on their bottom line.

Someone could have a PhD in Co...

Written and read by Austin Belcak: https://cultivatedculture.com

Original article: https://fcc.im/2LydTlZ

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Transcript:

In this episode I’ll show you how to quickly gain experience in any field, as well as how you can leverage that new experience to land job offers in that field.

Myths about things you DON’T need when switching fields

Before we dive in, I think it’s important to address a few “myths” about changing industries:

You don’t need an extensive network of contacts. In fact, you don’t need any contacts at all — you can make them all on your own.

You don’t need money. Everything you need to know can be learned for free. In fact, I’m going to show you how this process can actually help you generate a second stream of income.

Next, I’m going to outline the exact steps I used to land a job in a totally different industry so you can make it happen for yourself.

Part 1: Painting a picture of the perfect candidate

The good news about entering a completely different field is that you are a blank canvas. You can choose your skills and mold yourself into the perfect candidate.

What does perfection look like?

In order to become the ideal candidate, we must first understand what “ideal” looks like in the eyes of the people who will be hiring you. There are two ways to accomplish this:

Job descriptions

Let’s take a look at this Growth Marketing Analyst role that I grabbed from Facebook’s site:

Responsibilities

Minimum Qualifications

Preferred Qualifications

Software development experience. - Internet Marketing experience. What do you see here? What does the ideal candidate look like? What do they need to get hired?

My guess is that you’re thinking, “Ok, they need a degree in computers or math. Then they need at least two years of experience coding and managing projects at a company.”

Well, here’s what I see:

In order to understand it, let’s take a step back and think about why companies hire.

They want someone who will come in and have a large, positive impact on their bottom line.

Someone could have a PhD in Co...

Previous Episode

Ep. 31 - Good coding instincts will eventually kick you in the teeth

Some people have very strong coding instincts. They can solve problems just by looking at them, and feel like rockstars. But being a rockstar coder can only get you so far. You need one other crucial element: discipline. In this podcast, Bill shares his disciplined approach to writing code and to work in general.

Written by Bill Sourour: http://twitter.com/billsourour

Read by Abbey Rennemeyer: http://twitter.com/abbeyrenn

Original article: https://fcc.im/2IzwWdH

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Transcript:

I wrote my first few lines of code almost 32 years ago, when I was 6 years old. I developed very strong coding instincts. I could look at any problem and immediately know how to solve it, just by intuition.

By the time I started coding the web for a living, I felt like a rock star. I found and fixed bugs faster than any of my co-workers. My team started assigning me all the most challenging features and the most nagging bugs. They even started calling me a “wizard.”

But following your intuition can only take you so far. I hit a plateau. And no amount of coding instinct was going to push me past it.

The trouble with trusting your gut

Unfortunately, intuition as a technique for learning and problem solving doesn’t scale very well. When you rely on instinct and intuition alone, you get a curve that looks like this (See original article for graph).

Of course, you can choose to accept your limits and only ever deal with problems below the line. This will indulge your “rock star coder” fantasy, but it will quickly begin to limit your growth and your career. Plus, it’s boring.

As I pushed myself further and further ahead in my career — and started to really challenge my own abilities — I began to notice a disturbing trend. I was no longer the fastest kid on the block.

I had always known that I’d eventually run into people smarter and more talented than me. (My delusions of grandeur were still grounded in reality. I’m no genius.)

But when I looked around, I realized that some of the people beating me were not using a superior intellect or some sort of innate gift for code. They just had a secret weapon that I sorely lacked: discipline.

It turns out that a consistent, repeatable, methodical approach to learning and problem solving will eventually outperform any natural gifts — or instincts — that you may have developed.

Let’s tool up those problem solving abilities

Regardless of who you are, how much passion or natural talent you have, you will eventually hit a hard ceiling. I’m going to share with you a few techniques that will dramatically improve your disciplined problem solving abilities.

I’m assuming that, if you have a debugger, you’ve already run it, Googled the output, and had no luck.

I’m also assuming that if the problem was reported by someone else, you have been able to reproduce the problem. This second assumption is a big one. If you can’t reproduce the problem, then that needs to be your first step.

You need to compare the context and environment in which the problem occurred to the context and environment in which you are trying to reproduce it. Start eliminating any differences you can, one by one, until you can reproduce.

Once you can reproduce the problem, and after the debugger has failed to be of any use, you can try the following disciplined approaches.

RTFM

Read the documentation, you fool! (Admittedly this isn’t what RTFM stands for exactly, but there may be children reading.)

Actually read it — more than once if you need to. Don’t just skim it looking for something you can copy, paste, and pray will work.

The problem is you want an answer fast. You want that thrill of victory. But you’re not willing to put in the work. So slow down. Take a breath. Grab a coffee. And read the relevant documentation all the way through.

If you have no documentation, consider creating some, then sharing it with others after you’ve fixed the problem.

Test Your Assumptions

If you expect something to work and it doesn’t, it’s because you’ve made a bad assumption somewhere along the way. Take an inventory of your assumptions and try to prove that each one is true.

Start with the most basic assumptions that can be quickly tested. Is the server actually running? Is it connected to the network? Is everything spelled correctly? Are all the brackets and semicolons in the right place?

If you don’t start with the simple things, and it does turn out to be one of these things, when you finally figure it out you will want to jump out a ...

Next Episode

Ep. 33 - Code dependencies are the devil

Have you built your app on someone else's code? And beyond that, does the "secret sauce" of your product depend on external libraries or frameworks? While it's tempting to use the latest and greatest tech as soon as it comes out, that's not always a great idea. In this episode, Bill explains why, and what to do to protect your code.

Written by Bill Sourour: https://twitter.com/BillSourour

Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

Original article: https://fcc.im/2HerXO5

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Transcript:

“Change is the only constant...” – Heraclitus (Philosopher)

The tools, libraries, and frameworks we use to build our web applications today are drastically different from the ones we used just a few short years ago.

In a few short years from now, most of these technologies will have changed dramatically again. Yet, many of us make these a central, inextricable part of our apps.

We import, use, and inherit from the flavor-of-the-month frameworks as if they’re all going to be around and unchanged forever. Well... they’re not. And that’s a problem.

After 20+ years of developing, designing, and architecting web applications, I’ve come to appreciate two important truths:

External dependencies pose a great threat to the long term stability and viability of any application.

It’s increasingly difficult — if not impossible — to build any kind of non-trivial app without leveraging external dependencies.

This article is about reconciling these two truths so that our apps have the greatest chance of long-term survival.

The rabbit hole is very deep indeed.

If we start thinking of all the things our web apps depend upon it’s easy to think of a dozen or more before we even get to the code:

Power Connectivity Firewall DNS Server Hardware (CPU, Disk, Ram, ...) Cooling Virtualization Platform Container Platform Operating System Web Server Platform App Server Platform Web Browser

As developers, it’s good to be aware of these things, but there’s often not much we can do about them. So, let’s ignore them for now and talk only about the code.

In code, there are three kinds of dependencies:

1. Dependencies we control This is code written and owned by us or our organization.

2. Dependencies we don’t control This is code written by a third party vendor or open-source software community.

3. Dependencies once removed These are the code dependencies our third-party code dependencies depend upon. (Say that three times fast!)

We’re going to talk mainly about dependencies we don’t control.

Dependencies we control and dependencies once removed can still cause headaches, but in the case of dependencies we control, we should be able to directly intervene and mitigate any problems.

In the case of dependencies once removed, we can usually rely on a third-party to take care of it for us, since they are dependent on these, too.

Why third-party code dependencies are good

A large portion of your web application exists to solve common problems: authentication, authorization, data access, error handling, navigation, logging, encryption, displaying a list of items, validating form inputs, and so on...

Regardless of which technology stack you use, there’s a good chance that common solutions to these problems exist, and are available as libraries that you can easily acquire and plug-in to your codebase. Writing any of this stuff completely from scratch is generally a waste of time.

You want to concentrate on code that either solves an uncommon problem or solves a common problem in an uncommon way. That’s what makes your application valuable: the code that implements the business rules that are unique to your app alone — the “secret sauce.”

Google’s search and page ranking algorithm, Facebook’s timeline filtering, Netflix’s “recommended for you” section and data compression algorithms— the code behind all of these features is “secret sauce.”

Third-party code — in the form of libraries — allows you to quickly implement those commoditized features of your app, so you can stay focused on your “secret sauce.”

Why third-party code dependencies are bad

Take a look at any non-trivial web-app built in the last couple of years and you’ll be absolutely astounded by the amount of code that actually comes from a third-party library. What if one or more of those third-party libraries changes drastically, or disappears, or breaks?

If it’s open-source, perhaps you can fix it yourself. But how well do you understand all the code...