Callbacks confused the heck out of me when I first saw them. There were two things I kept getting caught up on: why do I need a callback and how do I write one? That’s what I will cover with this article.

tl;dr

What is a callback and why do I need it?

Before we get to the juicy details, let me start by giving a very brief explanation of a callback. Simply put, a callback is a function passed as an argument to another function. Sounds crazy, I know. But think of it this way: if you are at all familiar with writing functions, you likely feel very comfortable passing a string or number to a function, then using that string or number within the function body itself.

Callbacks are no different. Just like a string or number, you can pass a function (known as a callback) as an argument. When you do so, you are passing the entire function, not just what the function outputs. This is because functions are first class data types. That means they can be:

1. Passed into a function
2. Returned from a function
3. Assigned to a variable
4. Stored in a data structure

So, with that out of the way, let’s get to the nitty gritty. First, why use a callback? The best explanation I’ve heard:

“Callbacks allow us to ensure that a particular bit of code finishes execution.”

Picture yourself in your car in a parking lot. To leave your parking spot, you need to reverse the car, but you can only do so once you’ve shifted into the reverse gear. In this scenario, you backing out of the parking spot is the function and the process of shifting into reverse is the callback. Without shifting into reverse, you cannot back out of your spot.

How do I write a callback?

For me, the description of the what and why of callbacks is a bit useless without some example to show where they might be useful. Before I get to a legit example, let me show you a bare-bones breakdown of setting up a callback.

In the code above, the function on line 1 is the callback. It’s sole purpose is to take in an argument for the parameter called name and return “Hello name“.

The function on line 5 is where the callback is passed as the argument. The function, named inputName takes two arguments: name and callback. It then calls whatever function gets passed as callback and provides name as the argument for the callback function. Remember, when we pass a function to another function, what is being passed is the function body, not the function output.

In this case, when we call inputName on line 9, we pass in “Cortney” as the name argument and the function called sayHello as the callback argument. At this point, the inputName function would look like this:

function inputName("Cortney", sayHello) {
   sayHello("Cortney");

};

Then, since our inputName function calls the sayHello function, the sayHello function would look like this:

function sayHello("Cortney") {
   return "Hello " + "Cortney";

};

This whole process will output “Hello Cortney”.

“What is the point of all this?” you may ask. “I could do all this with a single function”, you say. And it’s true. The scenario above would probably be better served by a single function. I only used this to show you a simple example of how callbacks work. To understand the real beauty of callbacks, we can use a more real world example. Let’s assume you want to write some code (perhaps a calculator app) that performs calculations on two numbers.

Rather than having a single function that contains all the possible types of equations one could run (which would require lots of if/else statements), you can have separate functions for each type of calculation. Then, you can pass that calculation type as a callback to a function that performs the calculation. That’s precisely what is happening above on line 17. The function performCalculation accepts three arguments: two numbers and a callback (referred to here as calculationType) that determines what type of calculation happens to those numbers.

And that’s that! Hopefully you’ve learned a little about the nature of callbacks, but if my explanations didn’t do it for you, check out this article, this YouTube video, and this website.

Like what you read?

Give it some ❤ and follow me! You can also lookout for similar articles in the Layman’s Coding series where I describe coding concepts with very little jargon and lots of pictures. Didn’t like it? It’s cool. We can still be friends.

Want $500 off your Bloc tuition?

If you’re serious about learning to code, consider signing up for a coding bootcamp like Bloc. If you send me a message on LinkedIn with your full name and email address, I can refer you. I’ll receive a cash bonus and you get $500 off your tuition cost. No strings attached. Once I’ve submitted your email, a member of Bloc’s team will contact you to get you started.

Closures. A term I learned to detest when I encountered it a month ago during my web development apprenticeship at Bloc. Why you may ask? Because there are numerous tutorials out there on closures, but none of them explained things in a way my brain agreed with. It’s taken me a lot of practice, but I’ve finally found a metaphor that works for me. So, if you’re like me and you’ve watched the YouTube videos, read other Medium articles, and scoured the MDN docs but still don’t have a clear understanding of closures, read on. (Note: I have nothing against the tutorials linked. On the contrary, I actually found them quite useful, but only when I had already gained some knowledge about closures. They don’t seem as aimed towards beginners as I’d like).

I hope my article will make closures easier to understand. If my explanation doesn’t work for you though, check out the resources linked above. I won’t even be mad if you like those articles and videos more than mine so long as you find some explanation that works for you.

