First Internship Lessons and FAQ

I spent over 6 months as a software engineer between my first and second years of university. There was a lot that went into this internship, including skills that I needed going into it, skills I picked up and lessons I learnt about myself and working as a software engineer.

Skills I needed going into it

Going into software development professionally for the first time, I had no idea what to expect - would I be typing on vscode for 8 hours a day? would I be designing new applications or inventing creative solutions with what I learnt from uni?

Controversially, I’d argue that UNSW does a very poor job in equipping students with the skills needed for an internship in their first or second year. Every course is very rigidly structured and each assignment requires almost no creative thinking - for the sake of automarking there are rarely any components of the course that require autonomy and self-development. Even the most applicable courses to software engineering such as COMP1531 ultimately fall short in their ability to help students learn how to learn.

The most important things going into my internship was knowing how to learn and when to ask for help. I initially felt scared to ask for help and assumed that it was alright to spend a day trying to debug a big problem. However, the workplace is very different from university and for many problems, there are many people who have had the same problem before and can easily help out. After a few weeks, I became more comfortable asking others when I was stuck and not only did this help me learn, as more experienced engineers could explain the code I was struggling with in much greater depth, but it also made my development process much faster and allowed me to discover new tools to add to my skillset.

Learning how to use tools such as stack overflow, git and internal company tools is also an extremely important skill. There were many times when setting up my workspace that Visual Studio wasn’t working or some data I imported only my computer didn’t run. Most of these were very common problems that were only a few google searches away but knowing what to search for and where to look would have been difficult if I hadn’t already learnt these skills before starting my internship.

Skills I picked up

C#

I had never used any object-oriented programming language before this internship and I was worried that this would be a hinderance to my ability to code independently. My concern was valid and I did find myself struggling with different concepts such as overriding and overloading methods, and the differences between abstract and virtual classes.

What I realised was even though everyone on my team was really supportive, ultimately they had their own work assigned to them and it wasn’t realistic to ask them to spend an entire day on a C# crash course. Self-learning was the best way to go and there are a lot of important concepts related to inheritance and access modifiers that I was able to pick up simply from reading different bits of code and then searching up the terms that I didn’t understand.

What this showed me is that even though a computer science degree does not teach every single skill needed - sometimes not even teaching the coding language being used at work, it teaches students how to learn on the fly and pick up new skills that have foundations in what has been learnt. This meant that being new to object-oriented programming did not pose a huge hurdle and trying to code in it simply helped me add a new tool to my coding skillset.

Navigating huge codebases

One thing that is covered loosely in courses like COMP1531 and COMP2511 at UNSW is navigating through codebases with several different files and learning how to split different functionality between different files to improve readability and scalability. However, one thing that isn’t taught properly is how to code within a codebase that you’ve never seen before.

The first task I was given was to create a set of permissions for users to customise the application - it doesn’t seem like a complex task and would probably be a small part of a university assignment. This task took me weeks because not only did I have to learn how to use the product so I could find the file amongst the millions of lines of code in which to insert my code, but I also had to write tests for the code and its interaction with other features.

I spent days simply learning how to write different functions, run them and then see their effects on the product. Looking back on my experience, this was very tedious but super valuable and whenever I have had to navigate a new codebase in my own personal projects since then, I am much more comfortable opening different files, making small edits and debugging to find the underlying code being executed by different operations.

I don’t think there are easy ways to learn this skill besides manually going through new codebases and experiementing with the code. Without a job, it can be hard to find a large codebase, however, there are many open-source projects on github which can be easily downloaded and edited. For someone wanting to get better at this, I would recommend finding a topic you are interested in and have some prior knowledge of, and then downloading a similar project online and making changes to append your own features into it!

Lessons I learnt

About myself

One great thing about working in software engineering in my first year was that I got a taste of what it felt to sit down at a desk everyday coding different projects. Although I enjoy doing this at uni, I think the experience at work varies greatly depending on the team and the type of code being written.

