Reality of an average college student trying to start their career. Part 3

What I have learned over the course of my journey through university for what it takes to start your career: Part 3

Well, on to the next part of this internships, the thing that every college student competes for, and how everything ends up compounding after the initial push.

The first corporate experience and everything that comes with it.

So continuing from the last post, I want to talk about my first internship experience, the metaphorical dipping of the toe into the pool, or in this case, at least to me back then, the ocean. Like I had mentioned in the previous entry, I got the interview for this internship through my friend’s dad referring me to the role. After all of the interviews and getting the offer, the days leading up to my first day were a mix of exciting and nerve-wracking, as I’m sure those of you who have worked as interns or are currently interns can relate to. I remember parking at the office and being confused about where to go. Luckily, a manager who was also showing up for the intern orientation day saw me and guided me to the building. Turns out I was the intern on one of his teams, lmao.

Getting to go through all of the intern orientation stuff was cool and all, but honestly, the most interesting part to me was the following day getting to log into the company laptop and meet my team for the first time. I guess for a bit more context, though, my main focus and skill set now are data engineering, science, and stats. This first internship was working as a front-end software engineer, so it was a pretty big shift, imo. I got to meet my team and my mentor. I had read a lot of horror stories on Reddit about toxic teams that didn’t really care for helping their intern, but my team was quite the opposite so far in all of my experiences; they are the best team I have worked with by far. I believe I am extremely lucky to have had a team with everyone willing to explain concepts and walk me through any questions that I had. Also I was my mentors first intern he has ever had under him so it was definitely a learning experience for both of us but he did a pretty good job all things considered.

To give a bit of an overview of the scope of the work for the team and specifically for me. The team worked on managing all of the front and back-end web development of the company’s website and all of the forms, services, and chatbot services that went along with that. I primarily worked on migrating from React to Next.js, creating new forms, fixing the logic of existing ones, updating components on the site, and working on an MVP for a new landing page. The tech stack I used was primarily React, Next.js, AEM (Adobe Experience Manager), and Adobe Target (for A/B testing). Not one of the tech stacks you hear about on LinkedIn from most people. Also, at this point, I had never worked with anything related to the front end. I knew what React and Next.js were, but nothing else beyond that (unless we are counting taking AP CSP in high school). But, the learning curve for JavaScript and the frameworks wasn’t even that bad; being introduced to my first real production codebase was quite an experience. One of the most intimidating moments of my life, a lot of the videos I saw that were day in the life or day-to-day work in tech mentioned how you will never really understand all of the codebase, really only the parts you frequently work on. It had never been so true to me until that moment. But after the first month and a half you start to get the hang of it by the end of my internship I felt pretty comfortable navigating the codebase and generally had an idea of where I needed to go to work on any ticket.

The internship for the most part went pretty well, at least I think so. It was the typical SWE work: have your daily stand-ups, look through your tickets, tackle 1-2 every couple days, make a pull request, and have my mentor look it over. If he likes it, then push it to the production backlog, rinse and repeat for the next sprint. The main things I ended up gaining were experience navigating a large code base, working with and coordinating with different teams, and actually being able to push things to production, so overall, a pretty decent experience. Sadly, though, at the end of summer, they announced that no one was getting a return offer, which sucked, but it is what it is. Overall, though, it was a great experience for a first internship at a mid-size company.

Moving to a smaller firm with more responsibility.

Moving on to my second internship experience, this was a much smaller company (<100 people). This company’s main product was selling and licensing data that they aggregated, so it was a bit more of a data-focused role than my last one. On paper, I was the data science intern, but over the course of my time there, I was more of a backend/data engineer, really, which I didn’t mind; I mean, it’s all helpful in the journey of becoming a true data scientist.

When I joined, there wasn’t really a proper intern program; my boss just threw me whatever projects were deemed important to him and the company at the time. So one of my first tasks was pretty straightforward: it was data validation. We had a couple of data sets that contained personal information of individuals and their various contact information. This data had poor accuracy for the contact info, so I just had to write a script that would run a couple of APIs to validate the various contact information fields for each record. An important note for all of this going forward: all of the data and most functionality were built and run on the company’s on-prem servers; there was no use of the cloud, which was the biggest change compared to anything else I had done before. So after running and testing the scripts and deploying them to run each time any of the data sets were updated, and after they updated the status of all of the new records and any changes to existing ones, the accuracy was able to be brought up. I would say that my first task was a decent success; after this there were a variety of other tasks I worked on for the next few months, nothing worth really talking about.

