Blogging 467

Although this term has been enjoyable, challenging and full of learning experiences, I am happy this term is inching closer to the end. It amazes me how fast time has flown this term has it feels January 3rd was just this past week. I guess this could be thrown up as a consequence of enjoying the class so much this term I forgot about time.

I am thankful I was able to work with such well informed and flexible teammates. Each member on the team has been invaluable to our efforts and our success is in large part due to our efforts to work together like a well oiled machine. Most importantly, it has been a wonderful experience learning more about each one of them as the term has progressed. Meeting them and being able to build an application is definitely an experience I will cherish and have fond memories once my OSU days come to an end.

Lastly, I am thankful for the structure and guidance this class has offered. The instructor and TAs have been great stalwarts of the classroom and have not hesitated to help when able.

A few days ago I marked my one month anniversary as a software engineer. It has been quite exciting and interesting up to this point as making a career change always comes with its challenges. Some days tend to be more exciting than others and the same goes with the tasking. Not every task I will be assigned will be fun, however I am learning and realizing that each task is an opportunity to learn and grow.

Getting more familiar with the codebase and project as a whole is going in the right direction. Participated in my first demo in the last sprint which was exciting. Was not expecting to present however the product owner was pleased and my task was closed out as a success. I am glad I am getting early exposure as I believe it will only help with my confidence.

The team I was assigned to have been great thus far. They are all very capable individuals who have not hesitated to help me out or answer a question I may have. Most importantly, they have made me feel welcomed and have significantly eased my transition into this new role.

Getting involved with open source software projects is a great way to prepare yourself for a job as a software engineer. Many of you may find yourself assigned to a team or project where you will be dealing with code that was written years ago by different software engineers who all differed in logic. Thus when it comes time to improving and refactoring this code, it can be tedious.

To best prepare for a role as such and interpreting what code in a program does that was written by other people, I suggest dabbling with open source projects. It will teach you to take the time to learn what the codebase and figure out what code calls which file and such. You will be able to hone your skills and refine your methodologies by participating in these open source projects. Most importantly, the skills learned will be invaluable when you transition to a full-time role as a software engineer.

Before I began my career I used to watch numerous videos on YouTube labeled “a day in the life of a software engineer” hoping to get an idea of what typical work day was like. Most videos seemed interesting considering they consisted of the person waking up at 9 am to start their day, strolling into the office to eat breakfast, a few meetings with the team before lunch and then finishing up the day back at the office to play a few games and code. Now although this seems like an awesome typical workday, which I’m sure a certain fortunate people enjoy, these videos can be more than a bit misleading unless maybe you do indeed work a major tech company.

Granted the company I work for is not a major tech company, we do have certain perks but nothing in comparison to what many of these videos lead you to believe happens on the job. First and foremost, there is no sleeping in. Stand-ups are every morning at 8:30 am so goodbye late nights. These stand-ups have been somewhat odd to adjust to considering they are everyday and lasts maybe only a few minutes. Personally, I think it would be easier if everyone on the team just posted what they were working on for the day on a shared Google document for everyone to acknowledge, however in the software engineering world we must abide by a software development framework and on this role it is Scrum, thus daily stand-ups are the norm.

With the exception of daily stand-ups the only real meetings are sprint refinements, review and retrospective. Each type of these meetings during a sprint are unique and occur only once throughout the two week sprint. Sprint refinements are what you think they are, a time to discuss tasks assigned in the sprint and the need to make any sort of refinement. Whether that is breaking down a task in two sub-tasks are allotting more time to a particular task, this is all discussed during a sprint refinement meeting. A sprint review or otherwise known as a sprint demo is an opportunity to showcase what you have been working on during the sprint. Thus the task you were assigned at the beginning of the sprint, must be complete and working to show to the product manager what you completed with the product manager making the ultimate decision to decide whether a sprint task is complete or not. At times the product manager may ask for more functionality. A sprint retrospective is an opportunity for the team, free of the product manager, to discuss internal issues, ideas and strategy. I have only attended one retrospective thus far since I began my role, but these meetings are designed to give the team an allotted time to discuss and sort out kinks or issues without management being a part of it.

The end of the day usually entails just coding or reading up on documentation. At this stage I have become more accustomed to coding as I reserve the early part of the morning prior to the standup to read on documentation, however this can take place whenever one is stuck and trying to figure out what to do. Oh and last but not least is tracking your time. Something many of those “a day in the life of software engineer” videos does not show is if you are working on multiple projects or even one, you must accurately document your time. The purpose is to allocate how much time was spent on a certain project in relation to budget.

Overall, the career switch has been adjustment and working in the corporate world has differed significantly from my previous role. However with time and experience I expect I will get better acclimated to the position and company. Landing this role was not easy, so I will continue to keep my head up as I deal with the corporate grind.

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.