I would say that asking many questions and looking for "hand-holding" are 2 very different things. I think senior engineers should ideally avoid looking for "hand-holding", while it's definitely expected from them to ask a lot of questions (and not only when they are new).

I would recommend asking for a follow up the person who provided you this feedback about "being more independent ":
1. How much time do they expect you trying to figure out the answer by yourself prior to asking for a help of your co-worker? E.g. I recommend trying to spend 30 mins researching by yourself before asking questions in my Org.
2. What is the best way in your Org to get answers on your typical questions? E.g. it could be recommended for you to first research Confluence pages, DesignDocs and also avoid asking questions in 1:1 fashion and use shared resources like corporate StackOverflow or public help channels dedicated to your topic.

Senior Manager at Zoox; Meta, Snap, Google

Igor Podkhodov

There are good answers already and I would just add my 2 cents that could be useful for such situation:
1. Don't compare yourself against people who joined before you. And most of the companies also don't calibrate engineers of various tenures against each other.
2. Everyone has their strengths and weaknesses. And one of the leader's responsibility is to find appropriate tasks for each person on their team to utilize their strengths and cover weak areas. 

So I would recommend chatting directly with your manager, express your concerns and ask for a feedback + advice to get over them.

I would recommend focusing on being available and productive. This might mean that you need to work at night in your new location, but that's what I was usually doing. Otherwise, it's usually better to take a few days off instead.

And I think being available and productive for your team is more important than your location, but please check this out with your manager to be 100% sure ;)

I think Alex brought great points and I would also recommend sharing your concerns with your manager. They could give great advices being aware of the specifics and the exact people in your team.