tl;dr

A closure is a function wrapped inside an outer/parent function. It has access to the variables in the outer/parent function.

The Birthday Party Example

Using a metaphor, I think I can make closures even clearer for you.

Try to remember a birthday party you had when you were a kid. Picture all the corny games you played, the gifts you received, and the people that attended. This memory is a snapshot of the environment (i.e. the party guests, the background music, the chocolate cake) that made up that event. Since you aren’t a timelord, you can’t go back to that birthday party. (If you are a timelord, email me ASAP). But you can still access the information about the birthday party because you kept it in your memory. And with access to this memory, you can do new things with the information: you can laugh with your friends about what your Aunt Susan wore or recall the awesome Poo-Chi you received that became obsolete 6 seconds after you opened it.

In the above scenario, your memory is the outer/parent function. It has all the information about your birthday party. The closure is your joke. It is only accessible when you are accessing your memory of the birthday party. Let’s break this down even further using info provided by the MDN docs:

A closure is the combination of a function and the lexical environment within which that function was declared.

Our closure is the function called joke(). The lexical environment is the info in the outer/parent function called birthdayParty().

This environment consists of any local variables that were in-scope at the time the closure was created.

In our case, this variable is the parameter person1 that takes an argument that gets passed into birthdayParty(). So, our environment is made up of one argument.

The really nifty thing about closures is they can access info from their parent function even after the parent function has already closed for business and gone home. When we declare the variable auntSusan we, pass it the parent/outer function birthdayParty() and create a reference to the closure function joke(). Then, when we console log auntSusan and pass it an argument, the argument applies to the reference of joke(). Let me demonstrate with another example:

Above, the closure is the function iAmTheOuterFunction(). The lexical environment contains everything from the parent function iAmTheOuterFunction(). In this case, the closure will have access to the variable outerVariable.

When you call the parent function iAmTheOuterFunction() on line 11 and assign it to the variable favoriteFood, you are creating a reference to the closure function iAmTheClosure(). We’re basically saying “give me all the info contained in iAmTheOuterFunction() and store it in a variable called favoriteFood”. At this point, the parent function’s job is done. When favoriteFood is console logged on line 13, it will execute the closure using all the info in the lexical environment. Since the closure has access to the outerVariable and the closureVariable, it can successfully return these variables and output “cheese sandwich.”

So, what’s the big deal?

Even if you understand how to write a closure, it’s pointless if you don’t know when to use one. One of the biggest and most valuable uses of closures in JavaScript is to protect data privacy. For instance, say you declared the variable outerVariable in the global scope (i.e. outside of the parent/outer function iAmTheOuterFunction()) and got rid of the parent function so you only had the closure iAmTheClosure(). In JavaScript, you could later change the value of the variable outerVariable since it is a global variable and everything has access to it. You might even do this by mistake by forgetting you already have a variable called outerVariable and accidentally creating another one with a different value. If you store this variable in the parent/outer function that encloses a closure function, you make sure only the closure has access to that variable.

“But, the nature of local scope already does this in a function,” you say. Why can’t you just put outerVariable in iAmTheClosure() to ensure only this function has access to it? If you do this, you wouldn’t be able to do some cool stuff like reuse the function in an incremental fashion. W3Schools provides a really good explanation of this here. The important thing to remember about closures is that they are “function factories.” When variables are stored in the lexical environment of the parent/outer function, they are kept safe for use only by the closure functions contained in the parent/outer function. For instance, let’s look again at our birthday code:

When we set auntSusan to the parent/outer function birthdayParty(), you make it so you can continually reuse auntSusan and pass it different arguments without having to rewrite the whole function. If we did console.log(auntSusan("skorts"));, we are passing in a new argument for the clothing parameter in the closure function joke() but the value of person1 remains auntSusan. In this scenario, the console would print "Wanna hear a joke? Aunt Susan wore skorts!"

If we wanted to change person1, we could create a new reference to our closure like this: var uncleFred = birthdayParty("Uncle Fred"); then we could console.log(uncleFred("fanny packs")); We used our “function factory” to replicate the structure of the closure without having to code a whole new function. In this case, we would get "Wanna hear a joke? Uncle Fred wore fanny packs!"

Like what you read?

Give it some ❤ and follow me! You can also lookout for similar articles in the Layman’s Coding series where I describe coding concepts with very little jargon and lots of pictures. Didn’t like it? It’s cool. We can still be friends.

