Blogging 467

So I began my first task a few days and I am quite proud of myself for being able to complete the task ahead of time and without much fanfare. Granted I did need some guidance from one of my co-workers in regard to utilizing the proper setup and tools for the job, the insight I gained was invaluable and something I will definitely use to complete future tasks.

Prior to leaving the office a few days ago I made an attempt to discuss about possibly participating in a task from this week’s sprint with one of senior engineers on the team. However I was advised it would best if I instead familiarized myself with the code base considering I had only been on the job for a few days. I accepted the assignment and understood. However in the daily standup the next morning, one of my teammates who was not made aware of my duties from the senior engineer, gave me a task to complete on the spot. I will admit I was a bit nervous, but figured I would to be thrown into the fire sooner or later to better acclimate to the job.

The task I was assigned with was pretty tedious considering it involved rewriting legacy code and algorithms to conform with a new software update that would be released with an updated external tool. Fortunately, I took good notes and took the time to really figure out what member function called what from what class and reviewing header and source files over and over. To be honest, it took me more than a few hours to get acclimated with a branch of code that contained numerous changes that I would soon need to partake in.

After a few confident hours of realizing what I needed to do and what I would need to refactor and create, I began to write out a plan for myself to better set benchmarks in my build process. I had an idea however writing out my thought process really helped closing the gaps in what I needed to accomplish. Next, I spent hours refactoring and writing code to meet the expectations I created. Plus I got exposed to a valuable lesson in regard to ensuring that I declare a function in each child class once a pure virtual function is declared in a base class. I made the mistake of declaring a member function in only one child class and not the others thus leaving me to make some revisions.

Finally after many instances of testing my code and ensuring it worked accordingly before pushing the code to the repository, I made the mistake of not pulling the last code changes before pushing my code. Thus, I learned another lesson and spent another few countless hours fixing the issues until my code finally ran accordingly with the last pull. Thankfully, I was finally able to push my changes and although I have not yet received feedback, I am grateful I was able to complete the task and anxious to hear feedback on my method and results.

This past Friday officially marked my first week at my new job as a software engineer. Now although this feat is not quite something many people are proud off or acknowledge in many cases, the end of my first week does mark an early milestone in my budding career. Most importantly, this first week laid a blueprint of what a normal work week would consist of with this new job.

The Stand Ups. These quick meetings in the morning were quite easy to adjust to. I was quite impressed with the quick format and the discussions that come along with the meeting. Not only do these meetings keep everyone in the group in the loop on what you are working on, but also the opportunity to ask other team members for help or guidance in regard to solving a bug or issue.

I will admit I am still adapting to the revision meetings and other meetings that are scheduled during the sprints. With the exception of the stand-up meetings, which are held daily, there are a few other meetings with different purposes at different time frames scheduled throughout the work week that require I place the upmost attention to my calendar. And after this first week, I am sure my calendar will be my one of my most popular tools in order to keep me on track with the job.

Some of the highlights of my first week included finally being able to meet the other engineers who were part of my interview process. It was interesting to finally put a face to a voice that I had only encountered once over a GoTo Meeting call a few months ago. Plus, it was great to hear their feedback of how they got started at the company and informing me on the do’s and don’ts of the office. Plus with so much orientation and learning during my first few days of the week, I really appreciated them stopping by my cubicle to help me sort out some of the corporate framework. And last, but not least, I met the team I would work with. I was very impressed to learn their backgrounds and was proud to have been assigned with such a diverse and intelligent group. Granted a few of my other teammates were working from home and others out of the office, those I did meet instilled a very positive attitude about the team.

Landing a full-time software engineering role is not easy. Especially while you are still in school and working full-time in another profession. Not only must you learn to juggle your daily duties for your job, but also the commitment to the classes in which you are enrolled as well squeezing in time for interview preparation.

When I first got the opportunity to go through the hiring process for FAANG company, I was very poorly prepared. Granted a recruiter had reached out to me asking me to apply, I honestly did not think I would be fortunate enough to participate in the online assessments. Thus, I did not take the proper measures to study up on Leetcode questions I would encounter during the assessments.

During the first online assessment, I decided to do first round of questions in the C programing language. Bad idea. The questions I was forced to answer involved using complex data structures that took too long to code in C. Time is of the essence during these assessments as the more questions you can answer, the better chance of moving on to the next round. Granted the questions you are able to answer successfully, must pass the tests presented. Luckily, I answered not all of the questions, but just enough of them correctly to move to the next round.

When it came to the interview process with other engineers, I stumbled answering the behavioral questions in the manner they preferred. They wanted answers in the STAR format which I had never done before. The answer format required that I describe the situation I was in, the tasks that need to be handled or completed, the actions I took to complete those tasks and finally the results from my actions.

