My Undergraduate Experience

Where I Am Right Now

I am a computer science student, and most of my interests revolve around building things. I am especially interested in software engineering, artificial intelligence, and startups.

I have always liked taking an idea and trying to turn it into something real. Sometimes that means building an application from scratch. Other times it means looking at an existing process and asking whether it could be faster, simpler, or more useful. That curiosity is one of the main reasons I chose computer science.

My long-term plan is not completely set in stone, but I know I want to build at startups rather than settle into a traditional software engineering role at a large company. I am most interested in backend engineering and applied AI on small teams, especially when the technology solves a real problem instead of being added just because it is popular. I also want to keep working on my own products. Eventually, I would like to have the experience and judgment needed to build or lead a company of my own.

The values that matter most to me are curiosity, independence, and usefulness. I like learning how systems work, but I also want to use that knowledge to create something people can actually benefit from. A technically impressive project does not mean much if nobody needs it or can figure out how to use it.

Learning at Texas A&M

My classes at Texas A&M have given me the foundation I need to build more complicated software. Through my computer science coursework, I have learned about algorithms, data structures, computer systems, databases, machine learning, and different approaches to programming.

One change I have noticed is that I no longer think only about whether a program works. I now think more about why it works, how efficiently it works, what could cause it to fail, and how another person would maintain it later.

Outside the classroom, organizations and events such as TAMUhack and Aggie Coding Club have helped me stay connected to other students who enjoy building things. Being around other motivated students makes ambitious projects feel more possible. It is also helpful to see the different ways people approach the same problem.

Hackathons have been especially useful because there is not enough time to make everything perfect. You have to decide what matters most, divide the work, and produce something that can actually be demonstrated. That experience has made me more comfortable starting before I have every detail figured out.

I have also participated in intramural volleyball. It is not directly connected to computer science, but it has been an important part of staying balanced. It gives me a reason to step away from a screen and work with a team in a completely different setting.

My Internship Experiences

My internship with Dell Technologies has been an important experience in my undergraduate career. I have been working within Dell's Infrastructure Solutions Group on AI-assisted observability.

The basic problem is that large systems generate a huge amount of information through logs, metrics, and traces. Engineers can use this information to understand what is happening, but it can be difficult to notice the important signals before a problem becomes serious. My work has involved exploring how machine learning and AI could help identify unusual behavior, connect related signals, and detect possible defects earlier.

Before this internship, I mostly thought about AI from the perspective of building models or product features. At Dell, I have started to understand the extra questions that come with using AI inside a large company. It is not enough for an idea to work once in a demonstration. It needs to be reliable, explainable, measurable, and useful to the engineers who will rely on it.

I have also learned how much communication matters. I need to understand the technical problem, but I also need to explain what I am testing, why it might be useful, and what the results actually mean. This experience has made me more interested in AI, but it has also made me less interested in using AI without a clear reason.

Before Dell, I worked with Nuubi, an education technology startup. My work focused mainly on backend development. I built and improved REST APIs, worked with PostgreSQL, and helped with features involving authentication, user activity, and application data.

Working at a startup was different because the product and requirements could change quickly. I learned that a backend is not just a collection of endpoints. It has to handle invalid input, database issues, authentication problems, unexpected user behavior, and changes to the product.

Earlier in my career, I worked as a software engineering intern with Comal ISD. One of the most useful things I did was use Python to automate repetitive tasks. It was a relatively simple use of programming compared with some of my later projects, but it showed me how valuable software can be when it removes work that people previously had to do manually.

Each internship has shown me a different side of technology. Comal ISD was my first software engineering role and introduced me to building tools that solve real operational problems. Nuubi gave me experience with startup backend development. Dell has shown me how engineering and AI work within a much larger organization—and confirmed that I am more drawn to the pace and ownership that come with smaller teams.

Projects I Am Proud Of

Independent projects have probably taught me as much as any individual class. When I work on my own project, there is no professor telling me exactly what to build or what technology to use. I have to make those decisions myself, and I also have to deal with the consequences when I make the wrong choice.

One of my main projects has been Quoril. It started as a platform that used AI to help people find and evaluate online deals. I built systems that collected marketplace listings, processed the data, and tried to determine whether products were priced below their normal market value.

The project gained interest from potential users, which was exciting. At the same time, it exposed several problems that I had not fully considered at the beginning. External websites changed, search services hit rate limits, anti-bot protections blocked requests, and some data sources were less reliable than expected.

At first, these problems were frustrating because they slowed down development. Over time, I realized that dealing with them was part of the real engineering challenge. Quoril taught me that building a prototype is often the easiest part. Maintaining reliable access to data and creating something users consistently value are much harder.

It also taught me that changing an idea is not the same as giving up on it. Some of my original assumptions were wrong, so I had to rethink the product. That experience made me more willing to test ideas earlier instead of spending a long time building based only on my own assumptions.