Want $500 off your Bloc tuition?

If you’re serious about learning to code, consider signing up for a coding bootcamp like Bloc. If you send me a message on LinkedIn with your full name and email address, I can refer you. I’ll receive a cash bonus and you get $500 off your tuition cost. No strings attached. Once I’ve submitted your email, a member of Bloc’s team will contact you to get you started.

When I started learning HTML, I ran into this annoying problem where none of the tutorials I watched agreed on what the essential, basic, bare-bones code is for an HTML document. Some would include this <meta> tag with info I’d never seen before, and others would say you absolutely needed a <main> section or <header> and <footer> tags to separate content. Even when these tutorials did agree, they didn’t always explain why I needed a bit of code.

Now that I’ve spent a few months in HTML land, I’ve discovered what the essential building blocks for an HTML document are. I’m referring to what some people might call a boilerplate or skeleton code, but these terms all mean the same thing. Basically, what is the bare minimum code that needs to be in an HTML file for it to work properly?

tl;dr

If you really don’t care about the purpose of the tags, feel free to copy this code right here and you’ll be all set.

<!DOCTYPE>

This tag tells the browser which version of HTML you are using. If you look at code using older versions of HTML (HTML 4.01, for instance), you would see something like this:

Unless you are working on outdated code, you are probably using the latest version (HTML5). In this case, you’ll use this tag: <!DOCTYPE html>. Place it at the very top of your HTML document above everything else.

<html>

The <html> tags are basically just the “containers” for your HTML code. They tell your browser: “Hey, all the stuff in here is HTML.” It’s as simple as that. The most important thing to remember: like most tags in an HTML file, you need to use an opening <html> and closing </html> tag. Place these just below your <!DOCTYPE> tag.

<head>

This is where you essentially build the setup for your website. Within the <head> tags, you will include links to your stylesheets (i.e. your CSS), links to your JavaScript, a title for your website, and metadata. These are all discussed below. Use an opening <head> and closing </head> tag. Place these inside of your <html> tags.

<meta>

This is where all your metadata lives. Metadata is a fancy technical term for “data that describes other data.” Think of it as the settings for your HTML. The most common metadata attribute is charset which describes your file’s character encoding or how a browser reads your files. The vast majority of web browsers know how to read character set utf-8 making it the go-to charset. Long story short, use this tag: <meta charset=’UTF-8’>. Put it inside your <head> tags. Note: You DO NOT need to have a closing tag for <meta>. This means it is a self-closing tag.

<title>

This is maybe the easiest tag to remember. What you put within the <title> tags is what gets displayed in your browser tabs. If I give my website a title of “Doggos R Cute”, this is what it will look like:

Or I could do something like:

Use an opening <title> and closing </title> tag. Put these tags inside the <head> tags.

<body>

This is where all the action happens. The bulk of your HTML code will live within the <body> tags. You can add things like images, paragraphs, headings, sections, videos, music files, and lots of other cool stuff. Use an opening <body> and closing </body> tag. Put these inside of your <html> tags, but outside of your <head> tags. The <head> and <body> should be like two separate sections within your <html> tags.

Linking to CSS and JavaScript

Most people agree that the above code is all that is necessary for a website to function. This is technically correct, but the HTML skeleton code above won’t be pretty or functional without some CSS and JavaScript added to it. Since 99.9% of the websites you visit will have this extra code, we should consider the tags that link to this code as necessary too.

<link>

The <link> tag is how you attach your CSS to your HTML file. Most projects have several files that are created based on the language or the functionality of the code within them. Although you can put CSS directly in your HTML file, chances are good this is not a viable solution for most projects. Instead, you’ll create a separate CSS file that is linked to your HTML file. There are three essential pieces in a <link> tag:

rel dictates the relationship between your HTML file and the file you are linking to. In the case of CSS, use rel=’stylesheet’

type is exactly what it sounds like. It tells the browser the type of file you are linking to. For CSS, use type=’text/css’

href is the location of the file you are linking. Knowing how to link a file requires a bit of knowledge about paths, but a simple way to access a linked file when you are beginning is to make sure all your files are in the same folder. When this is the case, use href=’NameOfCSSFile.css’. For more in depth info on document paths, check out this article.

With all that added in, the full tag will look like this:

<link rel=’stylesheet’ type=’text/css’ href=’MyCSSFile.css’>

Place this tag within the <head> tags. Note: <link> is a self-closing tag meaning you DO NOT need to have a closing tag.

