Question Frequency as an Intern
Hi Taro Community,
I am a software engineering intern at Meta. I carefully watched your amazing video series about asking great questions. Even though manager notices I am able to unblock myself, I just received midpoint feedback that I am asking too many questions and need to be more independent.
- How should question-asking frequency evolve throughout the internship? I believe it is expected that interns ask very minimal questions during the last 3-4 weeks of the internship, but am not sure.
- How much weight does each performance axis contribute to the overall rating? Is a slightly weaker performance in independence axis still sufficient to justify a return offer assuming strong productivity, coding quality, and communication?
- Manager notes that my questions have sufficient context, but I struggle to make technical decisions. I frequently approach other peers to confirm the validity of my technical approach. I was wondering if you had any suggestions on how to improve technical decision making.
Discussion
(2 comments)- 1a month agoMid-Level Software Engineer [E4] at Meta
In regards to the third point, I relate to the struggle. In my experience, the reason you're stuck is because you're still in the world of theory. And in the world of theory, you can spin in circles asking a million questions.
But once you move into the practical side, things change. Your questions get sharper because you're focused on actually building something, not just thinking about it. And when it comes to technical decisions, here’s what I’ve found works best: spend a bit of time thinking through the options, commit to one, and write the code. Just get it out there. Then, during the code review, you’ll get real feedback. People might say, “This is good, but here’s another way to do it,” and still approve it. That tells you there isn’t always a single correct answer. Especially as an intern, the kinds of technical decisions you're making probably won’t make or break the entire system. Most of the time, it’s just about trade-offs.
And if your decision turns out to be wrong, that's still a win. You’ll learn a ton from that. But if you want to get faster and better, the key is to pick one path, implement it, and then ask for feedback on actual code, not just hypotheticals.
- 0
a month agoTech Lead @ Robinhood, Meta, Course HeroHow should question-asking frequency evolve throughout the internship? I believe it is expected that interns ask very minimal questions during the last 3-4 weeks of the internship, but am not sure.
Question volume generally goes down over the course of the internship, but as I talk about in my question asking course, the question quality is far more important.
On top of that though, the last 3-4 weeks of the internship are wrap-up, so you shouldn't have too many questions by then unless your execution went poorly.
How much weight does each performance axis contribute to the overall rating? Is a slightly weaker performance in independence axis still sufficient to justify a return offer assuming strong productivity, coding quality, and communication?
I forget - Do Meta interns have official axes just for them now? I think all 4 of the ones you mentioned are very important with communication probably being the weakest. Independence is huge for an intern. The main thing I want to see from a strong E3 is that they don't need to be hand-held all the time. I imagine Meta's for independence is much higher now given the economic climate there.
Manager notes that my questions have sufficient context, but I struggle to make technical decisions. I frequently approach other peers to confirm the validity of my technical approach. I was wondering if you had any suggestions on how to improve technical decision making.
This is tricky as it's a spectrum. For really hard decisions, it's fine (expected even) for an intern to verify their approach. But for something small like how to name a variable or which class to put code in or whether to make a utility method, I wouldn't expect a Week 5+ intern to still need help on that (it would frankly be a bit annoying and it would hurt their perf packet for sure). At that point, I would expect them to just make the decision and have it get judged in code review.
It seems like you're able to come up with the approach but are being overly cautious about running it by people first. I recommend just writing the diff and seeing what happens. If you get pushback, make a mental note and see if you need to course correct back into the middle. But hopefully your diffs just land smoothly and you save the time you were using before to validate everything beforehand.
Related Course
Other Great Discussions
![Entry-Level Software Engineer [SDE 1] at Amazon company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Famazon_logo.jpg%3Falt%3Dmedia%26token%3Dff5f2302-08be-43bc-b7b1-d381ba508d99&w=96&q=75){kind=logo}