In addition I recommend spending time building relationships with your peers, building informal relationships (by being genuinely interested in them), asking them if there is anything you can help with (in 1:1 fashion to be more genuine) and also sharing things you became great at (e.g. via tech talks or even simply by improving your team's documentation).

I don't know your exact situation, but I can definitely recommend a wonderful book on this topic. It's called: ["Radical Candor"](https://www.radicalcandor.com/the-book/)!
And it basically says, that people are whether too kind to provide a constructive and direct feedback or too harsh to demonstrate enough care... 

So your manager probably wants you to learn how to be more direct and provide constructive feedback, but without becoming too harsh on people. And this book can help you to become a little bit better in this.

I would also recommend asking your manager for a mentor within the company who they think could be a great example of not being "too kind".

It's great that you already recognize that it's an unique opportunity for you!

I also was constantly learning from such events. Here is a list of my favorite questions (just for the inspiration):
1. What are the top priority issues in your Org I can help with?
2. Is there anything about my teams that you want to understand better?
3. How would you describe the ideal engineer 1 level above me?
4. What advices will you give to yourself at my point of your career?

But overall please consider using your own ones, since it depends on the exact goals you want to achieve for yourself.

I would recommend being proactive and utilizing your passions. 
For example, I saw people who organize regular team lunches, bring fun staff to team's happy hours (or start holding them with boardgames), schedule offsites or just randomly spend lunchtime with others.

Cooler conversations you mentioned are also good to build informal connections with your peers.


However, to actually boost your career it's usually better to start managing up. First, try to understand, what are the top priorities of your higher management. They could be team spirit (then all the above is great) or could be pretty technical ones. 

Usually solving top problems for your Manager (and their Manager) is the most reliable way to boost the career.

Alex and Rahul definitely touched on the most important topics to tackle during skip level 1:1s!
I would only add 1 more potential topic and 1 concern from my side.

Topic: how would you describe a great engineer at my level at my team and what will it be different to be a successful engineer at the next level at my team?

Concern: I recommend being very careful when you complain about your manager to your skip-level.
  - If you have a great manager and just see a growth area for them, then it will be much better for both of you to deliver this feedback directly to your manager (in a polite and caring manner of course)
  - If you don't have a good manager (from your point of view), then it would be still better to deliver your concerns to your direct manager first. Also consider keeping shared notes for 1:1s with your direct manager. And if they don't deliver even on the written notes you both track, then it could be a much more productive conversation with your skip-level (starting from sharing about your efforts to improve the relationship in 1:1 manner and following on the specific areas that are mentioned in your doc, but are still lagging). 
Also it's important to mention, that your direct manager most likely has weekly 1:1s with your skip-level and it's in your interest for them to have a good rapport. So coming with complains can deteriorate relationships between you and your direct manager + between your direct manager and their manager which can often limit your own career opportunities. 
So I would say that such approach should be the last level of resort and building trust with you direct manager could serve you better in a long-term.

Rahul definitely mentioned great points! TeamInsights is a great tool in Meta where you can personally compare how your work stats stay in regards to your peers. And definitely it's not recommended to be below team's average unless you have a very specific reason for this.
And one more point I wanted to add is availability. Managers in Facebook don't know (and honestly don't usually care) when you are in front of your computer and when you walk, go to gym or do surfing. But they do know if someone complains about you being unavailable during work hours..

Overall it usually depends on a specific company. E.g. in most of FAANG companies it's pretty easy to switch between different teams and even departments. However in other companies a lot depends on the leadership.
I would recommend to start chatting with people you trust within your current company. And if you were able to build a good relationship with your direct manager, that could be the best opportunity to discuss where you want to grow into your career.

Good point, Alex!

I would add that if you have a really good relationship with your manager, you can ask them for a career advice. And you can let them know in advance that next 1:1 you want to dedicate to your career plans and listen for their advice.
And then take your time to prepare for it. E.g. outline all the reasons that make you thinking about leaving the company and all the things that you want to develop in yourself in the future. 

I would say that having a really great manager is a lot and they can help you to find the things you need in your current company/team or maybe even give some valuable advices about potential opportunities elsewhere.

Alex and Rahul mentioned really great points here.
I would only add that there are a lot of great resources on Android and I personally learned it within couple months completely from the scratch just building my own apps.

And these days Google itself provides free and easy-to-follow codelabs that can help new developers to learn Android within a couple of weeks. E.g. I would recommend starting from [this basic one](https://developer.android.com/courses/android-basics-kotlin/course).

I would say it depends on the team (especially at Meta). E.g. when I was working in their AR department, managers were asked why don't they promote E3 engineers doing a great job during their 1st half at Meta. 
So I would say it's impossible to come with specific times. 

Meta is focused on business impact and once E3 is capable to independently drive it on their feature level, deliver on time (according to their own estimates) and with a high code quality, they are usually promoted to E4.

Once E4 engineer is driving team-level impact (and not just delivers their features well and on time), they should be ready to be promoted to E5. 

And the same goes with E5 engineer who starts to drive Org-level impact. 

It definitely takes more time to be promoted to higher levels, but this is mostly depends on the engineer itself (as well as their team's project complexity+impact). And also it's due to the fact that driving a larger impact usually requires building more relationships, driving more challenging projects and getting buy-in from many people/teams.

* It's important to map E2E testing effort into the end user's experience and measure the exact coverage of it, especially for critical user's journeys. You can start from checking the percentage of regression tests that your E2E automation covers and set the goal to fully eliminate a need in manual regression testing. And the ultimate goal would be to eliminate manual testing completely. I would say this is an ambitious goal, but many companies have it in their plans. Moreover, some of them even ship their products without manual QA with varying degrees of success.
* I personally believe that having a manual QA team is also valuable, but all of the bugs they find during testing should ideally result in extra E2E tests to prevent them happening in the future. This could be another evaluation of your E2E testing effort's success.
* Also any crashes and production issues are obvious candidates (and measures as well) into the automation test suite.
* Moreover, usually the effort to make critical E2E tests land-blocking (preventing any pull request to be landed into master branch until all the automation tests pass) usually pays off in the long-term with higher engineering productivity due to a stability of the main development branch.

* I definitely agree that we should focus on business impact when trying to evaluate any type of work. 
Another important factor is complexity. And ideally both of these factors should be covered in a package for Performance reviews to justify engineer's work. 

* Coming back to your question, impact for BE could be measured in terms of its influence on business. And usually there are internal and external facing BE project impact:
  * Internal: Saving engineering time by simplifying commonly executed tasks (like adding new functionality faster as you mentioned). 
    * This impact is usually measured in X amount of saved engineering hours per day/week/month. And this should be not a very precise answer - just a rough estimate in regards to the average time it took to add such functionality before/after the corresponding BE project.
  * External: Increasing product's reliability/decreasing latencies and e t c via more robust integration tests, bug fixes or refactoring. 
    * This impact is usually measured in its influence on the end users. E.g. eliminated Y% of crashes or decreased cold start time by Z%.
* I also want to mention that sometimes companies even put a special emphasis on BE projects. E.g. Facebook has a special axis for their calibrations called Engineering Excellence. So they expect each engineer to regularly spend their efforts dedicated to the projects in this area.