<script>

The <script> tags are used to link your HTML file to your JavaScript. Like CSS, you can technically put your script directly within these tags in your HTML file, but it is best — especially for larger projects — to have your JavaScript in a separate file and use the <script> tags to link to it. There are two necessary pieces in a <script> tag:

type is just like the type attribute used in <link>. For JavaScript, use type=’text/JavaScript’

src is the <script> equivalent of href. This is where you specify your JavaScript file’s location. Use src=’SomeJavaScriptFile.js’.

The full tag will look like this:

<script type=’text/JavaScript’ src=’MyJavaScript.js’></script>

Want $500 off your Bloc tuition?

If you’re serious about learning to code, consider signing up for a coding bootcamp like Bloc. If you send me a message on LinkedIn with your full name and email address, I can refer you. I’ll receive a cash bonus and you get $500 off your tuition cost. No strings attached. Once I’ve submitted your email, a member of Bloc’s team will contact you to get you started.

Like what you read?

Give it some ❤ and follow me! You can also lookout for similar articles in the Layman’s Coding series where I describe coding concepts with very little jargon and lots of pictures. Didn’t like it? It’s cool. We can still be friends.

Over the past week, I’ve spent about 35+ hours coding along with beginner React tutorials. With this practice under my belt, I can safely say I love React. As blasphemous as it sounds to some developers, I am a huge fan of JSX syntax. I love how everything is neatly organized into “pure” chunks of code, even if it essentially means blending HTML with JS. Doing so keeps all the bits of your site nicely packaged (in blocks of code called components).

This is one of the features that makes React great, but it’s not the only one. First off, it’s built on a unidirectional workflow approach. I know, it sounds crazy technical, but it basically means data passes through your code in one direction. Simple, right? React’s components pass data to other components in a single, hierarchical direction. That makes finding errors in your code much easier.

React also makes use of something called the virtual DOM. With non-React, code the entire DOM renders every time a change happens. This results in a lot of unnecessary DOM updating that can inhibit performance. To avoid this, React takes a lightweight snapshot of the DOM and stores this information in its “virtual DOM”. The virtual DOM works like so:

1. When your site changes (like if someone clicks a button to load new search results), React re-renders the virtual DOM.

2. It compares the differences between this newly re-rendered virtual DOM and the previous virtual DOM.

3. It updates the actual DOM accordingly.

The great part is that it only updates the DOM nodes that have changed. This is one reason why React is quick, efficient, and preferred by many developers.

I could speak about the benefits of React all day, but I’m biased. As part of Bloc’s Web Developer Track, every student learns the React library after mastering CSS, HTML, and JS fundamentals. It’s a logical next step for front-end development and provides tons of useful features, but that doesn’t make it the only option out there, and Bloc knows it. One of the first questions the program encourages you to ask yourself is: “why use React instead of Angular or another JS framework?” My wise and experienced mentor, Mark Carpenter, summed it up this way:

React is all about front-end and creating apps that load in the browser. It has options for building with iOS and Android (see React Native), but isn’t used for mobile development as often as for front-end web work. Angular, on the other hand, is full-stack: you get front-end and back-end development capabilities. That said, become good at either one of these and you’ll get a good job.

This is by no means a final or complete analysis between these tools, and there are many more to choose from. But, alas, you probably came here expecting a synopsis on React given the name of this article, so let’s bring it back ‘round to that. Here are three invaluable lessons I’ve learned while learning React:

1. Not all teachers are created equal. This may seem ridiculously obvious, but it wasn’t something I considered when I started my React journey. Just because a title includes the word “beginner” doesn’t mean it is for beginner developers. I found the tutorial provided by React, for instance, to be both beautifully comprehensive and a little above my abilities as someone who started coding less than a month ago. That may not be the case for everyone, but it’s important to not give up learning React because the tutorial isn’t right for you.

2. If you don’t know JS fundamentals, don’t learn React…yet. React is a JavaScript library meaning it requires the use of JavaScript syntax. Even though you will (very likely) use JSX to write out your code, the logic is still governed by JavaScript that gets “injected” into JSX. If you begin learning React without a basic understanding of functions, loops, and if statements, you’ll want to brush up on these first. Having said that, you won’t need to master JS to be successful in React. I’m finding there are plenty of built-in JS methods I haven’t come across yet, and even some concepts I was a little fuzzy on (the idea of ‘this’ for instance). But, I’ve been able to learn these while I go and understand how they’re integrated in the React ecosystem.

