It’s hard to believe that Week 2 at Hack Reactor is already finished! I constantly go between feelings like I’ve been here for several months or several days, but definitely not 2 weeks. Keeping track of what day of the week it is has also proven to be a challenge. For example, yesterday I got to my local gym at 6 am only to realize that it doesn’t open on Saturdays until 8 am!

On a different note, the material at Hack Reactor has gotten progressively more interesting. This week we built a Dance Party game in jQuery using various CSS animations, explored how to design an algorithm to the classic N-Queens problem, and got introduced to the awesome data visualization libary D3.js.

What is D3.js?

D3 is a popular JavaScript library that stands for Data Driven Documents that allows manipulating DOM tree nodes (elements on a web page) using data. Prior to technology like D3, most data was visualized using bar charts, line graphs and pie charts. These tools date back to the late seventeenth hundreds. D3’s biggest appeal is that it allows to visualize large and complex data sets in the browser. With D3, you can create interactive charts and graphs that display dynamic data in ways that haven’t been done before.

D3.js Sprint

Having come from a data analytics background, the D3 sprint has been my favorite so far. We took some creative liberties and built an Interstellar themed video game where you have to move around Yoda’s head to avoid collisions with the falling asteroid. It was really amazing to see how easily we could bind data to the DOM nodes using D3.

Below is the high level picture of our code:

Step 1. Create the Board

Using D3 methods, append the SVG (Scalable Vector Graphics) element to the tag and set the height and width parameters of the video game frame.

Step 2. Create the Enemy Objects

D3’s method .selectAll() allows us to grab all svg ‘circle’ elements on the page and apply certain properties to them. The .data() operator takes in DOM nodes returned by .selectAll() and binds the data passed in. We then set the class, radius and the x and y coordinates of each enemy node with the data supplied from the createEnemies function. And lastly, we set the image attribute of our enemy circles to a picture of an asteroid.

Step 3. Create the Player

In the step above, .enter() took the selection returned by data() and created new DOM nodes for each missing item in the data array. Since our game only has one player, we don’t need to use the .enter() operator and instead we just set the player’s x and y coordinates.

Step 4. Making the enemies collide

To put it all together, this step grabs all the existing enemy asteroids and binds the new x and y coordinates generated by the createEnemeies function using the data(). Now every time we call the move() function, our enemy objects will move around on the screen.

Final Thoughts

This sprint made it apparent that D3’s ‘secrete sauce’ was the ability to loosely bind data to DOM elements. Without having to explicitly specify the quantity or type of data, D3.js is able to elegantly attach dynamic data with DOM elements to create amazing visual effects.

For those of you learning how to code, I put together a curated list of resources that I used to learn how to code which can be found at breakingintostartups.com

Sign up for the Breaking Into Startups newsletter here for further guidance.

If you enjoyed this post, please share it with your friends! ❤ Also, I would love to hear about your stories in the comments below.

Introduction

After much anticipation, I just completed Week 1 of Hack Reactor. The last 6 days have been filled with lots of introductions, lectures, pair programming, and sprints. Admittedly, coming into this experience I had my doubts about how much I could learn in 3 months; however, after just six days of being surrounded by the incredible instructors and teaching staff, I can safely say that the amount I learned in the last 6 days would have amounted to several months of learning on my own.

One thing that drew me to Hack Reactor was its emphasis on software engineering fundamentals. Although the majority of coding at HR is done in JavaScript, the language itself is merely a gateway to engage with deeper computer science concepts. To no surprise, the overarching theme of Week 1 has been learning about the fundamental concept of software engineering - the analysis of algorithms and data structures.

What is an Algorithm?

Definition: “Algorithm – is a set of steps to accomplish a task”

An algorithm can be thought of as a recipe or a step-by-step set of operations for solving a problem. You may have an algorithm for making a sandwich, driving from home to work in the morning, or using your phone to text a friend. In computer science, an algorithm is a set of steps that a computer program needs to follow to accomplish a task. Building efficient algorithms and knowing when to apply them, is what makes a superb software engineer.

Algorithm Design and Analysis

