From Teaching Middle School Math to Being a Full Stack Software Engineer
By: Reinald Reynoso
Tags: Algorithms, Career Change, Software Engineering, Career Advice, Programming

I’ve recently received my first offer as a Software Engineer for a great company after 3 months of job searching. As I’ve finally reached my goal, I wanted to take some time to reflect on my journey leading up to this moment.

Teaching

I was a middle school math teacher for about 4 years. That period of my life was certainly a challenging time. Being a teacher in a public school was no joke, especially in a middle school setting. I personally enjoyed facing challenges and finding solutions to overcome them. However, at some point, I felt that the challenges I faced were no longer providing me personal growth. I felt that I needed a change and that being a middle school math teacher was probably not something I wanted to for the rest of my life.

It was around that time that a friend of mine also landed his first Software Engineering position at Forbes. He was really happy with what he was doing and that had an impact on me. I felt that I wanted that for myself but I did not want to go back to college and spend more money to learn how to code. My friend suggested a Udemy course on Web Development by Colt Steele to get started. It was a great course but during that time, I wasn’t able to fully combine the concepts together. I needed more structure.

Fortunately, my friend offered me another alternative solution to learning: a coding boot camp, Flatiron School. He did not attend the program itself but some of his colleagues at Forbes did. Furthermore, he mentioned that his colleagues also did not have coding backgrounds and learned the core concepts from Flatiron School to succeed in an environment such as Forbes.

That reason was enough for me to select Flatiron School and take the next step. From there, I applied for the program, passed the interviews, and got selected for their April 1, 2019 cohort. Afterwards, I made the decision to leave my role as a public school teacher and dedicate myself entirely to this program.

Flatiron School

My time at Flatiron School included stints as both a student and a teacher.

Student Mode: Beginning

When I started the program, I was both extremely excited and nervous. After introductions, we were immediately paired up and given a project to work on. The project itself wasn’t difficult but it made me realize just how fast the pacing can be.

The first couple of weeks were what’s known as Module 1, which covered concepts in Ruby. It was a challenge for me but it was good since I was learning and growing. I had to adjust to the pacing of the program. New concepts were consistently being exposed to us and many labs were released for us to work on. Initially, I thought that I had to complete all of the labs in order to keep up but I did not realize that until way later in the program.

Student Mode: Struggles

Naturally, I felt I was falling behind early on. My imposter syndrome was at an all-time high. I felt everyone else in my cohort was keeping up with pacing and completing all of the assignments. However, that was not the case as there were others in the same situation as me, I just was not aware of it at the time. It was a matter of controlling my mentality and learning to adjust.

It didn’t help that I was not able to pass the code challenge associated with that first cohort. A lot of negative thoughts came with that and made me question if programming was for me especially since I couldn’t pass the first of many code challenges, and that it would only get harder from there.

But it was not the end for me. I had another opportunity to showcase my understanding of Ruby. I decided to push forward and focus on the project. Working on the project gave me the opportunity to apply the concepts that were taught to us and it helped me make the connections. With that, I showed just enough understanding to move on to the next module.

Student Mode: Project Partner

When the next module began, I had a much better grasp of how to prioritize my learning. I also a much better feel for the pacing of the program. In that second module, I passed the code challenge and had the opportunity to work with a partner on a full project.

Before, I was paired with a partner to work on minor labs/assignments. It was my first time working collaboratively with someone on a web application. It presented me with another learning experience. We brainstormed a few project ideas and discussed how different ways to implement them.

While working on the project, it made me realize that I still did not fully grasp all of the concepts taught in that second module but I was able to learn from my partner.

Student Mode: Finish Line

By the third module, I had fully adjusted to the pacing and structure of the program. More importantly, the concepts covered from then on involved the programming language I had some experience with, Javascript.

I’m not saying that it was smooth sailing especially with some of the hidden challenges Javascript provided, but I knew what to expect. It was essentially a similar experience for the fourth module, which covered the React library.

For the final module, I had the opportunity to work on a full-stack application for three weeks. I went through the entire process of designing and coding the entire application from the server to the client and everything in between. That’s where everything came together for me. I was starting to see how the code communicated with each other and connections were being made.

Creating the full stack application along with successfully completing the Flatiron School coursework were two major accomplishments for me at the time. It provided me with the basic structure for learning other programming languages.

