You grinded LeetCode, nailed the interview process, and got an internship at an amazing company. Congrats! But now it’s week three of your internship, you have no idea how anything works, and you’ve written one line of code in the past two days.
How do you ask for help? Whom do you ask for help? Should you even ask for help?
Working at Slack, I found that knowing how to navigate these situations and unblock yourself is essential to having a successful internship. Learning how to learn often felt more important than learning the technical material itself.
Background
 |
|
My project
- I interned on the iOS Application Infrastructure team. My project centered around the Mentions tab (also known as the Activities tab)
- I was tasked with changing the data provider for the Activities tab
- Before: data refreshed from an API call triggered by manual pull down, or 60 second timer
- After: use incoming WebSocket events with message data to update the screen, instead of waiting for the next API call
The first part of my project centered around adding listening for updates to message models associated with existing activities. The technical part of this project was not that difficult on its own. It still took me around half of my internship, though, because I was familiarizing myself with the codebase and — more importantly — learning how to learn.
The second part of my project involved adding a new data provider that streamed all activities from WebSocket events, and then combined it with the existing data stream. This was a much harder task than the first part, but because I had learned how to unblock myself, everything went a lot faster; I was never stuck for that long.
Hopefully, some of the things I learned this summer can help future interns get to that point earlier in their internship!
When to ask for help
The first step to knowing when to ask for help is learning that the industry is a completely different world than school . There is no cheating, there are no individual grades, there are no tests. Everything, especially at Slack, is collaborative. If it’s going to take you two days to fix a bug, but another engineer can tell you what’s wrong in two minutes, you ask for help.
The most important question to ask yourself when deciding whether to ask for help is:
Will I learn anything from spending more time on this?
Your job as an intern is to learn as much as you can. Sometimes, you will learn a lot from taking the time to step through a problem. Other times, you might waste a whole day in the debugger on a simple problem that can be solved with a one-sentence explanation from your mentor.
Types of problems you shouldn’t spend significant time tackling on your own:
- Formatting
- Syntax
- Which function to call to get a certain type of data
Types of problems you might want to spend some time tackling on your own:
- How a function you’re calling actually gets the data you need
- How changes in the state of a part of the app get reflected in the UI
The key difference between these two types of problems is the difference between knowledge and understanding. You should only spend the time to step through a problem on your own if doing so will leave you with a better comprehension of how things work.
Even if approaching problems by yourself can help you learn, sometimes you still might need help from someone else to move forward. This is totally fine! Apps like Slack are incredibly complicated, and interns are not expected to be able to understand everything by themselves. As long as you ask for help in the right way, there is nothing wrong with it.
How to ask for help
Ask questions that are straightforward to answer.
If you’re asking a knowledge-based question, this is pretty easy because there is normally one straightforward answer. For example, this is a question I asked at the beginning of my internship:
When you are blocked on a more complicated problem, asking the right question becomes a lot harder. I definitely had trouble trying to capture the complexity of problems while still providing a straightforward way for someone else to answer.
The first step that helped me was simply spending time trying to understand the problem. If you understand 95% of the change you’re trying to make, clarifying that last 5% is a lot easier for someone else to do than stepping through the entire process. In my experience, people are very willing to help you if it’s clear that you’ve spent time gaining understanding of the systems you’re working with before asking them for help. Sometimes, you’ll even answer your own question in the process of trying to understand the problem!
If you still need help after trying to gain an understanding of the problem you’re working on, the next step is to provide as much context as you can when asking your question.
This can involve describing:
- What you understand about the problem
- What you don’t understand about the problem
- What you’ve changed
- The expected behavior vs. the actual output
Instead of saying something like, “I’m having trouble implementing <feature>, can you help?” say something like, “I tried using <function> to implement <feature>, but instead of <expected behavior>, <actual behavior> is happening. Do you have any idea how to approach this?”
Another strategy for unblocking yourself is pair programming or calling with someone on your team. I would definitely recommend doing this as much as possible, especially for your harder problems.
Whom to ask for help
At my last internship, my manager was also the only other iOS engineer at the company. In other words, in 99% of situations the only person I asked for help was my manager. This summer, I found myself on a team of 14 people, all with knowledge in different areas. It was no longer straightforward to know whom to ask for help.
What I learned:
- Don’t be afraid to ask for help in a channel. If you don’t know who to ask, it’s much better to ask in a public channel than to DM half of your team until someone can help you.
- Don’t be afraid to ask your mentor or manager whom they think you should ask.
- If someone helped you with a certain area before, don’t be afraid to ask them for help on the same topic again.
Comparing two examples
Let me provide you with two examples from this summer. The first one is a situation where I should have asked for help earlier but didn’t. The other is one where I successfully took time to understand the problem before asking for help.
Situation 1
This situation is from the very beginning of my internship. For context, in Slack’s iOS app there are different data models for a Message and an Activity (aka a message that mentions you or a reaction to your message). For each Activity, we have an associated id that looks something like:
<channelId>_<timestamp>_<type>I was trying to change the activities data provider to listen for updates to any messages associated with activities. Messages also have a id, so I added a stream of Message models with the same id as the current Activity models. Unexpectedly though, the stream wasn’t returning any Messages. I stepped through the debugger for a while and eventually saw that in other parts of the app that used MessagesDataProvider, Message ids looked different; they all had no type and just looked like:
<channelId>_<timestamp>I wasn’t sure if this id discrepancy was from a mistake I had made when making local changes to Message data, or if it was because ids are different in Activities and Messages. At this point, I should have simply asked, “Are Activity and Message ids different?” to see how to approach this problem. Instead of asking a clarifying question, I jumped straight into finding a solution. I ended up using another Activity field messageIdentifier as the ID to stream Messages, which appeared to work.
The problem was that because I never asked a question, I didn’t truly understand why the ids were different, even though it seemed I had found a solution. Later on, I ran into a bunch of problems because when I started creating Activities from Messages, I copied all the Message fields, including id! This caused problems with duplicate activities, because I was writing the same Activity with two different ids (one with the type, one without).
It turns out, as you may have guessed, that Activity and Message ids are just formatted differently and I needed to convert between the two. I eventually clarified this by asking someone. However, I would have saved myself hours and hours of time if I had simply asked this question as soon as I saw the id discrepancy. This was a knowledge-based question and not an understanding-based question, so I should have asked as soon as I needed clarification. I’m glad this happened towards the beginning of my internship, because I was able to learn from it and be more willing to ask knowledge based questions in the future.
Situation 2
This situation comes from halfway through my internship. I had just finished the first part of my project and was starting the second part: adding the ability to stream Activities created from a different source (WebSocket events) than we normally do.
Based on a suggestion from my manager, I took a whole day just to write a document that explained exactly how data flows from the network request that returns activities to the UI in the mentions tab. Doing this gave me an immensely better understanding before I started the problem. Once I did start, I spent a few days implementing a basic solution that seemed to work from my tests. It was at this point, after gaining some understanding of what I was changing, that I asked for review on my changes.
The PR review came back, and it turned out that I did it completely wrong. However, because I had a solid understanding of the system, I immediately asked for help and joined a Huddle with two staff engineers on my team. We discussed the best way to approach the problem; it turned out that I had to write a new data provider for the activities tab that combined a stream of activities from the last API call with a stream of activities filtered on the last timestamp of the other stream.
This one Huddle probably saved me weeks of time that I would have spent if I had tried to just tackle the problem and create a perfect solution on my own. However, if I had asked for help before I understood the problem, I wouldn’t have been able to gain much from the call.
The takeaway from this situation is that you should try to find the sweet spot of asking for help: you should understand enough that other people can efficiently help you, but also ask early enough that their help saves you time.
Big takeaways
Learning how to work in the industry is as important, if not more, than learning the technical side of software engineering. I also found myself a lot less stressed when I became more comfortable asking for help. Once I became comfortable, I felt like way more of a team member than an individual engineer and had a lot more fun day-to-day.
My final advice is just to enjoy your time as an intern! Twelve weeks flies by and it really is such an awesome opportunity to be an intern at Slack. I’ve had an amazing summer and I hope any future interns reading this will too!
If you are interested in working on Slack’s mobile apps, check out our open roles!
Apply now