There are several ways to measure the efficiency of an algorithm - the main two being Time and Space (in memory). Time Complexity refers to the number of steps necessary to execute a program in relation to its input size. Whereas, Storage Complexity refers to the amount of memory space a program needs in order to accomplish its task. The effects of time and memory space may seem negligent when working with small input sizes, however, when operating over millions of data points, a poorly constructed algorithm can take hours or even days to complete.

This is best explained with an example. Say your task is to find your friend, Tom Kennedy’s phone number in a phone book consisting of 10,000 names. One way to solve this problem would be to go through each name, one by one, until you find the name you were looking for. In the worst-case scenario, it would take 10,000 lookup operations on 10,000 names. This is commonly referred to as linear search, meaning that for an input size of n, you have to perform n operations. Since all the names are in alphabatical order, another way to approach this problem is to use binary search. Instead of going through every name in the phone book, you can randomly open it at the “half-way” point (refer to Figure 1.1 above). Examine a random name on the page, for practical purposes let’s assume it was the letter ‘M’ and disregard the half that doesn’t contain ‘T’. Just in this one step, we were able save 5,000 operations. Next, we want to divide the remaining half of the phone book in half again (assume it’s letter ‘S’ now) and repeat the previous step of disregarding the half that doesn’t contain ‘T’. This saves us another 2,500 operations! Next we are going to divide the remaining half again and open to the page containing letter W, then U, and finally T. This took us all of 5 operations! Now if you repeat this step a several more times, you will be able to get to your friends name Tom Kennedy, but the bigger point here is that we were able to find our friend by checking approximately 10 names versus 10,000!

Big-O Notation

There are two important ideas that help us determine the efficiency of an algorithm. First, run time measures the amount of time our algorithm takes to complete the entire task, which is a function of the input size. The second thing we need to know is the rate of growth of the running time or how fast our function grows with the increase in input size. In the example above, if the number of names in the phone book increases, the time it takes to find our friend’s name will increase as well. If we contrast linear search (blue line) with binary search (red line), we would see that as input size increases, linear search would need to perform n operations of n input size where as binary search would only perform log n operations for n size!

To demonstrate that the rate of growth of running time is by far the best indicator of function’s efficiency, let’s take a look at an algorithm f(n) = 6n^2 + 100n + 300 with input size n. As the input size grows, n^2 will come to dominate the function’s growth as n moves toward infinity. By dropping coefficients and constant terms, we are able to estimate the function’s complexity in the asymptotic sense, by focusing on the function’s upper bound or the worst-case run-time, which is represented by the big-O notation.

The big-O notation simply approximates the asymptotic upper bounds of the function’s growth rate, by suppressing constant factors and low order terms. The letter O is used because it refers to the growth rate of a function, which is also referred to as order of the function. For our binary search example above, we can say that the running time is “O(lg n)”, meaning that the binary search run time grows at most f(lg n).

Check out Part II to learn about Determining Complexity of Algorithms

For those of you learning how to code, I put together a curated list of resources that I used to learn how to code which can be found at breakingintostartups.com

Sign up for the Breaking Into Startups newsletter here for further guidance.

If you enjoyed this post, please share it with your friends! ❤ Also, I would love to hear about your stories in the comments below.

There are several types of complexities, which can be represented using the big-O notation, namely constant, linear, logarithmic, quadratic and exponential time.

Constant Time

Constant time implies that the number of operations the program needs to perform to accomplish a task is independent of the input size. Constant time operations are ‘order of 1’ or O(1). Examples of constant time are looking up a value in an array, finding the size of an array, or appending values to an array. As the input size grows larger, the time it takes to perform these operations remains constant.

Linear Time

Linear time indicates that run time of the function is directly proportional to the input size. In our phone book example in Part 1, if we examine every single name in the phone book until we found the one we were looking for, it would be considered as linear time complexity or ‘order of n’ or O(n) because it would require to perform n look ups on an input size of n.

Logarithmic Time

Logarithmic time implies that the function’s run time is proportional to the logarithm of the input size. Its usually represented as O(log n) or ‘order of log n’. Binary search, in the phone book example in Part 1, runs in logarithmic time because with every operation, it discards half of the inputs.

Quadratic Time

Quadratic time suggests that the function’s run time is proportional to the square of the input size. Quadratic time is typically represented as ‘order N squared’ or O(n^2). An example of quadratic time would be comparing 2 integer lists against each other, nested “for” loops, bubble sort, selection sort and many others.