Teacher Mode

However, my time at Flatiron School did not end there. Shortly after finishing the coursework, I was hired as a Software Engineering Coach. I returned to teaching but I already knew that it would be different and better. I attended lectures and re-learned everything I was taught as a student. It made me realize that there were concepts that I didn’t fully grasp.

This time around, I was continuously growing through teaching. Explaining the concepts to my students was the best way for me to test and build my own understanding of programming concepts. On top of that, I wrote blogs on Javascript, Ruby, and how to create applications from the ground up to provide an alternate resource for anyone who wanted to learn web programming.

Learning just didn’t occur during my coaching hours. On the side, I continued to watch programming tutorial videos on YouTube and Udemy. Notable instructors I watched were TraversyMedia, Andrew Mead, Dev Ed, and of course, Colt Steele.

I focused on Javascript concepts including NodeJS and React. I wanted to focus on mastering one programming language and its key concepts instead of learning multiple languages.

I developed multiple full-stack applications to apply the concepts I have learned from those resources. Looking ahead, these projects would be essential in the job searching process. Not only would they provide samples for recruiters but the experience itself provides great talking points during interviews.

My time at Flatiron School was certainly a great experience as both a student and a coach. The learning and growth never stopped for me.

Job Searching

It was time to pursue my original goal and the reason I enrolled at Flatiron School: a career as a software engineer.

Resume/Portfolio

Before my time ended at Flatiron, I created my resume and website portfolio. I dedicated a good amount of time to ensure that both stood out enough while showcasing my ability and skills.

With my resume, I used a template from canva.com. They have simple, yet great resume designs appealing to the reader. The only downside is that parsers have trouble reading data accurately.

With my website portfolio, it was built with React and deployed on GitHub. The focus of the portfolio was to show more of my work that could not fit on the resume.

I felt that either the resume or website portfolio was important in grabbing a recruiter’s attention and helping me land an interview with a company.

Data Structures & Algorithms

Once that interview was scheduled with a company, it was essential to have some understanding of Data Structures and Algorithms, which I did not fully focus on during my time at Flatiron School.

Immediately, it was something that i shifted my attention to. I had a few resources available: a Udemy course on data structures and algorithms taught by Colt Steele (yup this person again), Interview Cake, and of course LeetCode. My structure of learning DS&A revolved around these three primary resources.

Colt designed the course so that a student can start from any topic but he does mention the prerequisite knowledge required. I watched Colt’s course in order, even though I had some experience with some of the concepts he taught already. But it was a good review. After watching, I’d work on some problems from Interview Cake and LeetCode to practice the concepts he went over for a specific section. This was something I worked on over a course of two months. I did not attempt to rush absorbing the material.

With LeetCode, you can search for interview questions specific to a company. However, you would have to purchase a LeetCode subscription. I am, in no way, saying that it’s a bad decision to do so. In fact, you’ll have access to more content and it’ll focus the attention on the specific company you’re interviewing for. To be transparent, I didn’t want to spend the money. Also, I wanted to first comfortably solve the questions that were available.

Working on these technical questions was certainly challenging, especially LeetCode questions. Even the “easy” level questions gave some trouble. It’s certainly still a challenge for me to this day.

But the biggest issue for me was that I was not accustomed to the process. To get over this obstacle, consistent exposure and practice were necessary. Early on, there were moments where I spent a good amount of time attempting to solve problems not getting around to finding a solution. Those types of problems would certainly take my confidence away.

At some point, I realized that spending too much time on a problem and getting nowhere was not efficient. I learned that if I was on a specific problem for too long, I would read the discussion board for how others solved the problem. The intention was not to copy the solution but to gain insight into how they came to that solution.

Interview Process

As expected of the job searching process, it took a while. The responses from recruiters for an interview were few. When the interviews were scheduled, it was another process to get accustomed to. The only time I really had practice was during the interviews themselves. There were a couple I made the final rounds but I underperformed.

Most of the time, it was automated responses stating that I was not selected to move on to the next round. It could be frustrating to not even receive an initial interview especially during times I passed the code challenge assignments.

Attempting to understand how some companies select who gets to move to the next round was a difficult and impossible thing to do. But it was all a matter of moving forward and learning from the failures. I continued to practice data structures and algorithms.

Interview Preparation

