My supervisor is a pretty great mentor. He is a computer/electrical engineer and is the lead engineer at the company. As my supervisor, he has been in charge of giving me my projects and providing any help when I’ve needed it. However, he has also gone beyond these basic duties. For example, he takes time each week to give presentations on any topics that the other interns and I might be interested in, even if they are not directly related to our projects. He has made it clear that he wants us to get more than just a line on a resume out of this internship, and so far he has certainly helped make that a reality. When coming up with a new project, for example, after finishing my first one, I was stuck at a crossroads of what type of project to choose. One option was to do a project that was similar to the first, was directly related to the type of software position I applied for, and had the greatest impact on the company. The other option was more data science related and working with AR technology, both things I’ve had an interest in learning about. My supervisor actively encouraged me to try the second option, and ultimately helped me come to the conclusion that that would be the best option. He offered the advice that having an internship where you are solely doing one sort of task, and solely developing that single skill can be good, but that is not really what internships are for. Internships are, in large part, for getting experience in fields you are interested in, and different sides of that field, so that you can compare these experiences with others and really see if you can see yourself choosing one of these as a career.
My supervisor also gave me some valuable advice that was a little bit more specific to software development and work in that field. While talking about different directions to take my new project, he wanted to know what my opinion was on the first project: what I liked and what I didn’t like. Part of my answer was about how I didn’t get much enjoyment out of the strictly coding and debugging parts, but where I did find enjoyment was where I saw that I was creating a new feature in and of itself and where I needed to figure out how to make this feature a reality. I had also mentioned a little concern about what it might mean if I am not thrilled by the idea of strictly coding, debugging, and designing a software architecture. He explained to me that he often categorizes programmers into two pools: those who love to code for the sake of coding, and those who love to be able to use coding as a tool to create a larger project. He assured me that neither is better than the other, and both are completely relevant within the field. However, understanding which side you are more comfortable with is a very valuable piece of information as you continue in your career, and something it would be better to discover earlier rather than later. My supervisor has been great in giving me the opportunities and information to help me figure this out.
He is also a Michigan alumni, so GO BLUE!