Initially, I worked on a generic coding team that worked with a very specific application and my primary task was to look at a problem and the proposed solution, and write code to accomplish that proposed solution within a few days. Although this wasn’t as tedious when I got the hang of it, I think in general I would prefer to work in a role where I can use more of my own problem solving to achieve a task. I learnt a lot from working on this team simply because it gave me a taste of software development and a baseline for future rotations and internships.

Moving into a more specialised team - the embedded systems team - I realised that I was much more passionate about working in this team simply because I found the work more interesting and creative. Unlike the code I was previously writing, the code on this new team was much more complex and required several iterations of thinking, sometimes leading to realisations that another solution would be better and then spending some time learning how to implement that solution. This rotation showed me a few different things about my own interests, namely that I enjoyed embedded systems development a lot more than general software development because working with hardware as well as software provided a very interesting challenge and opened up a lot of intriguing possibilities for future development.

The experience I had on this team shaped a lot of my future decisions because I decided to take a subsequent internship at a company specialising in embedded systems, and took a course focused on machine learning on embedded systems a few months later. What this shows is that my preconceptions of software development were not completely correct and what I thought I was interested in led me down a completely different path than I initially anticipated. I think it’s important to try out a broad range of things and doing an internship with multiple rotations as one’s first internship is an excellent way to do this as these roles are focused more on finding different flavours of computer science rather than focusing on one specific area.

University and Time management

I decided to take a one subject workload along with my internship to ensure that I was still making progress towards my degree. I realised very early into the term that this would be really hard to balance. The best part of working in the holidays was that when the workday was over, I could put down my laptop and forget about coding completely. Unfortunately, once I started uni, I had lectures to watch, assignments to code, and labs to attend. This created a few problems with my schedule as I would have to find the time within my own schedule to commute to university and because I only took half a day off for studies, I would sometimes need to find an empty room to code rather than spending time with friends.

I think the four hardest things I found to balance when working while studying were:

1. Finding the time and motivation to work consistently each workday even when I didn’t get much sleep due to my other commitments.
2. Ensuring that I had enough time to go to class and watch lectures, while also saving some time for midterm and exam studies.
3. Maintaining a healthy life outside of coding, whether that meant going out after work or on weekends, and making sure I had enough time to myself everyday so that I was having fun outside of my work-uni life.
4. Keeping up my participation within university life - this was in the form of director and executive roles in clubs and societies, and also going to interesting events as I did before I started working.

I realised from this experience that one really difficult but important skill is to know my limits and learn how to prioritise the things that matter the most to me while knowing how to turn down enticing opportunities sometimes when I don’t have enough time to properly commit. I started off the year with a long list of different activities I wanted to spend time on but after a few months, this distilled to only the most valuable activities and meant that not only did I have more free time for myself but also more energy to commit to what I was doing elsewhere.

FAQ

When should I apply for an internship?

I don’t think there is a right or wrong time to apply - even if you don’t do one at all, this doesn’t disqualify you from getting a job after you graduate, and if you do want to apply in your first year of uni then the worst that can happen is getting rejected. Personally, I got rejected from so many different companies when I applied as a first-year and many companies don’t even read applications from students that aren’t in their penultimate year, however, there is no harm in trying. As I did try that, it meant I was able to reuse my previous resume (with slight modifications) and was already familiar with the process which made it much less time consuming this year.

What about pay?

I personally think that most tech roles should offer a minimum of $30 per hour because you are dedicating yourself full-time to your job and there are so many companies which pay well beyond that. While pay shouldn’t be a huge limiting factor because getting the experience of working in a tech role and understanding your interests is really valuable, be mindful that there is value to your time and you should be paid accordingly.

Uni while working?

I tried balancing university with work for about 6 months and can confidently say that it was not a great experience. I was barely hitting assignment deadlines and lost a lot of sleep trying to balance my work, uni and personal life. I’d say a workload of maximum one uni subject could be manageable if it isn’t a really heavy course but it’s much better to focus your complete attention on one at a time.