3. There’s no single best way to write anything in code. Before I began learning React, and even when I was still in the CSS/HTML stages of my education, I thought there was one true and proper way of writing code. I convinced myself that even if I got something to work, it wouldn’t matter because the code I wrote was probably sloppy or wrong. But, that’s just not the case, and I see it now with React more than I did when learning CSS and HTML. There are a variety of ways to write nearly any code. There’s also an awful lot of opinions on which ways are ‘best’ or most clever, but these viewpoints are 99% subjective. Keep in mind, there are best practices for each language, but I’ve found even these are sometimes disputed. In the end, if it works and passes all the tests, then you’ve written it the way you should have.

As parting words of wisdom, I’d also like to share with you the React tutorials I’ve found most effective:

— This video by Chris, from the YouTube channel DevCoffee. He does a great job of succinctly explaining some of the core concepts of building components in React and shows you exactly how to code them.

— This free course by Tyler McGinnis. He’s an exceptional teacher, and does an excellent job breaking down the fundamental concepts of components, state, props, and lifecycle. He also provides coding examples and challenges you to recreate the examples until you understand what is going on.

— This other free course by Codecademy.com. This is probably my favorite as it shows you exactly what to do, when to do it, and how it works. They explain everything very simply and provide a space for you to code alongside the lesson. There’s also a part two for when you’ve finished learning React fundamentals.

Want $500 off your Bloc tuition?

Send me a message on LinkedIn with your full name and email address. When I refer you, I receive a cash bonus and you get $500 off your tuition cost. No strings attached. Once I’ve submitted your email, a member of Bloc’s team will contact you to get you started.

Like what you read?

Give it some ❤ and follow me! You can also lookout for similar articles in the series as I continue to expand on what I’m learning in the program. Didn’t like it? It’s cool. We can still be friends.

As a new developer, there’s nothing more common or more frustrating than getting stuck. For me, the problem often lies somewhere between not knowing a concept and not understanding how something works. Half the time it’s because I’m asked to use a method or library that I’m unfamiliar with. The other half, I’m confused by the directions or can’t figure out how a piece of code functions. It is during these times that thoughts of worthlessness and frustration invade.

Will I ever be smart enough to be developer? Why is no one else struggling with this? The answer is probably obvious, but I’m too stupid to see it.

I like to refer to these thoughts as belonging to my pesky inner snake oil salesman. She’s constantly trying to prove why I’m a failure, but I don’t buy what she’s selling. Why? For one, her claims aren’t credible. As with any new skill, grit and dedication are the true measures of success in coding, not innate intelligence. Second, even experienced developers struggle from time to time and seek help.

Which brings us to the first and most important step in getting unstuck:

1. Don’t believe the devil on your shoulder. If your first thoughts after failing to solve a challenge are demeaning, ignore them. They aren’t useful, they aren’t accurate, and they only serve to lower your morale. Instead, try to view each roadblock as an opportunity to learn and become a better developer. If my time as a student in Bloc’s Web Developer Track has taught me anything it’s that problem solving is the developer’s most important tool in the shed. So, instead of getting frustrated by a challenge, remember you are improving your ability to resolve a problem.

2. Don’t be afraid to ask for help. This took some time for me to accept. Until I started learning algorithms, I had done quite well finding solutions on my own. When I ran into my first real challenge, I was at first reluctant to ask for help. I was sure my question would have such an obvious answer that I would feel dumb and embarrassed for asking it.

Much to the chagrin of my inner monologue, I followed the advice above. I hopped onto Bloc’s Slack channel to ask for help. The result? A mentor reassured me, answered my question, and restored my confidence. If you aren’t currently in a Bloc program, you can also check out popular programming web forums like Stack Overflow to get help from fellow developers. Short story long: ask for help.

3. Remove yourself from the situation. This has been among the most useful techniques I’ve discovered over the years, and I’ve used it often outside of the coding world. Our brains can only take so much focused effort before they give out and turn to mush. The longer you attempt to solve a challenging problem the more likely you are to actually push yourself further from a resolution.

The best advice I can give to avoid this scenario is to use a time management system. I’m preferential to the Pomodoro technique, where you take frequent breaks (about 5 minutes every 25 minutes of work) during a project to prevent burnout. I’ve also found my best work comes after breaks where I’m relaxing my brain (petting my cat, going for a walk, taking a short nap).

