Final Paper
| Aug. 4th 2025 |
| CYSE368/Internship – Summer 2025 |
TABLE OF CONTENTS
Introduction
A summer at Maximus absolutely flew by but I am so grateful for the opportunity. I initially chose to intern at Maximus because they were offering such good terms and it was the position I really wanted. I had the option to do an unpaid in-person internship that was two hours away from where I live, doing regular old IT, or do a paid remote internship with Maximus in the position that I wanted. From that standpoint it was a no-brainer. The position I interned in was Cloud Engineer, which is what I am aspiring to be upon graduation. How could I not go with this option?
Maximus is a Federal, State, and Local government contractor providing administration and other services for Medicaid, Medicare, healthcare reform, welfare-to-work, and student loan servicing, among other government programs. They are a global company operating in Canada, India, Saudi Arabia, the United Arab Emirates, the United Kingdom, and the United States. Maximus started with contracting IT companies in India and eventually ended up buying one and turning it into Maximus India. Now they are trying to win contacts with the Indian government to provide services and technology solutions.
Maximus was founded in 1975 as a consulting firm for the federal government, including information technology services. Their history follows a series of government policy changes that led to the company being listed on the New York Stock Exchange in 1997. Throughout Maximus’s history, there have been many ups and downs, many changes to the business model… but one extremely important business model change happened five years ago, which I’m very grateful for… they took the leap to fully adopt the cloud and remote work. Maximus went from having multiple corporate offices and a plethora of data centers throughout the country, to hosting almost their entire operation in the cloud. They sent nearly everyone to work from home, sold their offices, and leased two floors in the building in Tysons, Virginia that they would call their headquarters. Nearly 50,000 people working remotely and the operates like a well-oiled machine. Maximus recently purchased a student loan servicing company and created Aidvantage which is the company that services my student loans… so I’m interning for (and getting paid by) the same company that will be taking my money to give back to the government. Something about that feels ironic.
The entire first week was Human Resources training and orientation which was enlightening and welcoming. We did have to complete the classic corporate training where you watch the cheesy videos and answer questions afterwards… this is a yearly requirement, from what I understand. Surprisingly, Maximus provided us with great benefits, even as interns. They brought in a benefits specialist to go through all of them and make sure we got signed up for the correct programs including health insurance, dental, vision, 5% 401(k) match, all kinds of wellness programs, etc. They brought in multiple C-suite speakers to come and impart their wisdom upon us, including the CEO, Bruce Caswell. It was clear to me that this was a real corporate environment, which was something I had never experienced before. I have worked at small companies my whole life… my last role, of seven years, was at a company with nine people. I was preparing myself for a rigorous internship where you keep up or you get kicked out. Once we gained access to the systems and had all of the HR stuff out of the way, we were handed over to our departments where the real learning began.
Going into this internship I had multiple learning objectives I hoped to achieve; 1. Understand and use core AWS services by demonstrating proficiency in provisioning, configuring, and managing them using the AWS Command Line Interface. 2. Improve and apply Linux system administration skills to manage cloud-based environments. 3. Develop and maintain automation scripts using Bash and Python to streamline cloud resource provisioning, configuration, and management in AWS and Azure environments. 4. Refine effective project management practices to successfully deliver technical projects within a corporate cloud engineering environment. We’ll talk about these later in this paper.
Management
The management at Maximus was hands-off but effective, which is what I’m used to in a remote role. My manager was the Director of Cloud Operations but I had multiple mentors that you could call my “supervisors.” They were all Senior Engineers and knew their stuff or knew how to source the information they needed. With the management being so hands-off, there was a lot of self-teaching. I would often take courses through a partnership Maximus had with Precipio. I was able to earn two certifications this way which impressed management and gave me quite a bit of knowledge specific to the Cloud Engineer role. I met with my manager once a week to discuss the week before. If he had any issues with the lack of shadowing or work getting done, he would send out an email to the mentors, which I appreciated. Two of three mentors didn’t take the time to shadow even when I would reach out to them specifically for that reason… so I definitely appreciated his management style. Open, easy-going, but direct, and stern if need be.
The management structure is that of a typical corporation. Everyone on the Cloud Operations team is either managed by the Director or a senior manager who answers to the Director. The Director of Cloud Ops answers to the VP of Cloud Ops, who answers to the CDIO, who answers to the CEO. There are nearly 50,000 people at Maximus but even a lowly intern like me can end up rubbing shoulders with people like the Vice President of Cloud Operations.
Duties & Responsibilities
My mentors were all over the place. One of them was great, someone I can contact any time if I need help or don’t understand something. The others were less enthusiastic about mentoring, which was surprising because they volunteered for the role. My second mentor was unresponsive, which I later found out wasn’t exclusive to me. Apparently, the guy just doesn’t answer Teams messages or emails for almost anyone. Even when the Director sent the mentors a group message, he requested a plan from them, and this guy just didn’t answer. I’m really not sure how he still has a job, to be honest. When I would meet with him, we would work with another engineer because they were actually doing work. I eventually started working with the other engineers and cutting out my second mentor entirely. My third mentor was always too busy to shadow and didn’t give me work so I would find things to do on my own or meet with people on his team. The third mentor was part of a sub-team that handled one specific account. It was one of the largest at Maximus. They did things totally differently from how the rest of the Cloud Ops team did things so it was difficult to follow at times. Instead of patching their servers through baselines, they used a Golden AMI which was edited using Git commands. They would commit the change and do a pull request. Someone on the patching team would approve the pull request then copy the AMI. In the AWS account, they would use the Service Catalog to delete the current AMI and replace it with their edited Golden AMI. After doing this with the DEV account, they would share the AMI with the other accounts in non-prod. This is in contrast to how the rest of corporate does their monthly patching.
One of the main responsibilities of my first mentor was corporate Linux patching which happened once every month. We would use BigFix to implement the patches that a separate team would create baselines for. The Provalus team created the baselines that my team would push each month to all of the corporate servers.
First, I have to explain Prod and Non-prod. Prod is short for Production servers… this is where the live website is and applications are hosted. Prod servers are NOT to be worked on during business hours or without a Change Management Request. Non-prod are servers used for development and testing; they do not host the live site or application. Non-prod consists of Development, User Acceptance Testing, and Quality Assurance servers. Although, some accounts treat User Acceptance Testing servers as Prod servers because they store Private Health Information (PHI) and/or Personally Identifying Information (PII).
Non-prod is always the first week of the month and there are four groups… Group A, B, C, D. Each group gets patched on a specific night of the week. Group A gets patched Monday night, Group B Tuesday night, Group C Wednesday night, Group D Thursday night. The next day we have to go through and make sure all of the servers patched properly. These are all Linux servers; the Windows servers were handled by another team member. In the BigFix console, we go into each group and scroll for the return code 0. We want to see all 0’s. If we see any 1’s it means the patch didn’t properly install and it needs to be looked into. This didn’t happen while I was taking part in the corporate Linux patching, everything went smoothly every time. Without this, servers would fall out of date and there would be security vulnerabilities abound. This is crucial to operations. It’s crucial for compliance. It’s imperative to the success of Maximus, which is quickly becoming a tech-centric company.
We were DNS Support, as well, so when anyone needed CNAMEs, NS servers, or whitelisting’s… we did it. The key with DNS support at Maximus is knowing if its internal or external. This would tell us which account to go to. Sometimes we would have to do work in both. DNS work is fairly simple once you figure out which account you need to be in. We are responsible for finding the correct hosted zone and creating the records requested of us. If done incorrectly, the giant tangled web of routes can get misconfigured and you have a communication nightmare.
Our team is required to wear many hats and the responsibilities range widely. We are assigned a few accounts to be the Technical Point of Contact on where we are required to keep the environment running smoothly. We have checklists to complete each month that include things like analyzing the Qualys scan reports for any vulnerabilities. Most of the time there are no critical vulnerabilities, most of the time there are false positives because the accounts are set up a specific way that the scans deem as vulnerable. Every once in a while, there is a vulnerability like a security update not installing on a Windows server. This can become a huge hassle like the one I dealt with that we will discuss later in this paper.
My team is also responsible cost analyses using a variety of tools. In AWS, we use Trusted Advisor but we take everything with a grain of salt because AWS is going to want to optimize everything for themselves, we also compare it to another application called Turbonomics. Turbo is more honest because it is a third party and it truly tries to optimize for you and your needs, not necessarily the needs for the infrastructure provider. Its incredible how important these cost analyses are… without them prices of infrastructure can skyrocket. This ties in closely to one of our other responsibilities, which is investigating for orphaned services. So, anything that isn’t being used anymore, like EC2 instances that are using low CPU… that traffic can be routed to another EC2 instance with ample CPU power and the first EC2 instance can be decommissioned. All you have to do is decommission it and the load balancer will redirect the traffic on its own.
I did a lot of decommissioning of infrastructure that was no longer being used, whether it was spun up for testing purposes or it was built in the wrong VPC. It happens so often and is so important to keep in check or else monthly bills will explode and profitability decreases. Not only do we need to decommission unused resources, Turbonomics would give us suggestions on right-sizing infrastructure to keep it running smoothly at the most cost-effective rate. It’s our responsibility to make the proper changes… to reduce the computing power here… to increase the memory there. With the prices of cloud infrastructure skyrocketing in the last couple years, this is one our most important responsibilities and shouldn’t be downplayed.
We are often contacted out of the blue to work on all sorts of things for our corporate and offshore colleagues. Sometimes, when the offshore team isn’t authorized to perform a certain task, it comes to us. We created some Name Servers for our Code Shuttle Development team when they contacted us, for example. Random tasks come to us from all directions and channels. It can be for building load balancers, DNS, allocating CIDRs to VPCs, you name it.
I often shadowed with the administrators of specific applications that Maximus uses like the Siebel application. This is a Customer Relationship Management tool used for the call center team in India. The administrators showed me how they are the ones to create users, place them into groups, give them roles, etc. When employees are hired on in the call centers, they have to be added to this application so they can perform any duties at all. Without this, they wouldn’t be able to access any resources or answer questions. This closely ties to the Oracle Knowledge Management admin’s role. When the users are added to Siebel, they must be added into OKM as well, to access knowledge resources.
The app admins are also responsible for all of the upgrades and patches to the application. For example, I worked with the BigFix admins to upgrade the BigFix application we use for corporate patching. The administrators of applications must make sure their apps stay up to date with the latest version of software. We were tasked with updating the application itself which was highly involved but great to see. It took multiple hours to create backups, shut everything down, run the multiple updates, then bring everything back up and reconnect it all.
I was also a part of the team who was standardizing operations between Maximus US and UK. We were tasked with spinning up BigFix repositories in the UK environment that would reach out to external BigFix repositories that were pulling updates from the Oracle update repositories.
Cyber Skills
While I wasn’t in a position directly related to cybersecurity, I did get to use some of my previously acquired skills. We used Splunk for remediating vulnerabilities in our accounts which I was familiar with from my studies. Researching the vulnerabilities came easy to me because I knew the proper places to go to and pertinent information to look for. CVEs were second nature to me so when they were explaining how they use Splunk I had no problem jumping right in.
I knew how to review logs to look for anomalies but my on-the-job training was far more complex. We were reviewing logs for ACCESS DENIED results which were easy to find but so difficult to remediate. When the system needed the proper permissions to perform security updates, my log analysis skills seemed like they were barely formed. It became clear that I knew how to review basic logs and follow simple guidelines to remediate issues. I was not aware that there were so many different types of logs and how much comparing would have to be done. How we would find something in one set of logs and try to recreate the incident and capture it with another type of logging tool… but sometimes we couldn’t capture it. I was surprised because I had never experienced that before. How could we capture it in one set of logs but not in the other? It turns out there are all kinds of reasons that can happen and I still don’t know why it happened to us. I understand now how convoluted the process of reviewing logs can be in complex cloud environments.
Permissions became a big issue when trying to troubleshoot patch updates. I was familiar with permissions but not how the permissions of one folder or a set of folders can cause such a headache. Sometimes they don’t act like they think they will, even when you give something full permissions. It can be very frustrating and I realized how they can also be a tangled web. If I don’t have to correct permissions, I can’t take ownership, then give something else full permissions. I ran in to this issue so many times when I thought it would work.
ODU Curriculum
The ODU curriculum prepared me for this internship in many ways, and in many ways it didn’t. Almost all of my Linux knowledge came from the ODU curriculum which I was so thankful for during this internship, and I am pretty sure its one of the main reasons I landed it in the first place. I credit the Basics of Linux class for a lot of the knowledge I used during this internship. Without knowing how to use Linux commands I would have been at a huge disadvantage because I was part of Linux monthly patching. While I didn’t know all of the commands and didn’t know how to administer Oracle Enterprise Linux servers, I knew how to navigate them and the specific Linux syntax.
The amount of Linux I used was inline with the amount of Linux I used in my ODU program, about 85%. Using OEL servers was a different concept that what I was taught though. I have Kali Linux which is an OS designed for penetration testing, not for the purpose of being a server. I felt like I was on the other side, trying to protect a server from someone using Kali Linux to infiltrate it.
I will say that I was clearly taught the rigid way of doing things, and rightly so. In the professional world, they were using commands like sudo su -y to continuously issue commands in an elevated state and to say yes to everything that comes. This isn’t quite best practice but it’s done for updates, nothing serious. But we were not taught to use su. We used sudo every time we wanted to issue a single command in an elevated state.
I was thrown into a task of trying to remediate a vulnerability in a Windows 2022 Server so I was very happy I took the Windows Server Security class. I had a natural ease of navigating the windows server User Interface and CLI. I was able to impress some of the mentors with my knowledge of Windows Server 2022. In my studies, I just scratched the surface, it’s an entirely different ballgame when you’re in there trying to fix a server. I was not prepared for how frustrating it would be to troubleshoot these systems.
My position was Cloud Engineer and ODU didn’t include much cloud computing material in their Cyber curriculum. Everything I learned about AWS and cloud infrastructure I learned on the side in my spare time. Granted, this was not a cyber security related position. Cloud infrastructure is just on-prem & legacy infrastructure in virtual form so without the foundational knowledge of on-prem & legacy infrastructure I got from ODU, I would not have been able to keep up. So, although I wasn’t introduced to the concepts of cloud computing I was able to easily grasp them because I understood the technology behind them.
I am grateful that the ODU curriculum prepared me for the CompTIA Security+ certification which I acquired just before the internship. I think that really helped me land it and it drove home some important concepts that was asked in the interview. They wanted to me tell them what I knew about Single-Sign-On (SSO) and Multi-Factor Authentication (MFA). By that point, I had been taking practice tests on topics like this for a couple week so I could answer no problem.
Outcome of Objectives
I’m happy to report that I was able to complete most of my learning objectives, with a few caveats. While I was able to get a better understanding of core AWS services by configuring and managing them… I did not do it via the Command Line Interface very often. I interacted with AWS almost exclusively using the Graphical User Interface, which is something I was told I wouldn’t be doing very much. In both AWS and Azure, we used the Console. It’s just easier and I prefer it for most things. Especially because we are building infrastructure through Cloud Formation Templates, so the code is already written. It’s been standardized into templates to reduce human error and to ensure compliance for all new builds. If we were doing more coding and building from scratch, I think I would prefer to use the Command Line. It just goes to show the difference between theory and practice.
I was able to earn the AWS Cloud Practitioner certification while I was at Maximus so I got to know the AWS services more in depth. Not only that but we worked with the main services often; EC2, S3, Route 53, VPC, Load Balancers. I spun up application load balancers for the offshore team, resized EC2 instances, created S3 buckets from Cloud Formation Templates, created CNAMEs in Route 53, etc. You name it, we were doing it in AWS.
When I wouldn’t have much to do, I would poke around in the different AWS accounts, looking at the CFT templates for the S3 buckets and the templates in the CCoE account. I got very accustomed to the AWS console and feel like I can cruise through it no problem. This is important when you need to be vigilant about which account you are in, which region you are in, where you are building your resources.
A bonus was getting to explore Azure as well. I worked with some people who had tasks to decommission VMs that were build in the wrong VNET in Azure. I was able to see the difference between the two and how Azure lists all of the resources irrespective of the accounts. I like how AWS makes you choose an account to go into to see their infrastructure.
I most definitely improved and applied my Linux system administration skills. Most of my time was spent with Linux servers doing patching and building repositories. I got more than just Linux exposure; I got Windows exposure too so this outcome was an overwhelming success.
Unfortunately, I did not write any automation scripts. I really thought I would be writing more automation scripts because that was one of the questions they asked me in the interview. They wanted to know how I would automate something if I needed to so I figured there would be more opportunity to refine that skill. I was wrong. Everything had already been automated for the most part and everything was built using a template or automation through elasticity.
I did take the lead on an intern group presentation so I was able to develop my leadership skills, which I am proud of. This ties into my fourth learning objective of refining my project management skills. When we were split into groups, no one in my group had any clue what to do so I stepped up and delegated tasks. I had someone create shared PowerPoint file, I decided that we should organize speakers in alphabetical order, I took ownership of the PowerPoint and became the slide master… I had to share my screen and control the slides. It was nerve-wracking because we presented in front of nearly eighty people, remotely, of course. The CEO and my Director were there to hear what we all had to say so there was a good amount of pressure. I think it went well and my group did a great job.
Most Motivating Aspects
It was so incredibly motivating to feel myself gaining momentum in my field/career. I feel closer than ever to achieving real goals. This was really driven home by acquiring two certifications during the internship through Maximus’s partnership with Precipio. As part of the intern program, they had a challenge where you could submit a course completion for a chance to win a prize. Not only did I find quality courses for passing these certifications, I was able to win a couple of prizes on National Intern Day because of how many completed courses I submitted.
I would have been required to get at least one of them but I did it without them pushing for it. My second certification is the CompTIA Cloud+ which would not have been required by Maximus but it is DoD preferred and Maximus just won large contracts with the Air Force. The Director was very happy to hear how it could be used in Maximus’s new FedRAMP High environment that I have already been working in.
I also received great feedback from my mentors and director which was encouraging and motivating in the sense that I wanted to keep up the good work. Hearing that the Director of Cloud Operations was happy with my performance and what I was able to accomplish outside of the internship was definitely a confidence booster.
Not only did I get good feedback, my director is trying to get the internship extended sixty-ninety days. Knowing that they want me to stay on for a while after the scheduled end date feels incredible, we’re just waiting to hear back from the Vice President of Cloud Ops. It feels like all the hard work and long nights I have been putting in the last couple years are starting to finally pay off and I don’t want to stop the momentum now.
Most Discouraging Aspects
The most discouraging aspects of tis internship was the lack of attention by some of the mentors. I know I’m an intern and they won’t have to deal with me for long but I don’t appreciate being ghosted when we set meeting times, or being left on read so often. I learned that this behavior wasn’t exclusive to me but it was pretty discouraging to deal with someone like this who volunteered to be a mentor. I didn’t understand that part. I tried to toe the line between being the needy intern and standing up for myself to get the most value out of the experience. When I would try to initiate shadowing or ask if they were working on something interesting, sometimes I would get ignored. There was never any bad blood, I always had a good attitude with him when we would meet but it got to the point that I started going to other people altogether for shadowing.
I also thought the work would be more like Cloud Architecture work. I found out that Cloud Engineering at Maximus is basically sysadmin but in the cloud. There wasn’t much building stuff from scratch, it was all made for you, you just put the blocks together. I realized that the position I thought I wanted actually wasn’t it. I have to alter my trajectory a little bit to accommodate this new information.
Another very discouraging aspect was my fault. I tried to get in there an get my hands dirty when a ticket came in that said a server was unhealthy and needed to be rebooted. So, I went to the server and rebooted it… well the server didn’t come back up and the Site Reliability Engineer contacted me. The server was unhealthy so it wasn’t my fault that it didn’t come back up but it was a UAT server with PHI on it and it need a CR before rebooting it. He told me to “stay in your lane” which was pretty discouraging at the time. I was able to turn it into a learning experience and shadow with him a couple weeks later so all is well that ends well. At the time I was told I was going to get a Change Management violation, I would have to redo the compliance training, and my director would be notified. Needless to say, I thought I was getting fired. It turned out not to be a big deal and the site reliability engineer was overreacting but it was discouraging trying to get in there and help and it turned into a mess where I got put in my place.
Most Challenging Aspects
The work itself is the most challenging part. It’s problem solving, research, and figuring things out. You just have to get in there and tinker and Google things until you get it. Sometimes it takes posting questions to Stack Overflow because we simply can’t figure things out. There have been times where we had to put in a Microsoft support ticket because we need their help troubleshooting an issue.
I tried for hours to troubleshoot a Windows server that would not take a security update. I still haven’t figured it out and I’ve been bashing my head against the wall. I’ve tried downloading the standalone installer, extracted the .cab files and installing those individually. I’ve turned off all custom and IIS/WWW services. I’ve troubleshot with different services interfering. I’ve tried to capture the process that is causing the problem. I thought I narrowed it down to a specific set of files that the Trusted Installer didn’t have full permissions to. So I took ownership of the files and granted Trusted Installer full permissions. I even gave ownership to Trusted Installer and it still didn’t do the trick. I can get the progress bar to move just a little bit further but it still fails. One of the most frustrating parts about it is that it takes twenty-eight minutes for it to fail every time. I have to make a change, then wait twenty-eight minutes to see if it worked. I feel like I’ve tried everything and yet I still can’t get this thing to work.
Another one of the most challenging aspects was learning the structure of Maximus. By not who does what, it’s hard to even reach out to the correct people for assistance but I’m getting better. I found an account ownership directory that helps a lot. Thankfully, my mentors would help me reach out to the correct people to access to applications and accounts because I had no idea. I would have just been asking around until someone pointed me in the right direction.
Another challenging aspect is having the discipline to work remotely. Some days the motivation just isn’t there but you have to rely on discipline. When you don’t have to be anywhere specific or wake up at any specific time to start… some people struggle with this sort of autonomy. If you are new to this kind of freedom, it can be so difficult to make yourself work. Thankfully, I’ve been in a remote role for seven years so I have the discipline it takes to work remotely. It may be an unconventional challenge but it is a valid challenge nonetheless.
Recommendations
I recommend anyone going for this internship to get your certifications first. They will provide you with the proper knowledge to be able to keep up and the credentials to show you are committed before you get that diploma. You have to get your Sec+ to get past the ATC most of the time anyways. Gaining the AWS Cloud Practitioner will familiarize you with the AWS services and shows that you are on the right path. If you can get the AWS Solutions Architect Associate you will already have one foot in the door. You can study your way through these certs, you don’t necessarily need professional experience.
Everything I learned about cloud computing was on my own time outside of ODU classes, so you have to go out of your way to find a lot of this information and go down this path. I ran into someone at the internship who was in a CYSE/CS program but hadn’t sought out extracurricular knowledge so he didn’t know what AWS was or any of the terminology. He was the only in-person intern and doing regular old IT, whereas we were all remote doing some sort of cloud engineering or software engineering. By the time the internship was coming to a close, it was clear he wasn’t happy with his position and he was asking all of us about our certifications and how we got our positions.
Above all else, get hands-on experience. I know it gets said over and over but you need to build a home lab and start building and breaking things. In between passing the first interview and going into the technical interview, I spun up an EC2 instance and SSH’d into it to get some hand on experience of what I thought I would be doing. I also spun up a S3 bucket to host a static website during this time. When I talked about this during my interview, they were so impressed, we ended talking about my little project for awhile and the things I learned from it. Come to find out, we weren’t even doing any work like that but they liked that I had the tenacity to get in there and try new things.
Even just setting up your home lab can help you talk technical in an interview which can get your foot in the door. People want to hear about the problems you ran into, how you fixed them, and what you learned. They don’t want someone who knows everything, they want someone who is willing to dive into daunting tasks and learn as much as possible.
Another recommendation I would give to students hoping to intern at Maximus would be not to be afraid to say you don’t know something but you’re willing to do the research and get back to them with an informed answer. Too many times, people think they are absolutely required to know the answer to questions. Of course, you should know about the subject you are interviewing for but nobody knows everything. Being able to show humility and accountability by admitting you don’t know and then educating yourself goes a long way. I ran into this scenario during my interview when they asked me what the differences were between AWS, Azure, and GCP. I simply told them that I think it’s the way they implement their container orchestration but I really wasn’t sure… and that I could do the research and get back to them. Turns out there isn’t much difference between them except some syntax so it was better to be honest that I didn’t know something rather than try to make something up to save face.
Conclusion
I thought this internship was an incredible experience and I wish it wasn’t coming to an end. I really got to experience the professional world of cloud engineering and the challenges it provides. I got to witness the immense amount of collaboration and communication it takes to keep these complex cloud environments running smoothly. With so many intricate projects throughout the globe, Maximus relied heavily on communication. We have meetings every single day for something or another where we discuss where we are in our tasks, what we need from who, who we need to do what, etc. Many of these meetings consist of twenty+ people.
I realized how much constant learning goes into this field, even people who are Principal Engineers are constantly learning just to keep up. We are running a marathon, not a race. We have to keep up this level of drive and determination for decades to stay relevant and continue making money. Whenever a new technology comes out, I want to be one of the first to dive into it. Or if there’s a difficult piece of tech like Kubernetes, I want to learn it to become more valuable. Your credentials get you in the door but you really need skill to last. You will be found out quickly if you don’t have any of the skills to back up the credentials.
I wish I would have done more internships or had started doing them sooner as I feel like I learned so much in my short amount of time here. I see why ODU requires the internship to graduate. They should probably require two of them.
I will try to do another internship before I graduate, if this one doesn’t get extended. I found it to be so beneficial to be in a professional setting of my choice but in a learning capacity. I wasn’t expected to produce but observe and learn. Eventually, I was given more hands-on tasks but I still wasn’t expected to produce results or know everything. I will view the remainder of my college time at ODU in a completely different light. I feel like I’m ready to move on to the next step, instead of taking more classes. I’m glad I only have one semester left because I want to get into the professional world and get my hands dirty.
This showed me how classroom theory is just the starting point for problem solving in the professional world, while it is necessary, there comes a point when you need to put the theory into practice and that is what I have been missing this whole time. Even though I have a home lab and tinker around, nothing compares to the real thing, and being able to learn without the pressure of producing like a full-time employee was eye-opening.
I think this internship experience has been pivotal in my professional path. I got to intern in the position that I wanted to end up in so I got to see firsthand what its like. I will say that after this internship I have changed my desired role to Cloud Security Architect. I want to be the one writing the Cloud Formation Templates and designing the infrastructure, not just making sure its operational. I want to be a designer, not a user, or worker. I like working with the technology and its necessary to understand how it works in order to design and secure but I want to move up a level.
I think it was so important to get in there and see what it’s really like because I was able to identify what I would like and what I would not like about the job. I realized that what I thought of as a Cloud Engineer is more of a Cloud Architect. I was wrong in what I thought they even did.
I’m forever grateful for ODU and Maximus for pushing me and allowing me to partake in this internship experience. I would recommend it to everyone ten times over. Do as many internships as possible, I wish I would have.