Another project I have been developing is ShopLink. The idea is to give small sellers—such as home bakers, vintage sellers, handmade businesses, student sellers, and local vendors—a simple storefront they can share through one link.

While working on ShopLink, I have spent a lot of time thinking about simplicity. It would be easy to keep adding features until the product becomes a smaller version of Shopify. That is not the goal. The people I am designing for may only need to upload a few products, share their page, and accept payments.

This project has made me realize that design is not only about making an interface look good. It is also about deciding what the user should not have to think about. Some of my earliest designs included too many controls and customization options. Removing unnecessary choices often made the product better.

I have also worked on projects such as PosterArmory, Careerbase, Sniffle, and UltraVid. These have given me experience with mobile development, payments, external APIs, deployment, data processing, machine learning, and third-party services.

Not every project has turned into something I continued long term. However, each one taught me something that helped with the next project. I have become much faster at taking an idea from a blank folder to a working application. I have also become better at recognizing when I need to stop adding features and focus on whether the core idea is actually useful.

Skills I Have Developed

I have worked with languages and tools including Python, Java, JavaScript, TypeScript, C, C++, SQL, React, React Native, Node.js, Express, PostgreSQL, MySQL, Flask, FastAPI, Supabase, Firebase, TensorFlow, and scikit-learn.

More important than any individual technology, I have learned how to teach myself unfamiliar tools. Most of my projects have required something I did not already know. I have had to read documentation, study existing code, test different approaches, and debug problems without knowing the answer ahead of time.

I have developed the ability to break a large project into smaller parts, design database-backed applications, create APIs, work with external services, deploy applications, and troubleshoot problems across the frontend and backend.

I also earned the GIAC Foundational Cybersecurity Technologies certification. Studying cybersecurity made me more aware of how many things can go wrong when software is not designed carefully. Even when security is not the main purpose of a project, it still needs to be considered.

How I Have Grown

The biggest way I have grown is that I am more comfortable with uncertainty.

Earlier in college, I wanted to know the correct approach before I started. Through internships and personal projects, I have learned that there is often no obvious correct approach. You make the best decision you can with the information available, test it, and adjust when something does not work.

I have also become more realistic about the difference between writing code and building a useful product. A project can have a good technical stack and still fail because it solves the wrong problem, is too difficult to use, or cannot reach the people who need it.

This has sometimes been disappointing. I have spent a lot of time on features that I later removed. I have had product ideas that sounded better in my head than they worked in practice. I have also run into technical limitations that forced me to change direction.

At the same time, those experiences have probably taught me more than projects that worked immediately. I now try to treat setbacks as information. Instead of only asking, "Why did this fail?" I try to ask, "What did this show me that I did not understand before?"

The moments that make me feel most accomplished are often small ones. It might be finally fixing a bug that I have been stuck on, seeing another person use something I built, finishing a working version of a product, or understanding a technical concept that previously felt confusing.

Leadership

Most of my leadership experience has come from taking ownership of independent projects.

When I start a project, I have to decide what problem I am trying to solve, what features matter, what technology to use, and what should be built first. I also have to decide when to continue, when to change directions, and when an idea is not working.

This has taught me to be more decisive, but it has also shown me that leadership is not the same as always being certain. Sometimes leadership means making a reasonable choice, explaining why, and being willing to change it when new information becomes available.

I would still like to gain more leadership experience in larger teams. I want to contribute more to open-source projects, work with other student developers, and eventually help newer computer science students with projects and career preparation.

Where I Am Going Next

The different parts of my education are starting to connect. My classes teach me the fundamentals. My internships show me how those fundamentals are used in real organizations. My projects give me the freedom to experiment, make mistakes, and take responsibility for the outcome.

Before graduating, I want to improve my understanding of system design, distributed systems, cloud infrastructure, production machine learning, testing, and security. I can build applications independently, but I want more experience building software that must remain reliable as the number of users, services, and developers increases.

I also want to improve the nontechnical side of my work. In particular, I want to become better at validating whether a problem is worth solving before I spend months building a solution. I want to get more comfortable speaking with users and explaining technical decisions to people who do not have a computer science background.

My capstone project will give me a chance to work on a larger project with a team over a longer period of time. I hope it helps me become more confident not only as a programmer, but also as a teammate who can communicate clearly, accept feedback, and follow through on a shared goal.

After graduation, I plan to pursue roles at startups or continue building my own products. I am most interested in backend development, applied AI, and early-stage teams where the work has direct impact on the product. Even when a project does not become a company, the process forces me to learn new skills and think carefully about what people actually need.

I know that my career will include setbacks. Projects will fail, interviews will not always go well, and some opportunities will not work out. I want to respond by figuring out what I can learn, making the necessary changes, and continuing to move forward.

When I look back at my time at Texas A&M so far, I do not think the most important result is the number of programming languages I know or the number of projects I have started. The biggest change is that I trust myself more when I face a problem I have never seen before.

I may not know the solution immediately, but I know how to begin looking for it.