What is the ideal time required to get properly settled in the team and working with autonomy?

If you have the right support, then 6 months. If you need to figure out most things on your own, 8-12 months.

How long it takes will depend on the level of support you get and the complexity of the project. I'd take the feedback at face value and take the time to evidence that you've done some work independently before asking for help.

When it comes to sharing your ideas it might help to phrase them as questions. "Could we approach it this way .... I think it could offer these benefits .... or address these challenges .... What do you think?"

Good questions - Lots to unpack here!

Onboarding Expectations

I mentored tons of E3 at Meta (entry-level, mostly newgrad engineers), and this is the playbook I held them too:

• 3 months: Able to land code on time with moderate hand-holding - Moderate means that every task requires at least 1 question where I have to divulge a large chunk of what to do.
• 6 months: Able to land code on time with minimal hand-holding - For every task, they can get 90%+ of the way there, but they will need help covering a tricky edge-case or something.
• 12 months: Able to land code with effectively 0 hand-holding while also returning value - I can give them tasks and not worry at all about them turning it in on-time with high quality. And when it comes to returning value to the team, it generally comes in the form of reviewing other people's code.

An E3 task should be of low to medium complexity, which is 1 month or less by Meta standards.

However, Meta moves faster than 99% of tech companies so take this with a grain of salt. For most companies, you will need to slow this down anywhere from 25% to 50%.

I recommend these other discussions as well:

• "What does it mean to not require handholding anymore?"
• "How can I work better as a junior dev?"

Should You Ask More Questions?

Yes.

You have already gotten the feedback that your questions are high-quality. Keep asking them - You don't have much to lose. On the flip side, you have a lot to lose by not asking them, which is staying clueless forever. 😂

On top of asking good questions, I recommend doing the following:

• Extract maximum learning from each interaction - As someone who's more often been the senior engineer providing help, it is actually kind of annoying when a junior engineer asks me for help, I help them, and they come back 5 minutes later with another question (breaking my focus) as there was an adjacent question they forgot to ask. Here's a good video on how to NOT do that: How To Actually Learn Software Engineer Skills
• Thank the helper deeply - Make it feel like it's worth people's time to help you. The most basic form of value add is to effectively show your gratitude, which we talk about in-depth here: How To Build Work Relationships Faster - Giving Deeper Thanks
• Ask in more public forums - At Meta, we used Workplace, but most companies don't use it unfortunately. For you, try to ask your questions in as big a Slack channel as possible. If it makes sense, document the learning you got in a wiki so you generate a long-lasting artifact that survives past the 1-of interaction.

How To Properly Share Your Opinions

Another pointer was how to be assertive in the sense I tend to be scared to share my ideology or idea about how we can potentially do something. Communicating with peers also seems intimidating especially Senior or Lead members or Manager too.

Nobody wants to be mean to the junior engineer (and if your EM/TL is happy to do that, you should probably leave the team).

If you have an opinion on something, just share it. And use tentative language and other critical communication techniques to make sure it's received well. Check out my Effective Communication series to learn more: Alex's Guide To Effective Communication

Here's some other resources that may help as well:

• "How to be more assertive in workplace?"
• "I struggle to come up with things that add value to a meeting - What do I say?"