Blocked: How to Ask For Help as an Intern

Unblocking Yourself as an Intern

You've cleared the interview bar and landed the internship. Now it's week three and you're staring at a codebase that might as well be written in another language. You've produced one line of code in two days. The critical skill here isn't technical prowess — it's knowing how to ask for help and who to ask.

Working on Slack's iOS Application Infrastructure team, I learned that navigating these moments matters more than mastering the framework itself. My project centered on revamping the Mentions (Activities) tab. Initially, data refreshed through pull-to-refresh or a 60-second timer. The goal was to switch to a system using WebSocket events to push message updates to the screen instantly, bypassing the need to poll for changes.

The first phase involved monitoring updates to message models tied to existing activities. That sounded simple, but the technical execution was secondary to the real challenge: getting oriented in unfamiliar territory. The second phase required building a data provider that streamed all activities from WebSocket events and merged that with existing data streams. That was far harder. But by then I had refined my ability to unblock myself, and I moved through it faster than the "easy" part.

Recognizing When to Ask

Industry work doesn't resemble school. There are no tests, no individual grades, and no cheating — everything is collaborative. If resolving a bug takes you two days but a teammate can pinpoint it in two minutes, you ask for help, period.

The heuristics are simple. If you can gain real knowledge — like understanding how a function retrieves data or how state changes propagate to the UI — spending time alone in the code has value. But if you're stuck on syntax, formatting, or figuring out which API to call, resolve it quickly through a question.

For the latter problems, you're missing knowledge. For the former, you're chasing understanding. Only invest solo time in the latter. Know the difference and save your patience for what matters.

Many blocks require input from others just to proceed — that's expected in a complex app environment. The trick is asking in a way that respects everyone's time.

Asking Better Questions

Make questions easy to answer. Knowledge-based questions often have simple, direct answers — a good candidate for an instant ask.

For more complex problems, spend time building context first. If you understand most of the change you're making, someone else can fill in the remaining gaps far more efficiently than walking through the details from scratch. Often that understanding yields the answer on its own.

If you're still stuck, offer full context: what you know, what you don't, what you've modified, and the expected behavior versus the actual output. Avoid generic pleas like, “I'm stuck on feature X, can you help?” Instead, lead with specifics: “I tried using foo() to implement this behavior, but instead of getting Y, I'm seeing Z — do you know why that's happening?”

Beyond messaging, synchronously pairing with team members helps on the hard problems. It's worth doing often.

Finding the Right Person

At a past internship, my manager was the only other iOS developer, so the answer to "who to ask" was trivially obvious. On a team of 14 people, though, expertise varies. Your time gets wasted hunting for the right contact.

Instead, ask in a public channel first — someone will know someone who can answer. Your mentor or manager can also recommend the right person. And if someone has helped you with a topic before, go back to them rather than starting fresh with someone new.

Two Mistakes

Early on, I worked with Messages and Activities, each carrying their own identifier. To enable streaming updates, I subscribed to Message models that shared the same id as existing activity ids. Unsurprisingly, nothing showed up. The debugger revealed a mismatch — my local Message ids looked different. I hedged, guessing that Message ids were simply formatted differently. Rather than verifying, I patched things over using another activity field as an identifier, and it appeared to work.

That shortcut bit me later. When I started generating Activities from Messages, I carried the Message's id along, creating duplicate activities with different id representations. The root issue was clear — those identifiers have distinct formats, and converting between them is expected. A simple clarifying question at the first sign of the mismatch would have saved me hours and irreversible design headaches.

Midway through the summer I encountered a different scenario. Moving to stream Activities from WebSocket events, my manager suggested I spend a full day documenting how network request data flows through the stack — right down to UI presentation. That exercise was transformative. When I eventually submitted a prototype for review, it was deemed fundamentally off-track. The difference between the first failure and this one was that no Huddle or explanation could have gotten me there months earlier.

I joined a working session with two staff engineers holding years of Slack platform context. Through that conversation, we sketched a solution requiring an entirely new Activities provider that merges API-sourced activities with a stream filtered on the last-known timestamp. Those focused minutes saved me perhaps three weeks.

Finding the Sweet Spot

Each of these experiences highlights one sweet spot for seeking assistance: understand enough so that others can help you effectively, but reach out soon enough that the help genuinely accelerates progress. Ask early for knowledge-based gaps, buy time for curiosity-driven understanding elsewhere, and lean heavily on your mentor to route you to the right people.

The comfort of working this way compounds. I spent my internship learning proper open issues can genuinely be collective work. At the end of your twelve weeks, that knowledge will matter as much as shipped code.