Advice for someone looking to switch jobs to a Senior Engineer at tier II or tier I tech company?

This is a highly relevant, pragmatic question, but I think you're right it's too broad. Let me share some general principles that might help you, or others, depending on situation:

• Broader vs. Deeper. This is a classic engineering growth decision-point. Do you double down on something you're already very good at, to become one of the best, or do you branch out to become broadly useful? There is actually a right answer to this. It depends on two things:
  • Personality / Interest. Some people like mastery. Others like agility / adaptability. You should pick the path that fits you best. I, for instance, have always been a generalist, so I'm definitely better at Broad than Deep.
  • Company / Team Size. This often has huge impact. As a generalization, small companies need more generalists and large companies need more specialists.
• New Tech vs. Mature Tech. Web vs. Mobile is a great example of this tradeoff. Things have clearly gone mobile, and that's clearly where the future will be. Yet you're new to mobile, so your particular value as a mobile developer will be much lower, at least in the beginning, than your value as a web developer. At the same time, you don't want to be the last typewriter repairman in town. The question is when to jump — and jump you must.
• Sowing vs. Reaping. Your career should vary between periods when you sow (i.e. invest in yourself by learning something new) vs. reap (i.e. maximize your value by doing something you're great at). You never want to reap too long, because the gravy train always ends at some point. But you also need to acknowledge that when you sow, you should fully expect slower progress. In fact, it'd be an odd world if people tossed even more money at you whilst your learned a new skill. The lemma, of course, is that when you sow, you often have to take a step back (in pay, or in title, or in career velocity).

Though there's no way to debug your specific situation in a post, I'll leave you with this thought: remember that the question is never, "What is the right way for generic engineers to advance?" The relevant question is always, "What is the best way for me, in my situation, with my talents, with my interests, to advance?" The whole Temple-of-Apollo Know-Thyself business is really wise: you need to thread the needle between the principles above knowing your specific situation/talents/interests in order to make the right decision.

Lastly, also remember this — whenever a decision between two choices seems too hard to make:

• Don't be fooled by false precision. Some — well, most — parts of the future are unknowable. Squinting harder doesn't help. If two choices are too hard to differentiate, don't spend more time trying to tease them apart. Which leads to...
• Remember that inaction is as bad as action. Sins of omission are equally bad as sins of commission. There was an old lady who was proud to tell an interviewer she had withdrawn all her money just weeks before the Great Depression. When asked what she had since done with that money, she proudly answered that she still has it, all in cash. She withdrew permanently from the stock market — a sin of omission far worse than her lucky pre-Depression withdrawal. Not acting is acting.
• Many things are anti-fragile. That is, many things benefit from breakage. Whenever you're faced with a tough decision where acting leads to limited downside but potentially uncapped upside, you should always take that route. For instance, suppose you have a great reputation at a blue-chip company that will always take you back, and you consider leaving for a startup which might go bust in 9 months or might become the next $1T company, you should always leave. The downside risk is completely mitigated, while the upside is uncapped. A person who repeatedly makes that bet in life will come out way ahead.

At the end of the day, nothing can really beat true passion as the biggest motivator. If you love something so much that it doesn't even feel like work when you're doing it (this is the case for me when I build Android apps), you more or less have the ultimate productivity hack.

While the world has become mobile-first, web is still extremely important. There are still engineers who have incredible careers at "top tier" tech companies building websites. So a question to ask yourself is: What do you genuinely enjoy?

This makes this specific web vs. mobile decision tree fairly straightforward:

• If you have a lot of experience with web and you like it, then sticking with web sounds like a great option.
• If you don't like it that much, then you can experiment with mobile development - Building and publishing a mobile app from scratch is quite easy. If done at a good pace, this will only take a few weeks to a month and you will learn a lot about yourself in the process.

If you're going to go the Android route for mobile, we have a great thread about that here filled with tactical advice on how to become a master at it: "How can I get really good at Android?"

Here's some other resources that could help you with your career direction:

• "How do I know what I'm great at?"
• [Masterclass] How To Choose A Good Company And Team As A Software Engineer

Should I even care about doing side projects considering I have 10+ years of work experience?

To be honest, you generally don't need to care about side projects when you have this much experience - I'm sure you could continue having a wonderful career without doing a single project from this point onward!

However, I do believe side projects serve a lot of different purposes that make them potentially very valuable at any stage in career for any kind of software engineer:

1. Light-weight exploration - Most companies are rigid letting engineers switch teams and stacks, preferring to keep them in their already established domain of expertise. Side projects let you break this boundary and play around with whatever new tech you want.
2. Builds up versatile product skills - Software engineers are often silo-ed into the coding part, which deprives them of visibility into areas like UXR, design, and data analysis. By doing side projects, you own the entire product, so you will build this more holistic set of product skills. I talk about this more in-depth here: "How to develop product sense as an engineer?"
3. Gets job and networking opportunities - I grew my side projects to 3 million+ users combined, so I have gotten interview opportunities from Block, Instacart, Uber, and more top-shelf companies through them. If you open-source your code on GitHub, you give yourself even more opportunities to get lucky and get connected with awesome people, whether its recruiters or other awesome software engineers.

Since you seem to be an exploration phase, it seems like side projects can have a lot for value for you! One of the great things about side projects is that you're in complete control: If you spend a few weeks on them and you feel like it isn't working out, you can easily shelve them and invest your time in something more meaningful.

I have had so much fun building side projects, and I owe a huge part of my career success to them (they let me break into being a professional Android engineer!). I hope they can be helpful to you as well - Best of luck!

Thank you for all the suggestions.