Summer started, class was over, and I had begun a 10-week journey with Credit Karma. Intern life was great: there’s free food, a foosball table, the sights and sounds of the city. However, the main point of an internship is to solve a problem, and in order to solve problems, you need to know how to ask for help. This is especially true when you’re entrusted with a meaningful problem and get ownership of the project, like we did at Credit Karma.
Making the mental switch
As a computer science major in school, I solved problems; during my internship, I also solved problems, but there were critical differences between those problems. At school, your assignments are usually something that other students have done before, one that your TAs and professors know well. In the internship world, your project is hopefully something novel.
In my case, I worked with my fellow intern, Luba, on sending push notifications to the browser, aka Web Push. You can read more about our project in Luba’s blog post. We were excited because not only was this an important project, but it was also a first for the company. We got a star engineer as a mentor and got to learn right alongside the team. Web Push involved setting up a service worker, something that nobody had done while at the company outside of hackathon projects, as well as a lot of other frontend and backend development.
School assignments are often just a standalone, one-and-done affair. Internship projects, however, are integrated with the larger codebase, delivering long-term benefits to the company and its members. As work is different from schoolwork, the questions that you ask and the answers you get during your internship will be significantly different than the ones at school.
Jumping into an internship
The first days of my internship were a whirlwind of events; I needed to quickly understand the Credit Karma infrastructure, my team’s development process, as well as various tools to help me work productively. My teammates gave me the steps to setup stuff, and the docs had information on tasks that people thought worth documenting, but those weren’t perfect. Given the rate of growth at places like Credit Karma processes are bound to change and docs may become stale. In this case, it’s necessary to notice the problem and be willing to ask for help.
The first few weeks are a great time to ask for extra help. Remember that no one – not an intern, nor a senior developer – knows everything about how the internal tools work on their first day. When I set up my Scala project, a lot of text in my IDE (code editor) was in red; the syntax highlighting and code analysis weren’t set up properly. If I hadn’t known that these were very useful tools I would’ve spent much of the internship with a half-functional IDE. One great way to find out about these problems is to shadow your teammates, like I got to do at Credit Karma. Observe their workflow and what tools they use. This is instrumental not only in showing you how to be more productive, but also in helping you learn language features, what tools you might be missing out on, etc.
I learned a lot during my internship, especially about the value of asking for help. Here are a few tips.
Tip #1: Know when to ask for help
There are many considerations when asking for help internally. First, be aware of the channels that are available. I had coworkers who sat beside me and countless Slack channels to turn to. However, there were also people outside my team who were willing to help when things were more nuanced or time consuming. In order to get the help you need, you must be able to skillfully navigate the various communication channels while making sure to not overburden others. However, the flipside of never asking for help doesn’t benefit anyone. Knowing when to ask for help vs. when to spend more time on a problem is a great skill to hone. My advice is to go for help when you have worked for an hour with no progress, and do not foresee progress happening soon.
Tip #2: Context is key
Another consideration is that teammates need some context around the question to answer it. Back in school, I was a TA for CS 107 (Computer Systems and Organization), and I answered students’ questions both in person during office hours and on Piazza web forums. In that class, students would just say “I am not getting the right result in case X.” They were, rightfully so, counting on fellow students and TAs to have context. In that case, the other students are working on the same problem and the TAs are expected to know everything about the problem (and have also answered the previous 10 students’ questions on the same assignment).
In the workplace this is not always the case. There were many times when I learned the importance of giving context, especially since Web Push was a new endeavor. A few weeks ago, I was asking some coworkers where I should host the the service worker frontend code. One developer suggested hosting it through the Credit Karma CDN, not knowing that service workers need to be hosted from the same domain. People in different parts of the organization work on different parts of the codebase. They may not know your problems as well as you do therefore you should give them some context. Only with the proper context can a teammate effectively answer your question.
Tip #3: Pay attention to the troubleshooting process
It’s helpful to realize that coworkers don’t always have all the answers. Different people specialize in different parts of the codebase, be it different parts of the stack, different products, or even different parts of the same product. Even if their work is related to what you are doing, they might be stumped and that is totally fine. I was having trouble importing a build package into another package. I went to my coworker for help. Initially, we were using our internal build tools built on top of Webpack and he asked another engineer for advice. That engineer advised that we use bare Webpack instead of the team’s wrapper around Webpack. We did that and continued to try various other things. After two hours of wrangling with the issue, my coworker had to transition to work on something else so we shelved the problem.
Even if someone doesn’t solve your problem, it can still be a great learning experience to observe their workflow. You can learn how to debug a program or properly find docs. Pay particular attention to the keywords that your coworkers use. These keywords can help you explain the problem to other coworkers and guide new internet searches. In my case, I noticed that my coworker was tinkering with the configuration of Webpack. Therefore, when I decided to do more searches the next morning, I used “Webpack” as a keyword. After a few searches I was able to find the instructions on how to export a node package as a library, and gained the knowledge to solve my own problem. I learned from my coworker’s troubleshooting process and now can use that same process in the future.
It adds up to a lasting impact
An internship is a learning experience. GitHub issue write ups, StackOverflow questions, and the like are all good resources, but these resources need to be augmented by your teammates. During my internship, I was able to help develop the frontend and some backend code for Web Push, allowing us to give tens of millions of members timely notifications that could help them make financial progress, like saving on a car loan or knowing when a hard inquiry has occurred on their credit. Without all the help and support from my team and the rest of Credit Karma, I wouldn’t have been able to build this in the timespan of my internship. Development is truly a team experience; we build better products when we work together, so remember to ask for help!
