I would share my perspective as a vegetarian.

**Breakfast (rotation):**

- Overnight Oats or Muesli topped with different fruits.
- Whole Wheat Bread with chocolate peanut butter and fruits.
- Milk or Indian Tea with biscuits and dry fruits as starter.

**Lunch/Dinner:**

- Frozen parantha (Indian bread) and curd.
- Any vegetable/dal + roti (Indian bread) and curd.

**Snacks:**

- Tofu/Paneer with sauce.
- Instant Coffee or milkshake using premix.
- Lots of fruits.

Sr. Software Engineer at LinkedIn

Paras Sidhu

> I'll be actively pushing for a promotion

Will this performance review summary document be a promotion packet or a normal review where you would want to get an exceed rating to solidify your promotion case in near future review cycles?

Does your company have publicly available document examples for some performance reviews or promotion packets? If so, the document can provide answer to many of your questions. To answer your questions:

1. It *depends upon* your company or more specifically the org you are working in. Generally speaking, the review document should have details about your most notable projects with focus on the impact. Just to give you an idea, **LinkedIn** has 1500 characters limit on promotion packet. and no limit on normal performance review.
2. In general, I have seen that covering all the *competencies* is not required in performance reviews as long as you landed good impact on your projects. I have seen managers and reviewers focusing on holistic view of the candidate's performance instead of matching each point with a certain *competency*.
3. I would suggest including both: strong ones at the top followed by the good ones. Once you note down the achievements, you can compare them with the *competencies* required. If you see a \~80% fulfillment, you should be good to go. Otherwise better to reframe a couple of achievements or you can consider adding any minor achievement. *Overall, quality is the key*.

If you have good working relationship with some of your peers at +1 or +2 level, they might be open to help here. Having a glimpse at their document may help reveal the expected length of the document and in general the number of achievements to mention.

For example, I had a review document with relatively bad wording and was lengthy. However, I realized only when one of the engineers at +1 level showed me his document's first page as a glimpse.

To be honest, I don't have the right data points to answer this. But I will share what I have "heard" over the years. 3-4 years back, I heard from my friends that Google India asks relatively difficult questions than the US counterpart. But since Covid, the bar has reduced and is now comparable for both locations.

For Walmart and Target, while I am not aware of difficulty level in US, I have seen the interviews to be relatively much easier than FAANG. 1 of my friend bombed a round badly and still got offer from Walmart. I have few friends in Target and they say that interviews are well targeted towards the role you're interviewing for. Example: Android, iOS etc.

Two of my friends who went to MS in US had hard time getting interviews and offers. While in India, they were in relatively good company like Tier 2-2.5.

What kind of companies are you looking to compare with US/India? I can share my experience (India region) of couple of years back when I was interviewing for Android roles.

**SDE-2 in a popular food delivery startup:**

- Project round where they gave 2 hours to code a task. It was fairly simple specially given 2 hours.
- Easy-Medium DSA
- Easy-Medium System Design
- Medium-Hard bar raiser including Android in-depth and some DSA
- In-depth medium level manager round including product questions

**SDE-1 in a popular social networking startup (later revised offer to SDE-2)**:

- Easy-Medium DSA
- Medium level System Design involving in-depth Android questions
- Round with team lead involving medium level Android questions

**SDE-2 in a popular FinTech startup:**

- Similar to above

They probably rarely ask hard questions at SDE-2 level. Good amount of focus is on fundamentals. If you are looking for something specific, let me know.

I would post my thoughts in terms of AI:

- Overrated: Adding AI everywhere in the product for the sake of it and showing we are AI-first.
- Underrated: Finding the right area of the product to integrate AI by data analysis, experimentation and user-survey.

Assuming there is a doc (or 1-pager) where things are being discussed, can listing out the tradeoffs, pros and cons of each approach help?

Let's say there is approach A which you want to disagree with and have an alternate proposal of an approach B which is better than A. You can drive the conversations from the data points documented on why you disagree with A and why B is a better solution. Some high level pointers I could think of:

- how A might not be as scalable and how B helps.
- how A might incur more costs to the company or how B is more efficient in this.
- how A might be adding much more complexity to the system without adding any significant value.