Other Time Complexities

There are other types of complexities such as factorial and exponential time. These algorithms are usually used for very small input sizes because it takes a very long time to execute. An example of an exponential time algorithm would be guessing a password.

Complexity Analysis and Data Structures

We can demonstrate how time complexity analysis can be applied to data structures by analyzing the run time of various methods of the data structures below.

Arrays

Constant time or O(1) Array methods:

• Ex. Updating, indexOf(), Append(), .length()
• The time to perform these functions is independent of the array (input) size

Linear time or O(n) methods:

• Ex. find(), insert(), remove()
• The time it takes to perform a function is proportional to the size of the array because each of the above functions requires iterating over the entire array. This may not be obvious at first, but in the case of insert or remove, we need to iterate over the remainder of the array in order to move the elements one index over to the right or to the left, respectively

Linked List

Constant time or O(1) methods:

• ex. Appending to the Linked List, Inserting, Removing*
• Appending, Inserting and Removing* can be done in one step

*Removing a node can be done in constant time in a Linked List if a bidirectional pointer is added to link back to the previous node. This would improve time complexity, however have negative implication on space complexity since it would require to store a pointer back to the node that pointed to it in the first place

Linear time or O(n) methods:

• Ex. Find, Length
• Finding the node or getting the length of the Linked List requires to iterate over every node from the beginning of the list until the end

For those of you learning how to code, I put together a curated list of resources that I used to learn how to code which can be found at breakingintostartups.com

Sign up for the Breaking Into Startups newsletter here for further guidance.

If you enjoyed this post, please share it with your friends! ❤ Also, I would love to hear about your stories in the comments below.

Update (12/6/2016) - After 2 years of working in software engineering, I decided to start a podcast called Breaking Into Startups where we interview top bootcamp founder and alumni who broke into software engineering. Check it out http://breakingintostartups.com!

Today is a very SPECIAL day. After months of anticipation, my twin brother Timur, left Atlanta to move to California to attend App Academy, one of the top coding bootcamps in San Francisco. Over last year, we have spent most of our free time learning how to code in two different programming languages, Ruby and JavaScript. I plan to cover the topic of various languages in a future post, but for now I want to keep the focus limited to how we came to a decision to attend App Academy and Hack Reactor.

What is a Coding Bootcamp?

Before I dive into the similarities and differences between various bootcamps, I want to explain what a coding bootcamp is. In recent years, there has been a growing demand for web and mobile developers due to the growing number of smart phone users who are consuming an astonishing amount of content right from their devices. Because every year or so, there are significant updates to the operating systems, all the apps and websites need to be rebuilt from scratch (just think about the number of times you had to update your web browser or your mobile apps in the last year). In addition, if you take a multi-platform service like Netflix, which needs to have a separate team to upkeep their website, iPhone, iPad and an Android app, you begin to see the magnitude of the problem.

Since there is a lot of demand for people with programming skills and an increasing lack of supply, this is where coding bootcamps come in. During 9-12 week programs, the students are fully immersed in the software development process, learning an array of relevant methodologies and tools to build modern applications. Compared to a traditional CS degree where the emphasis is on computer science fundamentals, the bootcamp students gain exposure to the latest, most impactful technologies that are currently in use.

App Academy

Established in 2012, App Academy is similar to Hack Reactor in that in a short period of time, it’s students pick up essential programming skills to become proficient software engineers. They have two campuses in San Francisco and New York and claim a 98% success rate at placing candidates at start-ups with average salary of $100,000.

The one feature that differentiates App Academy from other bootcamps is its “No Job, No Pay” deal. In short, you don’t have to pay for the bootcamp upfront. You only pay a percentage of your first year salary (currently 18%), AFTER they help you find a job. The basic premise here is that App Academy takes a gamble on you and has a great incentive to make you the most marketable job candidate in 9 weeks. This sounds amazing, however, the application process is grueling. My brother had several rounds of phone screens with behavioral and technical components and a final Skype interview with the founder of App Academy. (For full disclosure, I’ve never applied to App Academy and am only speaking from comparing my brother’s experience applying to App Academy with my interview process with Hack Reactor. If you are interested to learn more about my brother’s application process check out his blog here.) That’s not to say that Hack Reactor isn’t challenging to get into but in my personal opinion, App Academy cares a LOT about the candidate’s background and the ability to pick up the required skillset in 9 short weeks. I think what set my brother apart from other candidates was that he was already doing project management and working as a SCRUM master in iOS development for AutoTrader.com, so his learning curve would have been less steep than someone coming form an unrelated field.

