Just completed my second week at Hack Reactor. The first hour of Monday was spent on completing a self assessment used to measure how well we learned the material covered in the first week. We were given 5 exercises that we had to complete in a 30 minutes.
The 5 exercises covered the major topics that were covered in our first week at Hack Reactor. Here are the exercises we had to complete:
- Write a reduce function
- Write two new methods that would extend the Array prototype
- Describe differences between a stack and an array
- Write a stack function
- Write a function to handle collision in a hash table
Beginning at week 2, every Monday will start with a self-assessment. These self-assessments are designed to measure whether or not any student is potentially struggling with understanding the material covered in the previous week.
The pace at Hack Reactor is very intense. If a student starts to fall behind it is virtually impossible for them to catch up. The staff at Hack Reactor knows this which is why they provides these weekly self-assessments.
There are technical mentors that will pull aside a student and work with them one-on-one as soon as they know a student is struggling. This attention of excellence is one of the reasons that Hack Reactor is considered the best programming boot camp in the world.
In week 1 we learned about functional and functional shared instantiation methods as well as prototypal and pseudo-classical instantiation methods.
We started week 2 learning about subclassing. Subclassing allows you to create a hierarchy of classes through class definitions.
In a class definition, you can specify that the new class is a subclass of an already existing class. The subclass inherits all the properties of the superclass and additionally can add new properties or modify the inherited ones.
The first sprint of the week implemented subclasses. We were expected to create a superclass and then create up to four subclassess that inherited from it. Each subclass would have its own unique feature set.
On Tuesday of Week 2 we had our introduction to “Toy Problems.” Toy Problems are a daily event that will continue until graduation.
Toy Problems mimic what you might expect to face as part of the interview process for a job after graduation. Every company will present a prospective applicant with an exercise and then evaluate how they handle the solution of their exercise.
The toy problems – like job interview exercises – will measure you ability to solve a problem in a short amount of time. Every morning we are given our toy problem and we are expected to complete them in less than an hour.
Once we have finished our toy problem we submit them to Hack Reactor on Git. Hack Reactor has an automated system that will review our solution and send back an immediate grade to you.
The grade will tell us how we performed on that toy problem. If your solution failed any of the tests you will be given feedback on what failed.
The toy problems test your ability to think and solve an algorithm as well as how complete your solution to the problem is.
The second sprint of the week was an introduction to a very challenging algorithm called N-Queens. The gist of the algorithm is to determine how many queens can be placed on a chess board that is N squares wide so that none of the queens can attack another queen.
This was the most challenging sprint that we have had to date in terms of the complexity required to reach a solution.
To assist in solving the problem we worked through several smaller steps that built upon each other until we were able to solve the problem.
The first step is to write functions that would determine if there is a conflict with another piece on the same row where you want to place a queen. Then we would test if there was a conflict in the same column. Then we would test if there was a conflict on the diagonal.
The third sprint of week 2 was our first introduction to using a 3rd party API. In any type of development work that you do, you will be expected to implement some type of 3rd party API.
This sprint required us to basically read through the D3 documentation and then start testing things out to learn how it works.
The first day of this two day sprint was basically spent combing through the D3 documentation and trying to implement it.
The goal of this sprint is to create a game where a player is in an arena and attempts to avoid asteroids that are flying around on the screen. Every time the player avoids the asteroids their score increases. The game ends as soon as the player comes into contact with an asteroid.
Saturday evening from 6:30PM to 8:00PM is a social hackathon. During this optional time period we are presented with a challenge and we are expected to program our solution and then present them 90 minutes later.
The goal is to teach us to quickly develop a MVP (minimally viable product) in the quickest time possible. The goal is not to have the best looking or most flashiest solution. The goal is to have a solution that works in a very short time frame.
These social hackathons are a great way to measure your ability to perform under a tight deadline and to measure whether or not you can design a working solution.