Then, about 3.5 months into the role, my boss had a new project for me, which was creating a new API solution that would replace our existing one. On paper, this sounds pretty rough, in my opinion, giving an intern a project of this scale and responsibility (it was rough). To give you a general sense of the existing solution I would be replacing, it went down like this: so, like, each time a customer made an API call, it would go through some middleware, then make its way to a data warehouse, think of Snowflake or Redshift. Then once the warehouse would spin up and find the record or records, it would then go through the middleware again back to the user. The whole process takes 5 hops for each API, and it would end up taking 3-7 seconds, which, in terms of an API, is an eternity. Some customers were beginning to be frustrated with this solution. So my main job was to find an alternative, reduce latency to be sub-second, reduce cost, and scale it to be able to handle a far larger volume of calls than it could currently handle.

This was a huge jump from my previous role, where I had a highly defined scope and tasks already given to me with a mentor I could consult if I ran into any issues. For this project, I had the responsibility of finding possible solutions, making architectural decisions, and actually building the solution and deploying it all without any other developers to work with. In my eyes, a true David vs. Goliath moment. I’m not going to get into the nitty gritty of it all, but to give a general overview of the approach I took. I went with Supabase for a variety of reasons, the main ones being authentication built-in, user management for email and passwords, social logins (OAuth), auto-generated APIs based on the DB schema, edge functions for serverless code execution close to the user using Deno, and no vendor lock-in since it is open-source. So once I had settled on Supabase as a backend as a service platform, which makes my job a lot easier as a 1-man team, I reached my next hurdle, dealing with on-prem servers.

With all of our data being in on-prem servers and the company wanting to keep their on-prem stuff, I had to move the data to Supabase through an FTP server. This is all well and good, but then I had to consider, ok, once I move all of the current data over to Supabase. What am I going to do when there are delta files with updated and new records for each dataset being updated at different times, some weekly and others monthly? I thought about a few options and decided to go with doing the ETL using GCP. Why the cloud if the company wasn’t using it originally? Because it just seemed like the most efficient way to get the job done and provide an existing example of what could be done when the company eventually began to migrate more stuff to the cloud. So I made an ETL pipeline to process the various delta files received every month and containerized the ETL loaders to automate the file ingestion and have them trigger the pipeline to run only when there are file changes and not remain active otherwise, saving on cost. This ended up actually working out pretty well. There is some more work that was done, but this was the summary of the main things that were done: building and running the ETL pipelines with GCP, writing edge functions for tracking API calls, authentication, user management, reducing latency to being sub-second, and actually deploying it for continued testing.

This was the last thing I worked on before I resigned from my role with the company. Overall, it was an amazing learning experience being able to make all of these decisions and learn so much about building ETL pipelines, deploying and managing them, and how Supabase works and APIs in general. Now, would I ever do it again with the scope of the project expanding every couple of months alone? Absolutely not, but it was definitely something to talk about in interviews. I’m definitely thankful for the experience and hope the company can continue the project.

Compounding experience.

After these two internships, everything started to fall into place. I started to actually get callbacks from the internships and new grad roles I had been applying to. I spent a good chunk of February just interviewing. Honestly, it felt like I made it sure they weren’t the prestigious big-name companies you would think of, but in this job market, and going to a large state school felt like heaven. I guess once you get that first initial push, everything starts to come your way, a domino effect of sorts. I hope whoever is reading this has the same luck I did with starting their career.

What’s next for me.

The next time I’ll have a update on my career will probably be in around a month when I start my next role coming back to the company I interned with for the first time, working as a data engineer. I’m not sure what the tech stack is or the team will be. I’ll give some updates on the work I do and the tech stack there once I actually start. So no more career updates for now. I think the next post I have will be discussing my thoughts on the CitriniResearch Macro Memo and the potential scenario they pose for the future. Also I will make my first post regarding statistics its gonna be a bit of a cliche topic but I think its interesting.