Struggles with Live Coding

Posted by Alex Zdatny on September 29, 2019

I was pleasantly surprised when I learned that I had passed the mock technical interview with Skilled Inc. While I studied a week in advance, there was still some doubt that it wasn’t enough. Having spent the past several months coding heavily with JavaScript and React, a lot of the original concepts and definitions of Ruby that I learned were still a bit rusty to me. I decided to choose Ruby because it would test my abilities of earlier concepts and I would also understand what I could improve on before starting the job search.

During the interview, I was asked to create a system where Purchases had three attributes including type, price, and millisecondsSinceEpoch. Also, that the JS front end was expecting to receive arrays of these purchases. If this were a few months ago, I still would have been frozen while trying to solve this. Not because I wasn’t confident in my coding ability, but being put on the spot has been a fear of mine given my anxiety. It was the first time outside Flatiron that someone was assessing me as a full stack developer. However, I worked through the problem without much struggle because I thought more about the logical steps rather than the destination.

When solving coding challenges or live coding, I’ve learned to communicate successfully through the steps because of the Flatiron School and their incredible staff. It’s been a long road to get here, having underestimated myself many times and not taking advantage of the resources that I had. There could have been an easier route, but it taught me a lot about myself. Working under pressure can be a daunting experience, but issues are not solved without this element. You want to be in situations where critical thinking and strategy are at the forefront.

I’ve always encountered the silliest errors in labs or on my portfolio projects. Whether it was missing commas or putting too many ends, I’ve gained a great skill of paying close attention to each line of code throughout Flatiron. Continuing with the skilled interview, I thought of every possibility of how the code could work by talking out loud. Instead of just jumping ahead to what’s the solution, I understood that thinking in concrete steps and comprehending error messages are the most beneficial to progressing forward. Some concepts and fundamentals are generally set in stone, but there is rarely ever one answer.

With this in mind and the fact that I practiced with Ruby in several ways, I was eventually successful in debugging any errors that I faced. Going forward, I want to continue to enhance my communication skills, as it’s something that you can never stop improving. You can write the most functional code there is and still have trouble breaking it down in front of an audience. Not because you don’t understand it, but because it’s a performance and a test of your skills. One of the greatest things about The Flatiron School is the sense of community. Programming can be difficult, but nothing is built effectively without a support system. In every assessment or technical session that I’ve had, there was always an instructor or another programmer to support you.