How does Hack Reactor help you learn programming compared to learning by yourself?

Learning all of this by yourself is incredibly challenging.

1. You need to have a lot of self-discipline and be able to keep yourself accountable for meeting your own goals. Most of us aren’t wired to have this much self-discipline. Just ask anyone who works at a gym about how people fare with their New Year’s resolutions. It makes a huge difference when you’re surrounded by peers who are just as dedicated to learning programming as you (the same way having a gym buddy encourages you to actually hit the gym and do progressively harder workouts).

2. If you’re struggling on something because a particular topic isn’t clear, it’s both difficult and time-consuming trying to look for the answer. At Hack Reactor, you have instructors who can glance at your code and guide you towards the answer. Unlike online forums, you’ll even get to see how they arrive at those answers, so you’ll learn a lot of tips/tricks to troubleshooting code.

3. Hack Reactor has an intense and well-structured curriculum. You won’t find this curriculum on your own. There’s lots of disparate resources you can gather online (Udacity, Codecademy, Khan Academy, etc.), but they don’t necessarily blend well together. For instance, you can take courses on Javascript at one of those sites (and in fact, you’ll have to take some of those online courses as part of the precoursework prior to the first day of Hack Reactor once you’re accepted), but Hack Reactor isn’t just basic Javascript. It encompasses everything you need to know about programming for the web, from JS fundamentals/advanced JS, to git version control, the various databases and ORMs, JS frameworks like AngularJS and Backbone, libraries like jQuery, Underscore and d3.js, and server-side technologies like node.js. You can try to gather videos from those various sites to try to piece together the same kind of curriculum and then watch them back-to-back, but at some point, things may overlap and you’ll waste time going through their lessons and having to skip certain portions because it was already covered by another lesson elsewhere, or you’ll realize you missed something and you’ll have to hunt to fill the gaps (see #2).

4. Because of its immersive nature, you can learn a lot more very quickly. Unlike learning on your own (especially if you’re trying to learn while you’re working a full-time job), you can dedicate yourself to picking things up quickly, rather than taking everything one small piece at a time and constantly getting interrupted because you have other responsibilities to take care of. Sure, you could quit your job and try to study on your own, but you’d have a really hard time trying to accomplish nearly as much as Hack Reactor students accomplish in that same amount of time in order to be able to prove yourself as a software engineer to potential employers.

TLDR: Hack Reactor spares you of the wasted time and headache associated with trying to do this on your own.

What tips do you have to offer about the 2nd interview?

The 2nd interview is primarily for them to gauge culture fit and finding out how you learn. They’ll set you up at one of the computer pairing stations and try to teach you something new and ask you to implement a particular function. The idea is to find out how well you’re able to explain your thought process as you grasp the new information. So possibly the most important thing to do would be to talk aloud about what’s going through your mind so they can help guide you towards the right answer. Not only is this important for how you’ll be learning throughout most of Hack Reactor, but it’s critical during the technical job interviews, so it’s a skill that you have to hone. For instance, if you’re confused by why if (x === 3) resolves to true in the given code block, instead of simply saying “I don’t know,” explain what’s stumping you, like “I thought x would be 1 because it was assigned to 1 on line 10, and it’s not being reassigned anywhere else.” This goes a long way in both the Hack Reactor interview, and all your future job interviews as a programmer.

The second interview is also your chance to ask them any questions you have about the program. As with any job interview, you should come prepared to ask them anything on your mind (e.g., daily schedule, housing concerns, financing concerns, prereqs, recommended equipment/software, etc.).

That’s it for now. I’ll keep updating this as I get more questions. In the meantime, feel free to email me (will at this domain), or leave a comment below!

TLDR: Hack Reactor been an awesome experience and I couldn’t recommend it highly enough.

I graduated from Hack Reactor in early November as one of the 29 students in the 6th cohort, which started in August 2013. As a testament to just how great and effective Hack Reactor is, by the end of the 2nd week after graduation, I already started getting job offers with 6-figure salaries. The statistics on their webpage aren’t kidding around. At the time that I applied, they bragged about the average graduate getting $85k salaries. I was already skeptical of that at the time that I applied (but it was still a lot better than what I earned before). After we’ve graduated, as other students in my cohort got offers, it became apparent that the average salary has been increasing with each cohort and a 6-figure salary was the new norm.

What sets Hack Reactor apart from the other immersive schools out there, like Dev Bootcamp and App Academy? There’s a few things:

1. Most other schools teach students Ruby on Rails (a server-side language), while Hack Reactor focuses on teaching students software engineering principles using JavaScript, a (often client-side) language used by virtually every online presence out there. Because of its ubiquitous nature, there’s a lot more demand for JavaScript engineers on the job market.

2. At 12 weeks long (technically 13 weeks, more on that later), 11 hours a day (I stayed 13), and 6 days a week, you’re investing a lot more time into the program. This means you’re more thoroughly immersed in the curriculum and you get to spend 3.5 weeks on developing awesome projects: one to show off what you can do on your own, and one amazing one to show off what you can accomplish as part of a team. Both of these projects give you the opportunity to demonstrate what you’re capable of doing, once you start applying for jobs.

3. I’d be remiss if I didn’t mention cost. Hack Reactor (at the time of this review) costs $17,780. That’s a hefty chunk of change, but it’s easily the best investment I’ve ever made. The salary difference between my job prior to Hack Reactor and afterwards more than makes up for the cost of tuition. Also, if you wished Hack Reactor did something akin to App Academy, where they garnish 18% of your first year’s salary, consider this: 18% of the average Hack Reactor graduate’s salary (which at the time of this writing is $110k) comes out to $19,800, which is even more expensive!

4. Marcus and Ruan. Marcus Philips used to teach JavaScript and Front-End engineering at Twitter’s #CodeClass and is now Hack Reactor’s primary lecturer during the incredibly intense/brain-warping first several weeks of the curriculum. He has the unrivaled ability to turn any complex concept in JavaScript and explain it in such a way that it sounds incredibly simple, sometimes distilling it down to a single sentence. He does an amazing job of engaging students and won’t move onto the next topic until he’s certain everyone fully understands the current one. Ruan is the ultimate job hunting guru you’ll ever meet. A Hack Reactor alum himself, he isn’t working at Hack Reactor because he couldn’t find a job himself (heck, he was featured in Wired’s article “Hackers Spawn Web Supercomputer on Way to Chess World Record” because of his group’s project on creating a distributed computing system to tackle the n-queens problem; he’d have no problem getting the job he wants). Instead, he works at Hack Reactor because he loves the environment and he knows practically everything there is to know about the best strategies for getting the job you want.

Hack Reactor also does a great job of screening applicants for culture fit. Every student comes into HR because they genuinely want to learn to build applications and tackle new challenges; they’re not just there because they heard that HR graduates make a lot of money. Once you’re in the program, you’re surrounded by people who are just as driven and inspired as you are, and it encourages you to do even better.

After the group projects are done, HR kicks off the job search period by hosting a Hiring Day event where they invite recruiters from various companies (including Salesforce, Yahoo, Pandora, Udacity, Inkling, and Walmart Labs) and students get to talk to each company for 5 minutes, speed-dating style (because if you think about it, job searching is really similar to dating, in the sense that both parties are looking for the best fit and determining if they can make the relationship work). From this day on, HR helps you with all aspects of the job search, from boosting your online profile and resume, to one-on-one practice interview/whiteboarding sessions, reaching out to give you advice on each step of the way. This is probably the most underrated part of Hack Reactor, but it’s crucial to its success, because college career services don’t offer anywhere near this level of personal support after you graduate.

Of course, Hack Reactor isn’t without its flaws. The main issue: class sizes are starting to exceed capacity, and they currently don’t have enough physical space and staff to deliver the full level of support they’re aiming to provide (which includes very limited restroom stalls, which meant waiting in line for a few minutes after lectures). At least, they didn’t when I was there, but I’ve heard plans that they’ve acquired another floor in the same building, with plans to use it in early 2014, and they’re constantly hiring more staff to deal with their growth.

I took a gamble when I decided to attend Hack Reactor, a program that none of my peers had ever heard of, let alone attended. I had quit my stable, full-time job, drained my entire savings account to pay for tuition and living expenses, and moved nearly 200 miles to SF. After months of intense (but rewarding) work, I’m thrilled (and relieved) that it all worked out in the best way possible and proud to say that going to Hack Reactor was the best life decision I’ve ever made.

Git

Possibly one of the best ways of deploying your application is via Git. Once you have Git installed on your server, simply clone your repository from there, run ‘npm install’, and you’re ready to go with a fresh copy of your code. This also gives you the flexibility to checkout a tagged version of your repo and launch that version instead. This means you can easily rollback in case there’s any critical bug in the deployed code (ideally, you’d never get to that point, of course, but it’s nice having that option available, just in case).

Environment Variables

Hopefully you haven’t been committing information about your database connection (such as the username, password, database connection string, etc.) and API keys/secrets in your actual code repositories. If you have, follow the directions in this Github article on removing sensitive information. Environment variables give you the ability to separate these bits of sensitive information from your code. To get started, create a new file (we’ll call it prod.env) like so:

1
2
3
4
5
6
7
8
9
10
11
12
13

# If your db requires authentication, you could include the credentials in this connection string
export COW_DB_HOST=mongodb://localhost/cow
export NODE_ENV=production
export PORT=8080
# These are fake keys/secrets for the sake of showing you the format
export FB_CLIENT_ID=829459018483923
export FB_CLIENT_SECRET=8ds93jdf9e9d0esdf9e03kds0sd939d9
export GOOGLE_CLIENT_KEY=209432958010.apps.googleusercontent.com
export GOOGLE_CLIENT_SECRET=D9Dke9mSie92kX9KeX0wk
export GITHUB_CLIENT_ID=09sdf03d0024dsjjkn3d
export GITHUB_CLIENT_SECRET=0239ds903nd93ix93nwroino3kj435jkn634vg24
export TWITTER_CONSUMER_KEY=0sd9f3js90334xd093nnsi
export TWITTER_CONSUMER_SECRET=09usdf903jd9034ERDS93rs93JSW9ds9d0s0dsSJSeSde

Save this somewhere outside of your repository, like your home directory, so you don’t ever accidentally commit it to a repo. In your .bash_profile/.profile in your home directory, append

source /path/to/prod.env

Type that same command into your terminal to have these environment variables available in your current terminal session. In your server-side js files, simply use process.env.ENVIRONMENT_VARIABLE wherever you want to refer to those values. For instance:

1
2
3
4
5
6
7
8
9

passport.use(new GoogleStrategy({
    clientID: process.env.GOOGLE_CLIENT_ID,
    clientSecret: process.env.GOOGLE_CLIENT_SECRET,
    callbackURL: 'http://cow.moo/auth/google/callback'
  },
  function(...) {
    ...
  }
));

Privileged Ports

Once you actually set up node, and you’re ready to launch a production instance of node on port 80, you might notice an issue. You can’t simply run ‘node server.js’ under a normal user. You might be confused because you’ve been able to run ‘node server.js’ on your development machine under port 3000, 8080, 9000, etc. all this time without having to run it with ‘sudo’. This is actually because ports 0-1023 on UNIX/Linux are considered Privileged Ports and require root/super user privileges.

But wait. You really shouldn’t be running node with root/super user privileges. What happens if someone decides to exploit a security vulnerability in your code (or node itself)? They’d be able to execute malicious code on your server with root privileges! Obviously not a good idea.

What else can you do? Start using iptables. It allows you to reroute traffic from one port to another. In this case, we want to route traffic headed to our server on port 8080 (defined in our $PORT environment variable) to the standard http port 80.

sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports $PORT

If our server also supports SSL, we’ll want to reroute our SSL traffic as well:

sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports $SSLPORT

Once you run these commands, these rules will persist until your server restarts. If you want these rules to persist on start-up, see the Configuration on startup section of Ubuntu’s iptables article.

Forever

If you’re remotely logging into your EC2 instance via SSH to launch node manually, you may have noticed that node quits the moment you exit the terminal. It also prevents you from running any other commands in the same terminal session. you could run

nohup node server.js > node-output.log &

This works, for the most part, until node itself crashes when your application encounters an exception. At that point, you’d have to log back in to restart the node server using the same command.

This is where Forever comes in. Forever is used at Nodejitsu to keep servers running by turning the node process into a daemon, and it works really well for deployments to EC2 too. Setting it up is as simple as:

[sudo] npm install forever
forever start server.js

If you set up your server with Git, pushing to production can be as simple as committing to your main repository, and then running:

git pull origin master
forever restart server.js

More?

This list is meant to be a starting point for people deploying their applications by setting up and configuring their own VMs, rather than using Heroku, Nodejitsu, or Elastic Beanstalk. If you know of some other good practices for deploying Node.js, feel free to share in the comments below!

This is the div that repeats for each text field associated with a choice on the Create a Poll page (excluding styling syntax).

<div class="form-group" data-ng-repeat="choice in choices">
  <label for="choice" ng-show="showChoiceLabel(choice)">Choices</label>
  <button ng-show="showAddChoice(choice)" ng-click="addNewChoice()">Add another choice</button>
  <input type="text" ng-model="choice.name" name="" placeholder="Enter a restaurant name">
</div>

The magic really happens with this ng-repeat attribute on the first line:

data-ng-repeat="choice in choices"

ng-repeat tells Angular that this <div> should be repeated for each of the items in the “choices” object. “choices” is defined in my controller as simply an array of objects:

$scope.choices = [{id: 'choice1'}, {id: 'choice2'}, {id: 'choice3'}];

When you click “Add another choice”, it triggers runs the addNewChoice() function, which is defined as:

$scope.addNewChoice = function() {
  var newItemNo = $scope.choices.length+1;
  $scope.choices.push({'id':'choice'+newItemNo});
};

This will create a new object with a unique id and append it to the $scope.choices object. Because of the magical 2-way binding in Angular, this is as far as you need to go! Once the new object gets appended to the array, Angular will take care of updating the DOM and appending the new text box.

You might be wondering about that Add another choice button. It’s in that div that gets repeated, yet it doesn’t show up next to each text box. ng-show will only display the button if the function being passed into it returns true. The function in ng-show, showAddChoice(), looks like this:

$scope.showAddChoice = function(choice) {
  return choice.id === $scope.choices[$scope.choices.length-1].id;
};

Basically, it’ll only return true when the id matches the id of the last item in the $scope.choices array.

And there you have it. That’s all you need to dynamically add more fields to a form in AngularJS. Got a better implementation of it? Leave a comment below!

Week 1, known as “Hell Week” for the back-to-back lectures and the insanely dense lesson plans, was probably the most I’ve ever learned in a single week in my life. We went through 4 different instantiation styles (Functional, Functional with shared methods, Prototypal, and Pseudoclassical), created linked lists, trees, sets, and hash tables, and discussed orders of complexity along the way, in addition to doing a brief review the roughly 40 hours worth of pre-course curriculum we had to complete prior to attending our first day of class and covering some orientation materials (such as basic policies, schedule, how to request help, etc.). By the end of the first week, the only regret I had was that I didn’t have enough time to reproduce the crazy red-black tree in Javascript that was part of the extra credit section of our data structures lesson. (Still, regretting that, by the way!)

As if THAT wasn’t mind-blowing enough, by week 2, we covered subclassing and algorithms, including tackling the n-queens problem in pure Javascript. It was one heck of a challenge coming up with a solution to it, and my second regret up to that point was that I didn’t have enough time to tackle the extra credit part of the n-queens assignment, which was to solve it using bitwise operators, which would’ve been amazing because it’s a challenging puzzle to solve, and bitwise operators are much, much, MUCH faster at solving these types of problems. I’m definitely going to have to come back and revisit that sometime.

Weeks 3-5 covered frameworks and libraries like jQuery, Backbone, D3, Coffeescript, Socket.io, Node.js, Express, MySQL/MongoDB, Mongoose, and AngularJS. I’m sure I missed a few things in that list too, considering how much we covered. (Oh, how I wish I had enough time to blog about it while I was learning it!)

Week 6 marked the first week dedicated to personal projects, including coming up with an idea, getting the idea vetted, and deciding on our tech stack, and getting our tech stack vetted. Word of advice: think of your project way in advance, so you’re not caught off-guard when the time comes! If you need ideas, I’d suggest thinking of what you wish existed in your every-day life that doesn’t already exist. In my case, I wish I had a need for a tool that could help me and a group of friends decide where to eat (which has been been a challenge in the past), thus how I came up with the solution: NOMinatr. </shameless plug>

Then came “interim week”, which is the week where we’re left on our own to hack away at our projects while most of the instructors go on vacation (thus why it’s not part of the 12 weeks). It also officially marks the halfway point for Hack Reactor, where we go from being part of the “junior” class to being “seniors”.

And now begins the second half of my journey in Hack Reactor as part of the “senior” class. What kind of exciting things are coming around the corner? Who knows?!

Luckily, I had been looking into alternatives ever since I finished the first step of applying for App Academy. Turns out: There’s lots of programming bootcamps out there. Of the ones available, 3 stood out as great contenders based out of San Francisco (which is where I really wanted to move to):

1. App Academy, the first one I applied to
2. Dev Bootcamp has a great website, detailing nearly everything you’d want to know about them.
3. Hack Reactor has a slightly different philosophy compared to the other 2. Rather than focusing on the server-side of  web development (in most cases, Ruby on Rails), they place an emphasis on teaching Javascript, noting that modern web applications are getting increasingly sophisticated and web browsers are also getting better at running Javascript, which allows us to create great client-side applications that do most of the processing, using the server simply as a means of syncing or storing information. Also, it’s the only one of the 3 (as of the time of this writing) that even has reviews on Yelp, not that reviews on Yelp would be the determining factor for me to spend the $17,780 tuition fee on Hack Reactor. Hack Reactor’s philosophy seemed to make a lot of sense to me. Take Gmail, Twitter, and Facebook as examples. When you visit those sites, your web browser essentially downloads and runs a complex Javascript program, which then pulls just the bare minimum information from the server and processes that information to figure out how to display it to you, rather than relying on the server to tell your web browser how to display it. For instance, when you’re on your Gmail inbox, the browser window never refreshes to get new information from the server. Instead, it periodically checks the Gmail server for new email in the background. Once something new comes in, the entire email message gets downloaded, and the Gmail Javascript program in your browser stores it and figures out how to display it to you, and then understands how to immediately show it to you when you click on the email subject from your inbox. Contrast this to the days when each link we clicked on our web-based email inboxes forced our web browser to send a request to the server and refresh the full page.

People often ask me why I chose Hack Reactor as opposed to the other development bootcamps. Here’s a few of the things that factored into my decision:

• Of the 3 programming bootcamps, only App Academy and Hack Reactor had openings for sessions this year. The earliest cohort available through Dev Bootcamp was in February 2014, 8 months away from when I started this whole process. Given my excitement for this kind of a program after several years of thinking to myself  ”Man, I really wish I had more experience with x. That sounds really cool!“ (where x is the name of just about every tool in web development, like git, Node.js, Backbone.js, JavaScript in general, MongoDB, Ruby on Rails, etc.), I couldn’t stand the idea of waiting 8 months just for the chance of getting into a program like Dev Bootcamp.
• Hack Reactor is expensive. I’m not going to lie. $17,780 is not something to scoff at. That’s not including the cost of food (besides the continental breakfast they provide), living/commuting in SF, and all other normal living expenses, during a period when I wouldn’t have any income. In order to attend any of these bootcamps, I had to quit the job I had been working for nearly 3.5 years. With Hack Reactor’s schedule of 9am-8pm, Mondays-Saturdays for 12 weeks, there’s no way I’d find time to work a part-time job. In fact, Hack Reactor specifically tells students they shouldn’t have any other commitments during those 12 weeks due to the intensity of the program. I thought Dev Bootcamp’s $12,200 was high enough, but Hack Reactor is another story altogether. Even after taking into account that Hack Reactor provides more hours, it still comes out to being more expensive. I even did the math on it: Dev Bootcamp: 8 hours per day * 5 days a week * 9 weeks = 360 hours / $12,200 = $0.0295 per hour Hack Reactor: 11 hours per day * 6 days a week * 12 weeks = 792 hours / $17,780 = $0.0445 per hour Dev Bootcamp: $12,200 / (8 hours per day * 5 days a week * 9 weeks = 360 hours) = $33.89 per hour Hack Reactor: $17,780 / (11 hours per day * 6 days a week * 12 weeks = 792 hours) = $22.45 per hour
• In other words, Hack Reactor costs 50% more than Dev Bootcamp. (App Academy is slightly more expensive than Dev Bootcamp, if you calculate 15% of the average salary an App Academy graduate makes ($89,000 * 15% = $13,350). Either way, Hack Reactor is more expensive. Edit: Cofounder/CEO Tony from Hack Reactor pointed out the mistake I made with calculating the cost per hour; that’s what happens when I try doing math really late at night after my first (incredibly intense) week at Hack Reactor when I first composed this entry (but more on that first week in a separate entry). On a per-hour basis, Hack Reactor turns out to actually be cheaper! However, most prospective students tend to do the calculation on a per-week basis, which is where Hack Reactor would come out as more expensive: Dev Bootcamp: $12,200 / 9 weeks = $1,355.56 per week Hack Reactor: $17,780 / 12 weeks = $1,481.67 per week (Sidenote: Hack Reactor published a blog post outlining reasons why their program is more expensive. This blog post didn’t factor into my decision to choose Hack Reactor, since it wasn’t published until after I already got accepted and paid the deposit + tuition fees).
• The application process for Hack Reactor was incredibly better than App Academy. With App Academy, the focus was strictly on how well you knew Ruby (after they gave you a few resources to use). Their “interviews” were essentially closely proctored Ruby tests that took place over Skype. It just felt very impersonal. The interviewers never really asked any questions to get to know me to gauge my personality. Hack Reactor, on the other hand, was a breathe of fresh air in comparison. That alone made it worth the premium over App Academy. After submitting my application to Hack Reactor, they invited me to come in for an interview (in-person), or use Skype if I couldn’t make it. That alone was a nice surprise, considering App Academy never even invited me to tour their facilities despite how far I got in their interview process. During the interview with Hack Reactor, I got to meet a few students (even in the elevator ride to Hack Reactor on the 8th floor), so I had a chance to ask random students how they liked the program. All the students I met were enthusiastic about being at Hack Reactor. So I figured they either did a good job of screening out those who weren’t as passionate about the program during the admissions process, or they were just really good at hiding those students from me during my visit.

The first interview gave them a chance to get to know me, and very importantly, gave me a chance to get to know them and their facilities. After having me tackle an easy Javascript problem, they gave me a small take-home Javascript project to work on. Once I submitted it, they scheduled me for a technical interview, where they gauged my ability to learn new concepts (as opposed to just testing me on something they referenced in an email).

A few days after that second interview, I got my acceptance email (at which point I did several happy dances in the privacy of my room, and continued doing so for the next few days). Now that I was accepted, I knew I couldn’t contain my excitement for moving on to the next chapter of my life and starting to learn all the things I had been wanting to learn for the past several years. There’s no way I could contain myself and wait for a Dev Bootcamp session that’d start 8 months from that day. I had already fallen in love with Hack Reactor and I couldn’t think of what Dev Bootcamp could offer that made it worth waiting 8 months for (and besides, Dev Bootcamp makes you send in a video; I can’t say I’m a fan of that idea). And so, on July 9, I turned in my resignation letter at my job, paid my deposit, sent my tuition check in the mail, and prepared for my new and exciting beginning at Hack Reactor.

During my initial search of programming bootcamps, I stumbled upon a few blogs out there of people describing their experiences with various bootcamps and found them to be both interesting and informative, since they helped me confirm that these programming bootcamps were worth quitting my job and emptying out my life’s savings to pursue. I started this blog with the intent of letting others know about my experience with programming bootcamps (primarily Hack Reactor), with the hopes that someone else reading this will find it just as useful as the other blogs I found useful in my initial search. Stay tuned for the next entry, when I reflect on my first week of Hack Reactor (spoiler alert: It’s awesome).