Another notable difference between App Academy and Hack Reactor is the programming language. Although both schools teach full-stack development, App Academy spends more time teaching Ruby, which is more of a back-end language, whereas, Hack Reactor is focused on JavaScript, which is extensively used on both the front and back end. (If you don’t know what full-stack means or what the difference between Front-End and Back-End is don’t worry, I will cover it in my next post). The good news is that there is insatiable demand for programmers of both languages, so if you don’t have a strong preference yet, my advice is to just pick one and stick with it.

Why I chose Hack Reactor

To be completely honest, I didn’t learn about Hack Reactor and its emphasis on JavaScript until several weeks into my Intro to Ruby course on Codecademy.com. What jumped at me right away was the astonishing statistics that Hack Reactor publishes on their website like the 99% graduate hiring rate, $105,000 average starting salary and world class instructors among others. I was skeptical at first so I began to do my own research to dig up reviews on Quora, Yelp, Reddit and students’ personal blogs. To my amazement, there were 69 five-star reviews out 71 total on Yelp and countless Quora posts praising Hack Reactor instructors and teaching methodology. This was impressive but I still had my doubts. After spending an hour going through LinkedIn profiles of Hack Reactor graduates, I was amazed to find that they were all working for the top Silicon Valley firms like SalesForce, Google, Twitter, Groupon, Asana, Yammer and AutoDesk, to name a few.

After reading about the Hack Reactor curriculum and the different stages of the program, it became apparent how it's able to produce such unparalleled results. First, most coding bootcamps last 5 days a week for 9 weeks, whereas, students at Hack Reactor are there for 12 weeks, 6 days a week, 11 hours a day. That’s more than 30% more instruction time! Secondly, the way the course is broken up is the first 6 weeks are lecture based and in the last 6 weeks, students get to implement what they learned by working with actual start-ups. This work experience not only helps students to build a portfolio of projects that they can discuss in their job interviews, but also gives them an opportunity to figure out what they want to do after graduation by getting exposure to the start-up environment.

Lastly, JavaScript has surpassed other programming languages as the most popular language for web development because of the flexibility and ease with which it takes to create beautifully interactive websites. Today, there are tons of new frameworks and tools build on top of JavaScript like Node.js, that give website creators full control over the creation process. Since most website and web apps are being build using JavaScript, this means that going forward this skillset is only going to become more valuable.

(If you are interested in learning more about my application process to Hack Reactor, you can find it here.)

Where is Part II?

You can find Part II here documenting how we went through our coding bootcamps and navigated the job search.

For those of you learning how to code, I put together a curated list of resources that I used to learn how to code which can be found at breakingintostartups.com

Sign up for the Breaking Into Startups newsletter here for further guidance.

If you enjoyed this post, please share it with your friends! ❤ Also, I would love to hear about your stories in the comments below.

Update (12/6/2016) - After 2 years of working in software engineering, I decided to start a podcast called Breaking Into Startups where we interview top bootcamp founder and alumni who broke into software engineering. Check it out http://breakingintostartups.com!

My Hack Reactor Interview Process

After weeks of researching coding bootcamps, I was convinced that I wanted to attend Hack Reactor except for a “minor” problem – the admission challenge. From everything I gathered to that point, the technical interview would consist of a 45-minute session over Skype where I would be asked to solve a series of coding challenges using my knowledge of JavaScript. For those less familiar with programming, an example of a coding problem would be something like building a function that checks to see if a number is prime. For starters, you have to know enough basic math to know what constitutes a prime number. Secondly, you have to quickly come up with the rules to determine if the number is prime. Lastly, you have to apply your knowledge of JavaScript to build these conditions into a function. If this doesn’t sound scary to you yet, remember that you have to do it in a relatively short period of time while somebody is watching your every move! I was terrified, to say the least.

