Hack Reactor: Senior Phase

I got off the bus and walked back into my parent’s home in Queens. After setting my bags down and slumping back into my childhood bedroom. I couldn’t help but feel like I had just been hit with a huge setback.

Coronavirus was making headlines everywhere and it became quite clear that I would not be returning to campus anytime soon. I had been looking forward to the senior phase and being a mentor to the juniors in person, and now we would be resorting to building the community via Zoom. At the time, I thought I had made a horrible decision to leave my job and go down this path, given that I had just paid the full price of the boot camp to have the content delivered online.

Our cohort received the news on Friday that we had all passed the Technical Assessment. We were only the third cohort ever in the history of the program to have a 100% pass rate. The news was welcome given the circumstances. It also gave me hope to know that among our cohort, people were still extremely passionate about moving forward and putting their newfound skills to the test in the senior phase.

We had built a strong sense of camaraderie given that we had all just dedicated around 60 hours for six consecutive weeks for the purpose of changing our careers, and yet, we were only halfway done with the program. While I wasn’t sure how the rest of the program would play out online, I knew that my cohortmates were going to feel more motivated to work if we all stayed and saw the program through.

Senior Phase

Front End Capstone (FEC)

On Week 7 Day 1, we were welcomed back to the online campus as seniors. Immediately, the Senior Technical Mentor issued the prompt of the FEC: an e-commerce firm was looking to redesign their product page with React, JavaScript, HTML, and CSS and had an accompanying business requirements document to reference during development. We were given two weeks to submit our final product.

After being assigned to teams, we met for the first time to discuss how to approach the project. Starting with a blank canvas was intimidating, and initially, it’s difficult to judge what the right decisions are. We agreed that setting up an initial file structure and project board on Trello were important first steps and after that, we would divide up the widgets of the application and get to hacking.

I chose to do Related Products, where a main product’s associated items would be displayed as a carousel of cards. The cards themselves would have images, the name of the product, the price, and the rating of the product displayed. Additionally, the option to add the main product as a card to ‘Your Outfit’, which would persist across user sessions, meaning if you visited the site a day later, ‘Your Outfit’ would remain the same.

Unlike the junior phase, the senior phase had far fewer lectures. The schedule was more akin to actual software development work, where there were long blocks of time to code occasionally interspersed with meetings. Instead of focusing on learning new topics for sprints, we were setting up our own tickets and contributing deliverables at the end of each sprint. Any additional learning for implementation typically came from our own research and talking with our cohortmates to discuss approaches.

This was also our first exposure to working collaboratively on a code-base, meaning there were issues with merge conflicts, overriding CSS, and maintaining clean code. One benefit of not having a commute was that I would often stay up after sign off at 8PM to clean up code and read my teammates code to get an understanding of our application holistically.

After seeing repeated API calls in the lower levels of the application, I proposed utilizing Redux to maintain a global store of certain data that we all needed. For example, we all utilized the product ID to generate the data on a particular product, so why not keep that and other data that we all used in a store that we could pull from? Refactoring our code to implement Redux as our state management system became a more intuitive once I had a view on what each widget needed and what data could be pulled from the top level rather than repeatedly maintained at a lower level.

At the end of Week 8, we presented our projects to the rest of the campus and celebrated the completion of our first team project. There wasn’t much time for a break as we were then presented with the next major portfolio project: The Systems Design Capstone.

Systems Design Capstone (SDC)

The next capstone flipped the FEC on its head. Whereas in FEC, we were tasked with developing the front end with an API providing the data, in SDC, we were now being asked to create that API layer to serve up the data.

One of the first issues I ran into was the sheer volume of data. There were almost 5 GB of raw CSV files with millions of rows of data. Every attempt to read the data that I initially tried took entirely too long to process (often close to an hour). I looked into the idea of a buffer stream and found a viable solution to my problem.

The issue with trying to load in all the data at once was the limitations of the computer’s memory. It isn’t designed to hold that much data temporarily and ingest it at that volume. By breaking up the giant file into chunks, the processing and loading into my database became much more streamlined.

