5 Important Skills for a Software Engineering Internship
Starting your first job in software engineering can be quite intimidating. Whether graduating from a university, coming from a bootcamp, or being a self-taught programmer, the gap of knowledge between you and the full-time engineers at your company can be quite significant. As a current student at the University of Minnesota, and an intern at Punch Through, I’ve experienced this knowledge gap first hand.
Here are 5 important skills that I’d recommend building before starting your software engineering internship:
Understand Git and Github for Version Control
Before starting your internship, the most important technical concept to familiarize yourself with is Git. It wasn’t until I worked my first job in tech that I truly began to feel comfortable with using Git and services like GitHub. Note that Git and GitHub are not synonymous:
Git is a version control system, meaning that it tracks the changes made to a set of files over time.
GitHub is a service that hosts Git-based repositories (usually containing a codebase) on a remote server and provides an interface to interact with and edit them.
There are two main reasons using a service like Github is essential:
- To remotely back up your work
Although using version control is important to track changes and allow you to revert to old versions as needed, you’re always putting yourself in danger of losing your work if you store it all in a single, local place. When you’re coding, you’re making changes to the files in a local repository. When you’re ready to back up these changes, you should push the changes to the remote version of the repository on GitHub.
- To collaborate with others
In industry, you’re almost never the only one contributing to a codebase. GitHub allows multiple people to view and edit the codebase at once, and review each other’s code before it is merged into the main version.
Changes to a codebase are checked in in the form of commits. Each commit has an associated message that describes the changes within. These messages should be short, concise, written in imperative tense, and as specific as possible:
- Bad: Fixed UI bug
- Better: Fix UI update failure after user tap on table view
There are various conventions surrounding commit message formatting. Find out if your company has a preference and do your best to stick to it. Otherwise, Git’s best practices can be found here.
Branching is an important feature of Git that allows multiple people to push their changes to the remote version of the codebase simultaneously. There’s always at least one “main” version of the codebase, usually called the master branch. This branch is almost never directly edited. When you want to make a change, you’ll first create a new branch. This new branch is a copy of the current codebase, and initially only exists locally. All your commits should be checked into this local branch first. As soon as you have changes on your local branch, you should create a remote version of that branch on the remote repository and continue to push the commits as you make them so your changes are backed up.
When you’re ready to merge a branch back into the master* version of the repository, you’ll create a pull request (PR) on GitHub. A PR contains the diffs, or differences, between the master version of the remote repository and the remote version of your branch. One or more of your fellow engineers should review your code and make comments or suggestions before it can be merged. The codebase may also be integrated with tools like CircleCI, which can perform checks and run automated tests that must pass before you can merge.
* Pull requests can target any remote branch, not just the master.
Learn Agile/Scrum Software Processes
Another aspect of software engineering that’s important to get familiar with is software process models. Software process models aid in the process of software design and implementation. Agile, the most commonly used today, is a software process model that takes an incremental approach to software development based on these four values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The agile method is meant to be flexible and open to change, inducing more interaction between clients, engineers, and project managers.
Scrum is a common agile framework, meaning that it’s one way to implement agile methodologies. It’s also one of the most popular. Let’s break down some of the essential components of Scrum:
Project work is broken down into smaller tasks (sometimes referred to as issues or stories) that can be assigned to individual team members. Some examples of tasks include feature implementations or bug fixes. A new branch is typically made for each task, and once the task is completed, a PR is opened up for that task. To manage tasks, tracking software such as JIRA or Trello is commonly used.
A sprint, sometimes referred to as an iteration, is a recurring process in which a team designates a set of tasks to be completed within a predetermined span of time. Sprints are often one to two weeks in length and occur back-to-back — such that when one sprint ends, the next one begins.
The backlog is a list of all the tasks for a project that have yet to be completed. At the beginning of each sprint, tasks are selected from the backlog to be completed during that sprint. This is done during a process known as sprint planning. The flexible nature of agile means that tasks may be regularly added or changed in the backlog throughout the lifetime of the project.
Tracking software typically includes a visual representation of a kanban board. A kanban board is a tool that represents what stage of development the issues of a sprint are in (e.g., “In Review”, “In Progress”, “Completed”).
Daily scrums, or stand ups, are frequent short meetings where each team member discusses what they’re working on, and what stage of development their assigned issues are in. This time can also be used to discuss things that concern the entire team, like potential blockers.
Sprints typically end in some kind of review and/or retrospective, in which the accomplishments of the team may be presented to the client, or simply discussed among the team members themselves.
Working with Unfamiliar Code
It’s inevitable that you’ll encounter unfamiliar code during your internship. While working with unfamiliar code is a skill you’ll build up over time, here are a few tips to help you get started:
- Find examples in the existing code that are similar to what you are coding.
- Command F is your friend!
- Take time to understand existing classes, functions, architectures, dependencies, etc. that you’ll be working with while you code.
- Don’t dwell over code unrelated to your given task.
- Read documentation (e.g., library docs, README files, code comments, etc.).
- Take a test-driven development-like approach and start by understanding the unit tests and working backwards from there.
In addition to code, you may also find yourself to be inexperienced with the IDE, debugger, testing tools, etc. that your company uses. Take some time in the beginning of your internship to research these tools. Understanding your tools can lead to more effective and efficient development.
Asking Questions and Taking Notes
When beginning your internship, or even a new project, it’s nearly impossible to retain all of the information given to you. Taking notes during meetings is an important soft skill, as it’ll provide a reference point for later and also help you ask better questions going forward.
Tips for taking notes and asking effective questions:
- Don’t be afraid to ask questions! It’s expected that you don’t know everything as an intern.
- Try to prepare and organize your notes before meetings.
- Write down keywords, key filenames, classes, functions, line numbers, etc. as they’re introduced to you.
- Prep questions you have for your mentor(s) in your notes, so you can ask more specific questions when meeting with them. Even when you’re really lost, you can gain a lot more from being specific as opposed to simply sharing your confusion.
- Consider whether your question is contingent upon project knowledge or is something you can Google and research on your own.
Reflecting on Your Work After It’s Completed
Tracking what you’ve learned is an important skill that can help with future interviews, networking, and personal development. To get your thoughts flowing, start with a question or prompt. I try to set aside time to do this on a weekly basis.
Example Reflection Prompts:
- What went well?
- What could’ve gone better?
- What would I have done differently?
- What technical skills have I learned?
- What soft skills have I learned?
- What new concepts was I introduced to?
These are just a few of the skills and concepts that I found myself learning throughout my internship at Punch Through. Although engineering requires many more technical and soft skills than the five mentioned, I think these will likely apply to any company or engineering position. I hope you have gained some useful insight and wish you luck as you begin your career in software engineering!