That night I ended up reading as many Hack Reactor student blogs as I could find in search for any insight about the interview process. After reading about a dozen of them, I noticed a reoccurring theme – every applicant thought they absolutely BOMBED it when they took it! This wasn’t particularly reassuring considering a lot of the applicants were coming from some sort of coding background. All of a sudden, getting into Hack Reactor started to seem like a distant reality. The only sort of good news for me was that a lot of the same people who thought they BOMBED it, ended up getting in. Could it be that the interviewers intentionally pushed the boundaries in order to see how much the candidates actually knew? If that was the case, I had to REALLY start studying in hope that the little knowledge I can accumulate before I apply can shine through in my interview.

What you’ll find below are the steps that I took to prep for the technical interview with Hack Reactor. A lot of the study tips I borrowed from other students' blogs (Forrest, Amira Anuar, Austen Talbot). In order to maintain ethicacy, this blog is NOT intended to provide you with the answers to the problems that Hack Reactor asks during its interview. Instead, I’m sharing what I did to prep in order to help you should you decide to apply to Hack Reactor too.

Hack Reactor’s Website

The interview tips on Hack Reactor’s website were a great starting point. The courses on Codecademy and Eloquent JavaScript provided a great introduction to the JavaScript synthax. However, after finishing everything Hack Reactor recommended, I still had a feeling that I was missing the broader picture. I had a general understanding of the main concepts but if you had asked me to explain the difference between a “variable assignment” and a “variable declaration”, I would not have been able to answer. According to Hack Reactor, it should take a “great” applicant between 10-15 hours to prep for the admission challenge. This may be right, but since I was starting from a relatively low base, I knew I needed to get more practice.

Additional Prep

The JavaScript Road Trip Parts 1-3 on CodeSchool do an amazing job reinforcing the crucial JavaScript concepts with many examples and little practice problems. This gave me a more in-depth look into how to work with functions, objects, closures, hoisting and callbacks. Once I completed these three courses, I went on to take the Try jQuery and jQuery: The Return Flight course which were fun little courses that gave me a glimpse into what you can actually build with JavaScript. I then went to JavaScript-is-Sexy and read every article on there. Make sure you really understand the concepts of variable scope, closures, hoisting, and callbacks.

I then returned to Eloquent JavaScript and re-read Chapters 1-6. I would say, the exercises in Chapters 5-6 are a good assessment whether you are ready to take the admission challenge.

Game Time

Once I felt confident in my ability to write JavaScript functions and solve the “Easy” Coderbyte problems, I went to the Hack Reactor website and applied. The interesting part about the their application was that you filled it out using JavaScript. You got to apply your newly learned JavaScript knowledge to maneuver through the application and finally submit it! Right away, it was apparent that a lot of thought went into the application process, which provided me with a strange sense of relief.

I then received an email asking to schedule my technical interview and an optional “take-home” project. I’m not going to go into great detail about the project because I want to preserve the surprise, but I found it rather challenging and intellectually rewarding at the same time. I was asked to create a simple application using Ajax, which I wasn’t totally unfamiliar with because I have already taken the jQuery: The Return Flight on CodeSchool. Nevertheless, you should expect to spend a good amount of time on StackOverflow asking for help.

Finally, about a week later I had my technical interview. Again I’m not going to discuss the contents of the interview, but I will say that it was not what I had expected. My interviewer, John, was extremely nice and even went out of his way to make me feel comfortable. After a little bit of small talk, he asked me a few questions about some JavaScript concepts and then asked to see how I would apply them. Although I was a bit nervous, I answered the first question correctly and with a little bit of help, I was able to solve the rest of the problems too. I have to say that although the questions were definitely challenging and not something I had done before, the additional prep had paid off.

Final Thoughts

The unique interviewing style at Hack Reactor is telling of their overall approach to teaching. From the beginning of the application process until the final interview, I felt that Hack Reactor placed a great deal of emphasis on applying what you learn! To no surprise, it seems that it’s also the quality they look for in candidates – the ability to pick up new concepts quickly and apply them with little help from the instructors. Ultimately, the format of a 12-week crash course isn’t for everybody and that’s what the interview process is for. However, if you can demonstrate you’re eagerness to learn and the ability to be resourceful, you will undoubtedly get in!