After getting my data loaded into my database, I set up the API routes in my server to trigger a query to my database and have it finally return the data for the client to utilize. For example, hitting the questions/id?=1 of my API might return the questions and the associated data regarding the question with the ID of 1.

After testing my routes and configuring them to handle queries from the client, I looked into stress testing the service to see how it stood up to production-scale levels of web traffic. At around 1500 client requests per second, the server began timing out and the error rate of the service began to increase, so I looked for additional avenues for improvement.

When I looked into the logs of my sever, I noticed that the latter requests were being backlogged and never made their way to the database to trigger the query, and thus were timing out. In my restaurant analogy of a full stack application from my last article, it would be as if the line cook who was tasked with gathering the ingredients to create the hamburger was the only person available to go to storage the retrieve the materials.

This person was getting overwhelmed by the volume of requests coming in, so I decided the best solution would be to incorporate a load balancer. This way, even if the server had sent a worker to execute the query and retrieve the data, it wouldn’t be stuck waiting for the results to execute further requests, there would be an extra worker on standby to go run the request.

I combined the load balancer with Kubernetes, a container orchestration system that served as an extra layer of insurance for the integrity and availability of my service. This way, if the service went down due to a fatal error, there was a template that could spin up a substitute server and continue the work. My service ended up improving to handle 3200 clients per second. You can see a video summarizing my Systems Design Capstone below.

Residency

In Week 7 of the senior phase, we were given the opportunity to interview for a role of resident: a teaching assistance / admin hybrid for the program. It was a great opportunity to make up for the mentorship that I wished to contribute to the program as well as give back to the community that had given me a new set of skills for a career pivot. Additionally, I would have more time to brush up on the content that I had just learned and apply my engineering skills to learn new technologies to build with.

When I received news that I had been offered the position, it was actually my birthday. I shared the news with my dog, who didn’t seem to understand the implications but was happy to see that I was happy. By accepting the role, I was agreeing the forgo the remainder of my senior phase and become a part time employee of Hack Reactor. Instead of spending the last week on the job search, the new residents instead shadowed the departing residents and learned what life behind the scenes of the program looked like.

On Week 12 Day 5, we finally arrived at graduation. We were the only cohort to have been both online and in-person and would be the first cohort to have their graduation online. There were laughs and heart-warming memories over the course of the ceremony and at the end, we said our goodbyes. After all twelve of us had crossed the finish line, three of us remained behind to continue on as residents.

Retrospective

The curriculum at Hack Reactor was seriously fast paced and required more than just showing up and passively absorbing information to perform well. It was common to feel emotional swings between feeling completely lost and an ‘a-ha!’ moment that made the journey volatile, uncertain, but ultimately rewarding.

Unlike college, where there were lengthy periods of lectures and learning was primarily done in a student’s independent studies, Hack Reactor had a more hands on approach, where the topic you had just learned about would be worked on moments later and asked to be delivered as soon as possible.

This ‘learning by doing’ approach was different than what I was typically used to. I like to plan and chart out all the possibilities and weigh them against each other before making a decision. However, in a field as broad as engineering, there are any number of approaches to a problem and you are working on a deadline.

The project based work forced me into extremely quick iteration and a focus on completing requirements. Spending too long hung up on a problem could result in diving down a rabbit hole, only to develop a feature that wasn’t even being asked for . It taught me the importance of being explicit in my code and continually asking myself: “What exactly am I trying to accomplish here?”

A big takeaway for me was the fact that there are no “right” answers in software engineering. Approaches can be objectively compared in terms of performance, but in terms of the “correct” answer, it depends. An overly optimized, generalized, or modularized piece of code can certainly perform better, but if it is convoluted and difficult to understand, it essentially becomes a black box. If somewhere down the line, that piece of code produces a bug, good luck with that.

The educational portion of my experience at Hack Reactor was challenging physically and psychologically. At first, I felt a bit rusty being back in a classroom and being a new student again. It was refreshing to be surrounded by other people who were in the same shoes and learn as a community to round out each other’s skillsets. I walked away after graduation not only with a new set of technologies and skills, but also a healthy dose of confidence in my ability to learn quickly and apply new knowledge.