One day, I received an email for a phone screen technical interview. To me, it came as a shock since I applied not expecting a response. For this interview process, I decided to try something different on top of practicing DS&A.

I decided to do some research on the interview process for this company on Glassdoor and reviewed other candidates' experiences to try and gauge how the process would be. On top of that, I contacted the company recruiter as well to ask for advice.

Equally as important, I searched LeetCode for discussions involving the company’s interview questions. There was a good selection of questions mentioned and it probably didn’t include all of them.

But my intention was not to ask for, find, or remember all of the questions the company possibly asked all their interviewees. There was no way I could remember them all for the actual interview. There was also no guarantee that those questions were going to be the ones given to me.

Instead, I used them as references as to what questions I should work on to get accustomed to the type of questions I would face. For the most part, they were higher-level questions than I was used to. However, I was able to apply some of the strategies and information Colt taught most of them.

When I had my phone screen, I was a bit surprised at the level of the problem. It was relatively simple compared to what I was practicing. The practice certainly paid off during that round. A week later, I was contacted again by the recruiter for the next rounds of interviews. It was three rounds, an hour each, two technicals, and one behavior.

In preparation for the next rounds, the recruiter gave me a heads up mentioning a list of the data structures (which, was most of them but some of which I haven’t reviewed yet) that might be asked. I continued my structure of watching Colt’s lecture and practicing until the day of the interview.

The days leading up to the interviews were completely nerve-wracking. No matter how much preparation I did, I felt that it was not enough and that I needed more practice. When the day came, I spent that morning relaxing and saving my mental energy for the interviews. I felt that helped for the marathon of interviews.

Interview Results

When I finished my interviews, I wouldn’t state that I aced them. As expected, the questions presented to me were questions that were not on the LeetCode discussion but they were a variation of some of the problems I have practiced, which helped tremendously in approaching it.

I did enough to demonstrate my core understanding of DS&A by verbally communicating to my interviewers. I clarified what problem(s) we were trying to solve, cleared up assumptions as to what data we’re receiving/returning, and discussing how to solve the problem mentioning tradeoffs. What helped was understanding what the time and space complexities of each data structure were and for what purpose each data structure was implemented, which Colt Steele covers in detail.

I passed the three interviews that day but I had one more final round. This gave me anxiety as this was not my first “final” round and I underperformed in previous ones. My recruiter did mention that this one was not going to be too technical compared to the ones I already had. It was more of a discussion of one of my projects. In preparation, I reviewed my projects and focused on the structure so that I could readily explain why I designed it this way.

When the day arrived, I had my points prepared and ready to discuss. Instead of talking about all my projects, I was given the option to choose one. However, if there was a downside, I had too many points prepared and I was scrambling a bit to find which points to zone in on during the discussion. It was only a 45-minute interview, so I couldn’t talk about everything. At the end of it, I felt that I was able to talk about key points about the project’s structure and the tradeoffs I made through its design.

The next day, I received a call from another recruiter stating that the company would like to extend the offer. When I received it, I was speechless. I encountered so many rejections that I felt it was going to be another one. But thankfully, the company saw my potential and made me an offer.

Job Searching Reflection

The search for a software engineering position took approximately three months and I found the period absolutely brutal. Some people in my position are still currently searching or searched even longer than I have before eventually landing one. Regardless, I realized that the job searching period can be stressful and difficult, especially in this field.

The rejections that came with it were always difficult to accept. A lot of negative thoughts resulted from it, such as doubting my abilities and believing that I was not good enough to be considered, and occasional thoughts of comparing myself to others.

Those types of feelings should not get the better of anyone. However, that can be easier said than done. In my case, I acknowledged those frustrations and let them out instead of bottling them up. It made it easier to move forward.

Whatever the case may be for you, always move forward and continue to improve when faced with job rejection. It’s not the end and there are many more opportunities out there.

Closing Remarks

Looking back on my two-year journey since I left teaching in a public school, I certainly had no regrets. I was not happy with my situation and I could not picture myself doing it for the rest of my life (at least happily). I felt that I needed a change during that time and I was fortunate that a specific path was shown to me.

But of course, the alternative path I took to programming was not easy. I had to work even harder just to compete with other candidates in the field. But as long as I enjoyed what I was doing, I was able to give it my all and pursue my goal. So if you’re considering a career switch to software engineering and wondering if it’s possible, it is!

Thank you for reading!