For those of you learning how to code, I put together a curated list of resources that I used to learn how to code which can be found at breakingintostartups.com

Sign up for the Breaking Into Startups newsletter here for further guidance.

If you enjoyed this post, please share it with your friends! ❤ Also, I would love to hear about your stories in the comments below.

"Programming? You’re going to leave a 6-figure job to do what?"

This is what my mom told me after I told her my plans to quit my job as an investment banker in order to pursue my dream of working with start-ups. After close to a year of researching the world of start-ups and spending countless weekends and late nights teaching myself how to code, I’m proud to say that I got accepted to Hack Reactor, a 12-week coding bootcamp in San Francisco, CA.

Why Programming?

Since I can remember, I’ve always been curious about websites, and more importantly, e-commerce. During my sophomore year in college, my roommate and I built a successful online art gallery. By optimizing our website for search engines, we were able to rank at the top of Google, which resulted in thousands of dollars in art sales with customers from all over the world. The following semester, I was eager to take the Intro to Computer Science class, hoping that it would ignite my entrepreneurial spark. However, after spending 4 months studying computer science theory from a professor who didn’t seem to know what a text editor was, I came to the realization that this approach to learning computer science just wasn’t for me. Perhaps that’s the reason why there is such high demand for software engineers in America today.

Why I Quit

After college, I went on to joining an investment bank, advising consumer and retail companies on strategic partnerships, mergers and acquisitions. For someone right out of school this was a great opportunity to see the back workings of the business world. However, after 2 years of working long hours, missing friends’ birthdays and spending most of my early twenties in a cubicle, I came to the conclusion that there had to be another way to reach my goal of building my own startup. Then one day I came across a blog post that was going to change my life forever.

Climbing the Wrong Hill

The pivotal moment for me that set me on a new course was when I read Chris Dixon’s blog post – Climbing the Wrong Hill. Chris describes a common phenomena which also happens to be a classic computer science problem – hill climbing. The basic premise is that you are dropped at a random spot on a hilly terrain with the goal of getting to the highest hill (think of it as your life’s goal). Because of limited visibility, you are naturally attracted to climb the tallest hill that you see. However, after a while of climbing what you think is the tallest hill you begin to see an even taller hill. You want to jump over to the bigger mountain however you can’t go straight from where you are…you must first go DOWN in order to go UP. The principle of local maximum keeps most people stuck in their jobs or bad relationships because the pain of giving up all the hard work that got them to that point is greater than the potential pleasure of reaching the ultimate goal.

The thought of going DOWN in order to go UP was terrifying at first. If I decided to quit, I would be giving up all the hard work that I’d put in over the last 6 years, along with a high paying job, for a chance to follow my dreams. What inspired me to act was my parents’ legacy. When I was a kid, they left everything they’d built over the course of forty years behind in Ukraine for the opportunity to immigrate to the United States and follow their dreams. If they could face the fear of starting from scratch in a new country without knowing any English, so could I.

Journey to Hack Reactor

After 6 months of learning how to code, I was ready to take the technical interview at Hack Reactor. I plan to cover my reasons for choosing Hack Reactor and the steps that I took to prepare for my interview in future blog posts, but in summary, what attracted me to Hack Reactor was the rigor of their curriculum and the opportunity to use cutting edge technologies to build production-grade web applications and client projects. The day I received the acceptance letter was the happiest day in my adult life because for the first time in 24 years I knew I was taking control of my life and moving closer to realizing my dreams.

Mission For This Blog:

I hope to document my journey through Hack Reactor and beyond in order to inspire others to take the leap of faith and follow their dreams.

Topics I plan to cover:

• Learning How to Code
• Picking a Programing Language
• Selecting a Coding Bootcamp
• Preparing for Your Technical Interview
• Attending Hack Reactor
• Job Search
• My Personal Projects

Update (12/6/2016) - After 2 years of working in software engineering, I decided to start a podcast called Breaking Into Startups where we interview top bootcamp founder and alumni who broke into software engineering. Check it out http://breakingintostartups.com!

If you enjoyed this post, please share it with your friends! ❤ Also, I would love to hear about your stories in the comments below.