4. If all else fails, Google it. When I’m absolutely, truly and completely stuck, I search to find how other people solved their problem. If you’ve already spent hours looking for an answer, asking for help, and researching new materials and still haven’t found an answer, look up the solution. My most important and crucial word of advice here: DO NOT copy and paste the solution. This will get you nowhere and is akin to cheating.

If you aren’t able to understand what is happening in the code, the solution you find will be useless when you’re asked to explain it in a technical interview. Instead, write it out for yourself and see if you can figure out a better way to solve the problem after you’ve seen what someone else has done. If you still can’t understand the logic after seeing it, get advice from a mentor, fellow student, or another developer. Either way, make sure you understand what is going on.

Want $500 off your Bloc tuition?

Send me a message on LinkedIn with your full name and email address. When I refer you, I receive a cash bonus and you get $500 off your tuition cost. No strings attached. Once I’ve submitted your email, a member of Bloc’s team will contact you to get you started.

Like what you read?

Give it some ❤ and follow me! You can also lookout for similar articles in the series as I continue to expand on what I’m learning in the program. Didn’t like it? It’s cool. We can still be friends.

Before I began Bloc’s Web Developer Track Bootcamp, I was nervous. Really nervous. I doubted whether I could remember so much information about a field I had almost no experience in. I was also at the mercy of my ambitious and reckless confidence to complete the program in under 4 months. Bloc reckons those committing 30–40 hours a week will finish in as little as 4–5 months. I’m looking at 45+ hours each week, not including time spent networking, practicing, and reading about coding.

But don’t let my crazy schedule derail your plans. Bloc gives you several options to complete their programs, so you can take it at your own pace. The standard tuition rate gives you 8 months, but you can also pay monthly if you plan to finish sooner. (Bonus: If you finish in under 8, you’ll get reimbursed for the months you didn’t use! So, obviously this is a big motivator for me to finish early).

No matter how much time you plan to spend in the program, preparation is key. Below are words of wisdom I’ve gained from personal experience and the thoughtful contributions from my mentor:

1. You get what you put in. It’s as simple as that. If you’re really invested in learning to program, read all the extra resources. Practice outside of the program and take on a side project. It seems daunting at first, but it’s important if you want to understand how programming works.
2. Bloc will force you to think like a developer. The most important thing I’ve learned so far: having technical skills alone will not get you a job. A large part of development problem solving, and Bloc forces you to do this from day one by making you find your own answers. Stack Overflow, W3Schools, and Google will become your best friends during the program and even after you finish.
3. Take free classes before you begin your program. There are tons of opportunities out there to learn coding basics for free and there’s no better way to prepare. Check out the following courses. They are all free or incredibly cheap: freeCodeCamp, Codecademy, Udacity, Udemy, WomenWhoCode (you don’t have to be a lady to sign up!).
4. Code everyday if you want to make progress. Even if it’s only for 15 minutes, so you don’t lose momentum.
5. Learn how to learn. If it’s been a while since you were in school, take this free course from Coursera. It’s recommended by Bloc and is useful even for those still in school. I graduated with my B.S. in Psychology this march, and I’m working on my M.S. in Human Computer Interaction. Even with all this practice I was able to find ways to improve my ability to think and learn creatively.
6. You will fail. It is an inevitable and annoying part of learning, but it happens to everyone. My mentor’s advice? Don’t let failure leave a bad taste in your mouth. Every failure is a chance to learn. Every time you make a mistake, you learn how not to do something. It makes you a better problem solver and a better developer.
7. It’s up to you to land your developer job. While Bloc will put in tons of time helping you polish your elevator pitch and resume, it is ultimately up to you to find your own job. They aren’t going to match you with an employer or do the searching for you. That means networking, practicing soft skills, and job hunting are other priorities during your program. That said, their career services team does a great job of providing tons of resources and is committed to helping you succeed. (Bonus: Bloc has implemented a tuition reimbursement guarantee should you fail to find a job after your program).

Want $500 off your Bloc tuition?

Send me a message on LinkedIn with your full name and email address. When I refer you, I receive a cash bonus and you get $500 off your tuition cost. No strings attached. Once I’ve submitted your email, a member of Bloc’s team will contact you to get you started.

Like what you read?

Give it some ❤ and follow me! You can also lookout for similar articles in the series as I continue to expand on what I’m learning in the program. Didn’t like it? It’s cool. We can still be friends.