Having a B approach should really help see why A is inefficient. In other case, it's sometimes hard to visualize the issues with 1 approach if we don't have a relative comparison. Backing of data will make your case strong.

Moreover, setting timeline to close out on the approach may help. If there is no timeline, the discussion may go endlessly.

I have been there, and I can assure you that it might be a good thing to feel "other people being smarter than me". That means there is a growth opportunity, and you have the right amount of motivation fuel to improve. With some practice, you would be far ahead of those "other people".

When I had "not good" problem-solving skills and felt "not smart", I tried some challenges on [Brilliant](https://brilliant.org/home/). They were fun and required good amount of logic + problem solving. I was on free tier and used to do the daily challenges. For some reason, now I am not able to see the daily challenges, but a quick Google search landed me [here](https://brilliant.org/100day2017/day1/) and I can see the free challenges.

At the same time, I kept up with Leetcode. Doing 2 problems a day, mostly easy ones. But I used to spend a good amount of time thinking of the solution. A few recommendations from my side:

1. Improving problem solving takes time and it's difficult to quantify the improvement, specially by yourself.
2. Spend more time on problems. If you are not able to solve, sometimes take rest, play games and the mind may automatically try to solve the problem in the background. Many times, it works and the solution "clicks".
3. A big factor in improving problem solving skills is consistent practice + rest + fun. This is what works best for the mind to be able to develop the mental models.
4. In 2-3 months, there would be a significant improvement in the problem-solving skills if you stay consistent. If you also face imposter syndrome, you might feel you haven't improved at all, but you definitely have.
5. For coding, try giving mock interviews. Problem solving is one thing but problem solving under pressure is another. It will make you a bit more habitual so that when the skills are really needed, you can pull it off.
6. I would recommend this highly rated course on Coursera: [Learning How to Learn: Powerful mental tools to help you master tough subjects](https://www.coursera.org/learn/learning-how-to-learn/home/info). Initially I used to think the more I study, the better. This course taught me otherwise. It helped me optimize the studies for greater results.

I hope it helps. Happy to answer any follow-ups.

Adding some thoughts over Lee's suggestions:

1. **Resources**: Android development is vast and fragmented. For a long time, Google has kept introducing new things and deprecating existing things. There are tons of content on the web, but I would recommend some hands-on with the [Google codelabs](https://developer.android.com/get-started/codelabs?text=java) starting with something [like this](https://developer.android.com/codelabs/build-your-first-android-app?hl=en#0). After this, you can start to have a look at your company's codebase to understand the common Views like ConstraintLayout, lifecycle handling, architecture components, networking etc.
2. **Iterate**: Android development is notorious in the sense that you need to handle a lot of things which may not come naturally. Like user rotates the screen (called configuration change), ideally there shouldn't be anything for the developer to do but you have to persist data and it isn't trivial. Get started with codelabs or small tasks and iterate on it. Learning all at once might be an overkill.
3. **Physical Device**: Android Emulator works just fine but can heat up the system and hamper the performance. Considering this fact + Android builds taking a lot of RAM, using a physical device for testing can provide significant speed boost.
4. **Use Github Copilot**: It can provide some productivity boost where the operation seems trivial like iterating over the list, creating a TextView, creating an adapter etc. You can simply comment your ask like the following. It will generate the boilerplate code which would save some time. It may not work in every scenario but worth giving a try.

```
// create a RecyclerView adapter
class Adapter: RecyclerView.Adapter<RecyclerView.ViewHolder>() {

  protected fun getView(@LayoutRes layoutId: Int, parent: ViewGroup): View {
     return LayoutInflater.from(parent.context)
                          .inflate(layoutId, parent, false)
  }
}
```

Is your company/team moving to Kotlin? As Rahul also mentioned, it's definitely a better choice for developers. If your team is aligned and you will be doing Android development in the long term, you can start with Kotlin as well.

**Fails:**

- I am trying to disambiguate a big project. While I brought a lot new discoveries, I was not able to make enough progress on one core exploration.

**Success:**

- Worked out for 4 days this week (target is 5 days but considering 4 also as success).
- For the discoveries I brought from the project I mentioned above, I was able to dig a bit deeper and come up with multiple proposals. This helped the team to not stay blocked and make progress.