Answering these behavioral questions on the fly was difficult without proper preparation. I made the mistake of assuming most of the questions I would discuss during the interview would pertain to my resume and past projects listed on my resume, but that was not the case. It was a very rude awakening and a bit embarrassing considering I felt I could have answered those questions much better had I prepared or thought of scenarios that fit those behavioral situations.

After the completing the assessments and interview process, I was rejected. I will admit I was very upset with myself after getting my rejection email and kept running the “what-if” scenarios in mind. I felt like I finally had an opportunity and I blew it. However, after a few days of moping around and doing some reflection I realized it was a great learning experience for me. I forgave myself for my faults and learned I needed to make some changes and improvements if I was serious on landing a job as a software engineer.

The failure lit a fire in me that helped me devise a plan that ultimately was a path to success. I began by allotting an hour of everyday doing a few leetcode questions. If I could not answer all the questions in an hour, I would stop and pickup where I left off with a fresh mind. Eventually, I began to do a series of questions while timing myself in order to become more aware of time management for each question. Most importantly, I stopped doing these questions in C and moved to C++ which had a bunch of built in libraries that would make my time coding much more efficient.

Next, I began thinking of scenarios similar to the questions I was asked during the interview. I would then write out my answers for each aspect of the STAR to better describe my thought process. I would write copies of my answers to memorize my answers. Eventually, I was able to refine my answers with time and added new ideas that improved my process.

After making these changes to my study regimen and dedicating ample time to preparing for behavioral questions despite handling a full schedule with working full time and an eight hour course load, I felt prepared. Thankfully, the next opportunity I was given to interview for did not take long. And with the preparation I had, it was a breeze. I managed my time effectively answering coding questions, demonstrated confidence explaining my logic and time complexity and finally knocked out the behavioral questions with ease.

Was it easy dedicating extra time to the process? No, but I exercised restraint from deviating from my plan knowing what my end goal was and how I wanted to accomplish it. I hope my experience can serve as a valid template of what not to do and instead of how to do in regard to landing a full time role as a software engineer.

A few years ago while working in my previous role at an oil & gas services company, I stumbled across accessing the back-end of our database system. Intrigued, but also very confused about what I was looking at, I started down a rabbit hole that would ultimately lead me to OSU’s post-bacc program.

After making this discovery at work, I began hopping on codeacademy everyday at home in an attempt to learn more about web development. I first began learning HTML, followed by CSS and then Javascript. As I progressed through the online curriculum, it was awesome to visually see what I could accomplish and was hooked to learn more.

Unfortunately, one day after arriving back to work from my lunch break I was informed I would be laid off. The news was tough. I had relocated to another state at the behest of my company and had no other tangible skills that would help me land a job in a different industry. Plus I knew my previous degree in political science was not in very high demand and would not be enough.

Thus recognizing I needed more education and applicable experience, I thought about enrolling in a coding boot camp however many of the job postings in my area required having a degree. As I continued to peruse for information and surfing on reddit in-between job searches, I came across the OSU post-bacc program.

Immediately I felt this program was designed for people like myself who wished to gain a promising educational experience in attempt to make a career change for the better. Starting the program was tough as I had no prior coding experience other than doing web dev stuff on codeacademy and C++ was like a foreign language to me, but I stuck it out. I put in long hours, read the book over and over and grew a deep understanding of the language. Thus after my first term was over, I developed a deep confidence in myself that I could succeed in this program with the ultimate code of landing a software engineering job.

As I progressed through the program I began to learn other languages and skills that would only further my confidence and help me succeed in my job quest. Learning data structures in C was amazing. I enjoyed it so much that at one point all I wanted to do was code in C. Assembly language was amazing as well as I was fortunate enough to ULA for the class for two terms, which I firmly believe was a great experience for myself and bright spot on my resume for potential employers to acknowledge. Plus, building a micro-service in Python really helped me hone my skills in the language as I was a late bloomer to learning the language.

Despite not yet having my degree, I began applying to jobs and was astounded with the feedback I received. Granted I built a portfolio with my projects to showcase what I could do, I was inundated with OA’s and interviews. Some OA’s I totally butchered as I was new to the process others I did really well on. Same thing with the interviews. Overall, despite my flops in the interview and OA process it really helped prepare me for the next opportunity and how to effectively manage time in OAs and crush coding questions.

Fast forward to now, all the time, stress and effort paid off. After many interviews and coding challenges, I was able to land a software engineering role with a defense company that I am super excited about. I have always wanted to work in defense and create products that help in achieving our nation’s mission of national security. I am grateful for  the guidance and framework OSU’s program and instructors have provided me and look forward to my new journey as a software engineer.