You definitely don't want to be caught in the "crossfire" between two engineers here. We all want the team to be harmonious and happy, but as an IC engineer, you should primarily be concerned with your project and the deliverables. 

Trying to appease multiple parties, or giving feedback on an employee's conduct generally does not help you (or the situation). Leave that to the eng manager. 

**You should address this insofar as it impacts the timeline and quality of the project.** One way to move forward productively is to propose how you'll prevent the same mistakes going forward. In your case, that could be: 

- A recurring meeting between the 3 of you to discuss progress or changes more regularly.
- A well-defined protocol (or just an agreement) on where the source of truth will live. 

Just having the conversations can often go a long way in soothing the tensions.

[Here's the masterclass on building relationships in tech, ](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/)for which communication is critical.

Tech Lead/Manager at Meta, Pinterest, Kosei

Rahul Pandey

Dumb question: **Why do you need to have pre-defined strengths?** 

You're putting a ton of pressure on yourself to have a brand in some way, but there's no need to have urgency around that. For the first few years of your career, it's totally fine to do your job well and focus on learning. As you learn and tackle larger projects, your strengths will become more clear.

This is similar to the advice I give folks who are struggling to find a passion. **Passion is an emergent property of doing hard work across months or years**, not something you stumble upon during your afternoon. The best way to "find your passion" is, ironically, to stop looking for it: just do impactful work on important projects.

Usually, the HR meeting is a formality and a way to get some data about competing offers or compensation expectations. 

The HR meeting rarely results in a change of outcome for an offer -- the technical interviews matter much more. This is especially true for larger companies like TikTok or Meta where they will be able to "slot you in" across multiple teams.

Overall, you handled the call well, by dodging the question about compensation expectations. No need to do anything now -- just wait for them to get back to you with next steps! If they don't get back to you within a week, **then** you can send a follow-up indicating that you have some flexibility on comp + level.

> Won't "not restarting services" lead to increased memory consumption at some stage?

Why do you think that? Don't invent problems: unless you have historical evidence of issues that have resulted from *not* restarting (either at GS or another company that is similar), I wouldn't worry too much.

Another framing I like is to "shadow" someone you respect on the team and basically make their life easier. The senior/staff engineers on the team will probably have more work than they can handle. Can you look at their PRs, their design docs, and their calendars to identify good questions, or simply provide some feedback? 

Once you develop a relationship with them, you'll have a lot more direction ("narrative") around this extra work you'll do.

Very much agree with Casey. freelance/contract programming gigs while you have a full-time job is difficult: lots of work and may conflict with your employer (especially if you're in Big Tech).

However, **teaching is a great side gig that can also be lucrative**. I was a contractor for Codepath teaching live classes, and I also recorded a course that was published on LinkedIn Learning. Since I was teaching people how to code, there wasn't any issue with doing these after hours from my day job.

Which company are you at? Can you navigate from your current role to an area that you think is a higher company priority? Or where you would work with smart people in the company? (who then may help you get a job later on.)

I'm confident that all the roles you mentioned (DBA, DE, DS, Data Architect) will have roles available in the coming years. I'd advise you to pick the one where you have an unfair advantage based on your network and skills. 

I wouldn't worry too much about showcasing your work. Worry more about making sure people can **benefit from your work**. The *byproduct* of this is that your work will get noticed. Some ways of doing this: 

- Provide helpful feedback on code review. 
- Write posts reflecting on what the team is doing well, or patterns you've noticed. 
- Organize a social event or hang-out session for your team. This allows opportunities to share your work in a more informal way.

I'd also encourage you to find a "body double" if possible. Someone to pair program with or a do a recurring 1:1 meeting. See the idea of an [accountability partner](https://www.jointaro.com/lesson/czwltSPj1pmYIlJUBMIk/not-getting-stuff-done-find-someone-to-call-you-out/).

Be explicit about what your goal is. Do you want users, revenue, or learning? Or did you just build it purely for yourself to help with your own interview prep?

For most devs building side projects, the goal is to **get users**. In that case, the vast majority of projects are lacking when it comes to UX. It needs to be *incredibly easy* for someone to understand how and why they'd use your tool. 

The reason most side projects fail is that this is traditionally not the "glamorous" part of engineering: you're not learning new algorithms or working with a cutting-edge API. You just need to do the hard work of writing good copy, reducing button clicks, color-coding the UI appropriately, etc. 

For your app, I'd really focus on the usability. A few things come to mind immediately: 

- Make the tap targets bigger. Right now I have to hover over the row in order to click “Open”.
- Color code the “next review” and make the time relative (“in 2 days”).
- I'm not sure what *title* refers to. Can you link it to a Leetcode problem? 

See the [masterclass about building side projects here](https://www.jointaro.com/lesson/OEuX0KMhcnNSTJ50Voee/masterclass-how-to-build-and-grow-tech-products-to-500k-users-for-free/).

Do some prep work before the meeting. You can probably anticipate some of the questions you'll ask during the meeting -- now ask those **before** the meeting to someone who knows the answer!

**Every meeting should have resources that you can dig into and learn about**. If not, ask!

- Attendees + agenda
- Running meeting notes
- Objective/decision of the meeting

You should also be selective about which meetings you care about. When you're new, it's fine if you can't prepare for every meeting. But pick a few that will be high leverage and look up the terms, look up the people, and look up any historical context. 

It's better to be fully in command for 1-2 meetings per week rather than half-heartedly know what's happening for every meeting.

- **Talk to your manager for an honest opinion about your influence (or lack thereof)**, and if that may hold back your promotion to Staff Engineer. You've made good observations about differences in behavior, but I'd like for us to validate if they are indeed problems. (*"If it ain't broke, don't fix it.")*
- **Start with the outcome you want**, which is to be able to answer questions for the team, influence team direction, and help others? Which projects would best allow you to do that? 
- **Observe which forums the other Staff Engineers are using most effectively**. Are they doing a lot more 1:1s, team meetings, group posts compared to you? (You should creep on their calendar, wiki contributions if possible!) I talk about this in the "[Talk & Observe](https://www.jointaro.com/blog/talk-and-observe-a-framework-for-engineering-onboarding/)" onboarding framework.
- 

For SWE roles, I think reaching out shortly after the interview with an update on the code is neutral. However, for PM roles, it's less helpful to reach out, to the point of **almost being detrimental**. 

PM interviews are about problem-solving and discussion. Since there's no "one right answer" when it comes to PM interviews, I don't think you get any extra points by coming up with a better answer *after* the interviews ends. I wouldn't overthink, just spend your time focused on the next interview!

A related question is about doing [some reflection on onsite interviews](https://www.jointaro.com/question/CdmrIsMFPFbsRqRUvueu/how-to-figure-out-why-im-not-passing-onsite-interviews/).

At Meta, there were frequent complaints internally about employees who got unwanted messages from candidates they interviewed. If the information is not directly presented to you as the candidate, your sleuthing attempts to guess the email may backfire.

If you're doing this for a cold outreach, this oddly feels more acceptable to me, but this method for landing a job has a low hit rate. Referrals are a better bet (see the [masterclass on networking here](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/)).

Definitely not expected or common to work 18 hours/day. As in, I've literally **never** heard of any team that does this.

Maybe it's for one night because an engineer was deep in a flow state, or perhaps one day during crunch time. But any kind of expectation for 18 hours/day would be ludicrous. 

Take action to increase your **luck surface area**. One of the best ways to improve your odds of getting lucky is to become top-of-mind when it comes to a job, topic, or other domain. 

Posting on LinkedIn consistently is one of the easiest ways for you to build that expertise.

For me, it led to valuable connections. Concretely, I was able to teach a LinkedIn Learning course back in 2021 due to the network I was able to create.

First, watch this video about [imposter syndrome](https://www.jointaro.com/lesson/dTSdd4ozp298jH3glvnx/overcoming-imposter-syndrome-you-have-so-much-more-value-than-you-realize/). It's totally normal (and expected!) that for some patches of your career, you feel like not enough. These feelings often come at transition points in your career, e.g. a new job, promotion, or recognition. 

One tactic I recommend is to better leverage 1:1s to get the detailed feedback and start to act on it. Here's the [masterclass about 1:1s](https://www.jointaro.com/lesson/FEK6JZqW2Jg3rdN9yeGn/masterclass-how-to-have-impactful-1-on-1-meetings/).

- You should definitely have a recurring 1:1 with your manager and talk about your feeling that you are not improving. Make sure this feeling is not just in your head, and others feel it too. (you may be surprised to see that your manager thinks you're totally fine!)
- Have 1:1s with other people on the team as well, e.g. your tech lead, peers on the team, and peers on adjacent teams. Be vulnerable with them and have discussions about your work and what you could do better. 1:1s are a time [to be awkward](https://www.jointaro.com/lesson/xjeFRpp5YHxG9TTK8wjn/1-on-1s-are-the-time-to-be-awkward/)!

I'd encourage you to be more structured in your reflection. When you say you don't feel like you're improving, are you saying that based on lines of code, experiments you've run, general vibes, or something else? When you have a metric or something you're tracking, you can start to actually measure it and focus on improving.

Finally, keep a [brag journal](https://www.jointaro.com/lesson/QVqPkuCvplbHSqBWtKJX/make-your-promotion-case-easy-keep-a-brag-journal/) to remind yourself of your wins!

At most major tech companies (FAANG+), the interview process **won't be that different** between a front-end engineer and a full-stack engineer role. These should all be common regardless of the role: 

- Technical phone screen
- At least 1 or 2 data structure and algorithm (DSA) questions
- At least 1 system design interview if you're interviewing for a Senior+ role
- One behavioral/project-based interview. 

The differences will be in the last 2 categories: 

- The system you design will be about your frontend domain expertise. e.g. for Facebook, they asked me how I'd implement the Newsfeed with various view types. 
- The project-based interview will be about implementing some user interface, discussing best practices, and exploring various technologies or frameworks.

The advice from the interview masterclasses will apply! ([system design](https://www.jointaro.com/lesson/J3I9fTW9ulr6T9KjxpqY/masterclass-how-to-ace-your-big-tech-interview-system-design/) or [DSA](https://www.jointaro.com/lesson/V4sTACzfOh22nMVcUV3w/masterclass-how-to-ace-your-big-tech-interview-data-structures-and-algorithms/))

Assume you're at a public company that gives you X RSUs as part of compensation. One way to think about the decision to sell or not is: 

> If I had cash on hand, would I actively choose to buy X RSUs right now?

If the answer is no (it will be for most people), the rational thing to do is to **sell all your vested stock** and diversify. Of course, very few people do this, either out of laziness or because they think the stock will still go up.

In terms of handling stock price fluctuations, one thing that really helps me is to realize that the stock price is out of your control. For the vast majority of engineers in Big Tech, there's very little they can do to impact the company stock. Why worry when you're helpless? 😅

(I also talk about the stress associated with checking stock prices in this [LinkedIn post](https://www.linkedin.com/feed/update/urn:li:activity:6989278004149465088/).) It's easy to feel anxious when so much of your comp is tied to company performance (e.g. the [5 offers I got as a new grad](https://www.jointaro.com/lesson/4MBOiqWEMbCTCcLPjisz/5-offers-w-faang-companies-as-a-new-grad-details-lessons/)).

I like the ***greedy approach*** to career growth. If you feel like an opportunity gets you meaningfully closer to your long-term goals, take it. Waiting for the perfect opportunity doesn't work since (1) it may never come and (2) the tech industry moves so fast that your definition of 'perfect' will evolve.

Based on this, I think you should take the Amazon role because:

- The Amazon brand is powerful and will open up future options
- Transitioning to a software engineering role now will ensure that you stay in the SWE track.

I would not worry about the compensation not increasing despite your 6 months of work experience. The delta would be small/symbolic anyway, perhaps $10K-$20K. The above factors are more important this early in your career.

**Choose the shortest path back into an active coding role**. 

You mentioned that you haven't done much dev work in the past 4 years or so, so I'd first focus on remedying that. If you're a Partner Engineer or Solutions Engineer, the barrier to be a Software Engineer is a bit higher -- it may require re-interviewing even within the same company. 

It sounds like you have great Android experience in the past, so I'd use that to transition in to a mobile engineer role. Once you're in that position, it'll be easier to transition to AI/ML, which is your eventual goal. 

I don't think a certification helps in these cases. They are expensive and take time. You work in Big Tech so you presumably know lots of people; can you use them for referrals? 

Especially in recent months, the stigma around low performers being laid off is **almost entirely removed**. Countless companies have done mass layoffs in the past 1.5 years, so people won't assume it's performance-related.

In general, people worry too much about explaining how they'll explain a layoff.

- It often won't even come up in the interview, which is totally fine. Don't feel the need to volunteer info about layoffs that you don't want to volunteer.
- If it does come up in interviews, you can either say (1) you were part of a big layoff (esp if you worked at Amazon, which had widely publicized layoffs of tens of thousands of workers, or (2) just mention that the company "wasn't a great fit, and I'm excited by many of the other opportunities"

Keep the conversation more focused on *where you're headed rather than what you're leaving behind*.

- [**Did you just get laid off? Here's how to think about it.**](https://www.jointaro.com/lesson/ZaQOp7CPMFfHYX4Nx4bI/did-you-just-get-laid-off-this-is-how-you-should-think-about-it/)
- [**\[Masterclass\] How To Survive Tech Industry Layoffs**](https://www.jointaro.com/lesson/axnVXYox5QeOneqcoyuH/masterclass-how-to-survive-tech-industry-layoffs/)

I highly recommend the [time management masterclass](https://www.jointaro.com/lesson/rnX9EKpzc43TgGW9MozG/masterclass-how-to-manage-your-time-optimally-in-tech-and-achieve-more-results/). And I actually talked to Steve Huynh about exactly this topic! Productivity tips from [A Life Engineered](https://www.jointaro.com/lesson/s9VPqSHk2EuK2xOaBqYq/getting-to-the-top-1percent-of-amazon-engineers-productivity-tips-from-a-life-engineered/). I'll ping Steve to see if he's interested in giving a talk :) 

A few random tips from me: 

- Start each day with a clear task. It's worth spending a few minutes at the end of each workday to write down your first task for the next day. Ideally something &lt; 2 hours long that you are reasonably confident you can accomplish.
- Reflect on where your time is going, and get feedback from others. We have our own ideas of how productive we've been, but your project lead or manager will provide a valuable perspective on how it lines up with team/company priorities.
- If you have a hard time finding focus time at work, it's likely your colleagues are as well! Coordinate with them to setup pre-defined focus days that more people can follow, e.g. Wednesday is a "no-meeting" day at Meta.

You don't need to have something to say. **Just ask good questions**. 

- Do some research on the people or topic being discussed at the tech event, and ask a question about that. 
- Ask how people discovered the event and what motivated them to join. 
- Ask what people are hoping to learn from the event. 
- Ask about changes: what has changed about a person's job/company/setup in the past 6 months or year? How will it change? 

Once you've networked with people , make sure you follow up. Send personalized messages and add people on LinkedIn (and share your Taro profile if you've answered questions!)

- Here's the [masterclass on building deep relationships in tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/).
- [**Overcoming Imposter Syndrome**](https://www.jointaro.com/lesson/dTSdd4ozp298jH3glvnx/overcoming-imposter-syndrome-you-have-so-much-more-value-than-you-realize)
- [**Don't Be Naive When Networking**](https://www.jointaro.com/lesson/BPh3QbVvH1HaGV0bSszf/dont-be-naive-when-networking-understand-that-youll-get-burned)

Rather than trying to find entrepreneurial people, can you make them come to you? Start building something -- anything -- that solves a tiny problem, and then start sharing your work with others. Even if you don't build something, you could publish some writing online over a few months to attract people. 

> I am very extroverted so can't do my own project don't have the motivation , not build that way.

Can you expand on what you mean by this?

There are builders everywhere, not just in Silicon Valley. 

In Alex's case, many companies showed **inbound interest**, which is extremely powerful. If you build something cool, you'll get people and companies reaching out to you, which already gives you a huge advantage in the job search.

Of course, this is not always possible. A few ways to connect with startups:

- Go through startup directories, e.g. those funded by a VC or accelerator like YC ([WorkAtAStartup](https://www.workatastartup.com/))
- Go through your network. A very common destination for Big Tech engineers is to join a startup (or start a startup). Connect with them and learn about their experience.
- Find "open-core" startups that are built around an open-source project (e.g. [DAGWorks](https://github.com/dagworks-inc/hamilton) or [Supbase](https://github.com/supabase/supabase)), and make a contribution.

In terms of reaching out, the best thing you can do is to actually care about their problem space. Many startups are starved for attention and they want people to pay attention to their efforts. So if you make clear that you **understand their problem domain and attempted solution**, there's a good chance a small startup will chat with you.

BTW, we do have a few founders in the Taro community as well -- I'd post in Slack to see if you can connect with them :)

In general, I advise keeping things **vague** when dealing with recruiters: don't share your previous compensation, expected compensation, or what level you want. The idea is that you only want to have these discussions when the company has invested in you (through 5+ hours of interviews).

So with that backdrop in mind:

1. "I'd want to understand how the expectations at each level in more detail -- is that something that needs to be decided now? I'd like to focus on meeting the team, and based on how the interviews go, we can decide on a level we both think is fair."
2. "I'm more concerned with the job and whether it's a good fit at the moment, I'm sure we can come up with a reasonable benchmark on compensation later in the process."

Based on how pushy they are for #2, you can also give them the reassurance "I've talked to a few friends who work at company X and I'm confident this interview won't be a waste of time. Based on the data points I've seen, I'm sure we can find a reasonable compensation agreement."

Finally, another tactic is to answer the question with a question. So if they ask you about compensation expectations, say "what is the typical comp band for this role?"

I'd also **highly** recommend these resources:

- [How to Negotiate a Big Tech Offer as a Software Engineer - Pragmatic Engineer and Rahul](https://www.jointaro.com/lesson/9bkla80fiO1HMNG3ACBk/how-to-negotiate-a-big-tech-offer-as-a-software-engineer-pragmatic-engineer-and-rahul/)
- [\[Masterclass\] Understanding And Optimizing Your Pay In Tech](https://www.jointaro.com/lesson/gk408yBIV2fa5RjVR213/masterclass-understanding-and-optimizing-your-pay-in-tech/)

Your manager needs to be on your team to get promoted. Phrasing this as an ultimatum ("*I'll only do this if I get promoted.*") will almost certainly be counter-productive.

Instead, I'd phrase this as a collaborative discussion where you voice your concerns. Here are some starting points of what this could be:

> When I look at the scope expectations for my level vs. the work I'm taking on, there seems to be a big gap. I'm concerned this may lead to problems when working with the broader team, and I'd love to chat with you about that.

> I'm really excited to take on this project, but I'm also keen to understand how this fits into my path on the team. When do you think we could have a career conversation?

For me, this was one of the hardest parts of being a manager -- I had so **much less focus time**. What helped me was to partition my day into chunks where I was fine being reactive (and I expected to be pulled into random fire), and other chunks (sometimes this would be the evening...) where I had focus time.

In terms of where to focus your time and energy, one way to think about your job as a manager is to **minimize surprises and unknowns**. 

- The high-performing engineer who leaves the team
- The project that get delayed by 2 months
- The XFN partner which is a pain to work with. 

Structure your time in meetings or with tools so that you can more easily detect and solve some of these issues. This usually manifests in observing the work your engineers are doing, talking to leads from other teams, and figuring out what high-priority work the team really needs to focus on.

- Here's another perspective about [how to allocate your time from David Pan, a former VP of Engineering](https://www.jointaro.com/lesson/SM4ba01t6PQFsrmlYMKK/how-managers-split-their-time-between-highmediumlow-performers/).
- [\[Taro Top 10\] Software Engineer To Engineering Manager (IC -&gt; M Track)](https://www.jointaro.com/playlist/oz0mnJvHHgM8NfVF7rgp/)

Good luck as you onboard into the new job! I recommend going through this blog post about the "Talk and Observe" framework for onboarding: <https://www.jointaro.com/blog/talk-and-observe-a-framework-for-engineering-onboarding/>

Your question is about how to easily talk to your new colleagues, especially those outside your immediate team. I think a simple, straightforward approach is the best here:

- Just ask "*I'd love to understand your experience on the team.*"
- Look them up on LinkedIn and ask questions about their career, especially changes they've made (moving, changing jobs, etc).

You don't need to have much to say! Just be curious. 

I'd also recommend meeting up with your coworkers physically if possible. The small moments that happen IRL (walking to lunch, small talk as people come into the office, etc) turn out to be quite meaningful.

Also check out the [masterclass for joining a new team](https://www.jointaro.com/lesson/n384HdJuDgulSHbHQLnf/masterclass-how-to-succeed-at-a-new-team-or-company-as-a-software-engineer/).

I love Kuan's advice. The only thing I'd add is that it's also worth formulating your own opinion and then advocating for that. A lot of these conversations go well (and it reflects well on your path to Senior Eng) when you can say, "*I think this project makes the most sense for X and Y reason.*"

How large is your company? Most medium/large companies will have a rubric for expectations around scope/impact for each level of engineer. 

I'd copy/paste that rubric into your doc, then annotate it with how you feel you're doing along various dimensions. Highlight areas where you feel you're already meeting expectations and where you need more support. Then ask for feedback to see if your manager agrees with you.

That is your development plan!

First my non-answer: you should still ask for equity! It's less common in Europe (IMO the *understanding* of equity in Europe is a lot lower), but there's no harm in asking. Unless you know the company doesn't do that, just asking for RSUs or stock options can be really powerful. 

To answer your question, my question is: **what levers can you pull for the negotiation**? In most offers, there are 3 or 4 negotiable parts: 

- Salary
- Signing Bonus
- Annual Bonus
- Equity

The reason most negotiations work is that the company and employee value the above components at different amounts, e.g. more equity vs less salary. If you no longer have equity as a component of negotiation, your life is harder.

The extreme scenario is if you literally only have salary to negotiate on. Then it really is a zero-sum game: you want a higher salary, but the company wants a lower salary 😨

So the question is, how can you introduce more variables to find a win-win? Some ideas you can offer for a higher salary:

- Sooner start date
- Fewer vacation days
- Promise of a review/salary adjustment after a few months.

Some great resources to check out: 

- [Master The Art of Successful Negotiations: Unlock Your Full Potential](https://www.jointaro.com/lesson/zQWx8Vq89OA2lERWnjvL/master-the-art-of-successful-negotiations-unlock-your-full-potential/) from a professor at INSEAD
- [How to Negotiate a Big Tech Offer as a Software Engineer](https://www.jointaro.com/lesson/9bkla80fiO1HMNG3ACBk/how-to-negotiate-a-big-tech-offer-as-a-software-engineer-pragmatic-engineer-and-rahul/) - Pragmatic Engineer and Rahul

Sorry to hear you were surprised by the negative feedback, that never feels good 😭 

The good news: you're not on a PIP and you have a 2 year history at the company. So you definitely **have not** been written off. The best thing you can do now is show that you're receptive to the feedback and act on it.

I talk about being a "feedback sponge" for a portion of this video (starting at 0:54): <https://youtu.be/Rzl3_5hcnwI?t=54>. Summary here: 

- **Write down the feedback**. This lets you reflect on what you heard, and also shows you're serious about it (assuming you have some shared doc with your manager). More on a [shared 1:1 doc here](https://www.jointaro.com/lesson/wcFrGc53iHzbWh0Ssw1j/dont-waste-your-1-on-1s-build-the-relationship/). 
- **Address the concern quickly**. Better to over correct rather than under correct.
- **Follow up**. After a few weeks, proactively bring up the concern that was surfaced, and ask what else you could be doing. 
- Finally, this is more on the topic of prevention, but going forward, I'd [ask very pointed questions about how you're doing](https://www.jointaro.com/lesson/wcFrGc53iHzbWh0Ssw1j/dont-waste-your-1-on-1s-build-the-relationship/). Don't just ask "*How am I doing?*", ask questions like "*I feel like I was slow to ramp up on this project. Do you agree, and what could I do better?*" ([More here](https://www.jointaro.com/lesson/srTbalkn0HMwEH7HoOpY/how-to-get-real-feedback-so-you-can-actually-improve/))

Big Tech (and Microsoft) is great, but I'd caution against assuming that it will be the perfect job. It won't be perfect, and I actually know many, many unhappy engineers working in FAANG. 

Observing that the grass is NOT always greener can help you relieve some of the depression/envy you might be feeling.

Like any other job, working in Big Tech has pros and cons: 

- Defending Big Tech: [ https://www.youtube.com/watch?v=gmL-yM1r_zo](https://www.youtube.com/watch?v=gmL-yM1r_zo)
- Attacking Big Tech: [https://www.youtube.com/watch?v=HoXPjGF3gz8](https://www.youtube.com/watch?v=HoXPjGF3gz8&t=348s)

Sorry to hear that, I know it must be disappointing :( 

Honestly, given that you don't get feedback, I wouldn't get too hung up on this. **Interviewing is a numbers game** -- the best thing you can do is just to line up a bunch more interviews. 

Independent of the feedback from the company, you can also do some self-reflection. You probably know which interviews went well and which didn't. It's worth writing down some reflections after each interview and review questions where you feel like you struggled.

Do you have enough personal runway if you quit your job? If you have a good safety net, you can consider the dramatic move of simply quitting your current job. 

This kick-in-the-butt may be very valuable for you to find a new environment where you can really thrive and feel energized. 

This will force you to be uncomfortable (in a good way!): 

- Start networking and building relationships
- Give yourself time to explore various topics, side projects, open source contributions, or different industries altogether

What is the cost of maintaining a decent rapport with your current teammates? Given that you're transitioning internally, and not to a new company, it's very **important to maintain your reputation and relationships with your colleagues**. There's a good chance you'll interact with them again at this company, or in a future company you happen to intersect at. (This happens very frequently!)

I'd imagine the cost of keeping the relationships alive is not very significant, perhaps a few hours per week. If that's true, do it. 

Beyond that, though, your reputation is what will get you the best opportunities in your career. Beyond your skill as an engineer, you want people to actually have a positive association when they think of you.

Find teammates you enjoy spending time with and you can also learn from. These are the ideal people to stay in touch with. 

On the topic of switching companies or teams, please also consider what your tenure says about you: [https://www.youtube.com/watch?v=RYY3maOhSWI](https://www.youtube.com/watch?v=RYY3maOhSWI&t=319s)

Two thoughts in addition to the great ideas from Jonathan: 

- **Can you create more focus (and education) around the work your team is doing?** e.g. schedule a bi-weekly meeting where you talk about the features you're building, how they contribute to a metric moving, and invite feedback.
- **Can you chat 1:1 with key people on the team to understand what they view as "important" work?** Then, in your messaging of the customer support tools, you can connect the dots to what they mentioned as important. If you can't do that, I'd try to expand the scope of your work so there is some overlap.

See also: 

- [**What To Do If Your Manager Doesn’t Care About Your Work**](https://www.jointaro.com/lesson/m0nzUspfEz5fn4Cp5wXi/what-to-do-if-your-manager-doesnt-care-about-your-work)
- [**"How can I get my work better recognized by leadership?"**](https://www.jointaro.com/question/cU1qsdIXMMNuFiNOM3gz/how-can-i-get-my-work-better-recognized-by-leadership/)
- [**"How can I make sure that I get full credit for my work?"**](https://www.jointaro.com/question/Dw4kffB557sUhU9Pkgtv/how-can-i-make-sure-that-i-always-get-full-credit-for-my-work-and-am-properly-leveled/)

Here is my (non-answer) to your question 😅

The way you would answer "*Which domain is better for long-term career growth and compensation*" is to look at things like: 

- Projected # of job openings
- Average compensation for these roles 
- Ability to transfer to other domains in the future

In my opinion, **these are the wrong questions to ask when deciding a career direction**.

Since you're on Taro, you're ambitious, career-oriented, and a fast learner. Your should aim to be in the top 10% of the field, not to be average. Any of the stats you find online will bias toward avg data points, things like: 

- "*The average software engineer in the US makes $62K/year*" -- this is not very motivating, I'd like to make much more money than this
- "*There will be 190,000 software job openings in the next 5 years*" -- this stat is pretty useless for me

Instead of trying to work backward from whether backend or low-level systems are better, **work forward from promising situations**. 

- Do you have mentorship from a database expert? Work with her and see where your career takes you. 
- Do you have an idea for a side project around GPUs? Pursue that and start finding collaborators on GitHub. 

The people will the most successful careers benefit from outlier events or people. A company, project, or relationship that becomes transformative for their careers. Focus your energy on putting yourself in that position rather than trying to big-brain which domain will be hotter in 5 years. 

I don't think having other offers makes it more likely that you'll get the offer, but it does help you with negotiation. 

This is an example of where I recommend candidates to keep it vague and not reveal extra information. The general rule is that you should **reveal additional info only when the company has confirmed that they're giving you an offer** (ideally in writing).

So in this case, I'd say something like this: 

> I'm exploring a few other opportunities, but nothing concrete to share at this time

I like this since it could pretty much mean anything 😂 like, it could mean you have several other offers already, or you are about to apply to other roles. When you get the offer from the company, then you can show your hand.

I just answered this related question about "[**Actual offer taking too long after verbal confirmation**](https://www.jointaro.com/question/o831qCRVZicvxdjsx8iR/actual-offer-taking-too-long-after-verbal-confirmation/)", which might be applicable here.

Three weeks is significantly longer than I've experienced between the verbal confirmation and written offer. Do you have details of the offer or just the confirmation that you will be getting an offer? 

I'd ask for details of the offer even if the company needs more time to put it together formally (i.e. in writing). This will help you get a sense of how this offer compares with the others.

- If the offer is competitive, use it as leverage with the other pending offers. 


- If the offer is not competitive, I'd mostly ignore this company and focus on the others. 

Can you ask them for an ETA when the offer may come, along with an explanation of why it's taking so long? This may also indicate chaos or disorganization within the company which you'd want to avoid.

I also wanted to say, I really appreciate this question. Everyone goes through feelings of doubt and burnout in their career. **This is totally normal**, and it has no bearing on whether you are fit to be a software engineer or not. 

No one should gatekeep what an age, gender, or job type which are allowed to be software engineers or not. If you find joy in building software, you can become an effective software engineer.

For me, the excitement of software engineering is simple: the ability to easily build something that lots of people can use and benefit from. 

> for last 1 year I have been going through interview prep resources like LeetCode, AlgoExpert, and practicing from books like CTCI for interview prep

For most people, including me, interview prep is soul-sucking. I would not recommend you spend much time on this unless you are confident that you will start to get interviews. 

My recommendations to get energized about a software engineering career: 

1. **Surround yourself with people who are enthusiastic about building and shipping**. "You become the average of the 5 people around you", but the beauty of the internet is that you get to pick which people you hang around!
2. **Ship something ASAP**. I truly mean ASAP. Like, spend the next 3 hours deploying a website, or publishing an Android app. You'll get a huge dopamine hit when you see your code live in the world -- don't worry **at all** about the quality.

Here's how I'd think about who to include as a reference check: 

- People who will say positive things about you (obviously)
- People who can speak to specific experiences or projects (rather than than just generalties like "He works hard")
- People from a diversity of past experiences (not all from a single job)

So in my case, I believe I gave the contact info of the following people when I joined Facebook in 2017: 

- My Product Manager from Pinterest who had actually joined Facebook already 
- My Facebook intern manager from 2013, who was now working at Airbnb
- My Stanford professor for whom I did my senior project

Since I was still working at Pinterest at the time that I landed the Facebook offer, I didn't give any names from Pinterest. Most companies will understand this. 

OP, sorry for the (very) late reply! My experience is that anything with visualization or diagramming is always a bit clunky with online interview formats. 

The thing to remember is that all candidates will have the same struggle to communicate and, e.g. draw boxes in Google Docs. So as long as you don't feel like you're being unfairly hurt in the online format, I'd just do some mock interviews with this format in mind.

I can potentially forgive a disorganized or scattered onboarding, especially if you're at a smaller company, but the more concerning aspects of your manager are the unhealthy team dynamic: 

- Aggressively confronting teammates or designers
- Telling you to leave a call due to an argument with someone else

These feel like red flags to me. In almost all cases, **it's not worth trying to "fix" your manager**. How hard would it be switch teams or even companies? The amount of effort you should put here depends on what your other options are to simply leave.

In terms of how to address the manager:

- I do think it's worth stating your observations directly to your manager. Write down some points (*don't expect to have them memorized*) and tell your manager you'd like to do a "special" 1:1 to discuss your observations as a new person on the team. You obviously want to be careful how you present this, but you owe it to your manager to voice your concern if you do try an official channel like lodging a complaint.
- Some of the examples seem egregious enough that you should elevate this to company staff, e.g. HR. Especially if multiple people on the team have the same complaint, I think it's worth notifying them. I would NOT expect them to do much, since HR is primarily intended to protect the company, but you also shouldn't face too many repercussions if you have the numbers working in your favor.

Congrats on the offer! First, I'd ask the company how much time you have before you need to confirm. Here's a great question about a [reasonable amount of time to decide on an offer](https://www.jointaro.com/question/jNa6yYzkXAoipJbslk7Z/post-offer-discussions/). If they give you 2 weeks, that's actually plenty of time to interview somewhere else if you act with urgency. 

> I'm thinking that it would be wise to optimize for career growth

This is the right approach in general, but there are a few cases where IMO it makes sense to "chase" money or status: 

- You are early in your career and having a higher income would make a huge difference in your quality of life
- The other (higher-paying) company has significantly more brand value. 

It doesn't sound like either of these are true: a series C company likely has good brand already, and you mention you have runway. So I like the idea of optimizing for your long-term career growth!

> Do you have any tips about how to negotiate a better offer even when I don't have the leverage of a competing offer?

Yes! As you mention, the ideal scenario is if you have competing offers that you can reference. But the fact that you don't, and that you expect the other companies to actually pay more, could be twisted to your advantage. Basically, I'd say something like "*I'm in the process of interviewing at company X and Y right now, but honestly I really enjoyed meeting your team and the type of work I'd be doing with you. If you can increase my salary or signing bonus by $X, I can sign the offer today.*"

Of course, you should only say this if you're willing to accept the offer, but I've found many companies are happy to do this if they really like you. You're basically telling them that you're a flight risk **but** they can close you as a candidate with an increase.

This tactic worked to increase my signing bonus at Facebook by $15K+.

For pinging the CTO of the slow company that you like, you might as well. Since you likely have an offer pending, use that to create some urgency: "*I'd really love to consider your company, but I really need to finish the interview process by Thursday next week so that I have enough data to make a decision. Does that timeline work for you?*"

Some other resources that are relevant here: 

- [**The #1 Rule Of Negotiation - How To Avoid Giving A Number**](https://www.jointaro.com/lesson/4T3wTorG47wPzSqVmAOx/the-1-rule-of-negotiation-how-to-avoid-giving-a-number/)
- [**\[Masterclass\] Should You Work At FAANG? - What Big Tech Is Like For Software Engineers**](https://www.jointaro.com/lesson/JnEnRphdi5TaPZl1Zrl8/masterclass-should-you-work-at-faang-what-big-tech-is-like-for-software-engineers/)

From talking to Taro Premium members in India, engineers are unfortunately expected to share previous salary and compensation details with a potential employer. Like Alex mentioned, this depends on where you live. 

For proof of competing offers, this can happen. In fact, **I was asked to show proof of offer details multiple times**! 

After I graduated, I received a strong offer from Google due to fortuitious timing with the Twitter IPO in 2013 😂 I was able to use this as leverage to increase my signing bonus at Facebook from $75K to $125K, but the FB recruiter did actually ask me for proof of the Google numbers.

I talk about that whole saga here: <https://www.jointaro.com/lesson/4MBOiqWEMbCTCcLPjisz/5-offers-w-faang-companies-as-a-new-grad-details-lessons/>

On the topic of reasonable time before you decide on an offer, I just wanted to mention -- **you don't need to (you shouldn't) immediately accept the deadlines from the company**.

When I was negotiating between 6 offers in 2017, I was transparent about my process and asked for several additional weeks. The Big Tech companies were surprisingly ok with this, so you should just ask. Phrase it something like this: 

> This is a big decision and I want to ensure I can commit completely to the job I take on. I don't want my employer or me to have buyer's remorse, so I'd like to make the decision with all the data on hand. I'm confident I'll be able to do that within the next 2.5 weeks -- does that timeline work for you?

- **What will success look like in 6 months?** As a manager, you probably can't rely on things like code commits or features shipped to measure impact.
- How will you [allocate time between low, medium, and high performers](https://www.jointaro.com/lesson/SM4ba01t6PQFsrmlYMKK/how-managers-split-their-time-between-highmediumlow-performers/)? Are you comfortable committing to that? 
- **What feedback do you expect you'll need?** Do you have people, both from the team you're managing and your leadership team, who can deliver this feedback to you?

- **Define what "completion" looks like for your project**. So for the Android app, make clear to yourself (write it down!) what minimum functionality you want to build, and then stick to it. 
- **Find an accountability partner**, a friend or colleague who you talk to daily/weekly to ensure you're making progress.
- **When you first wake up, spend 30 min doing the work you most care about**. Don't get distracted by blogs, social media, or email. Treat this as sacred time. 

I'm sure there are lots of other great tips! Would love to hear from others. Here's the top 10 playlist for productivity: <https://www.jointaro.com/playlist/5WA87nbbYJWLnQ60D826/>

If you're talking about accomplishments in the context of your internship, the answer very much depends on the work you're doing.

I like the format you have, and I'd encourage you to actually **start with the outcome you want**. Internships are so short (generally &lt; 12 weeks) that you need that clarity. For example, imagine writing the line on your resume which makes it clear how much business impact you had.

You'd want it to be easily measurable, easy for a layperson to understand, and to have a meaningful amount of code behind it.

You should pick projects based on the above 3 criteria, and make this known to your intern manager so they can help you as well.

Here's the top 10 playlist of SWE intern advice: <https://www.jointaro.com/playlist/MGpBojl9gBzI9OQWTBzK/>

How *strong* your resume is depends on some factors that are in your control and some that are not in your control. 

For example, where you went to school, or whether you have a referral to a company, is not entirely in your control. (Although, given a long enough time horizon, referrals are in your control if you do enough networking.)

What is purely in your control is the work you do. **For software engineers, that largely manifests in terms of indie projects**. Here are a few ways this can make your resume significantly stronger: 

- **Your project is in a domain that your desired company also works in**. This is most valuable for startups. For example, you build a project in sports betting, and the company you apply for also does sports betting.
- **Your project uses technology that your desired company also uses**. This is especially powerful if the company uses a unique tech stack, e.g. [OCaml with Jane Street](https://www.efinancialcareers.com/news/2022/09/jane-street-ocaml).
- **Your project actually gets users**. This is the easiest way to be impressive, but also the hardest. If you have a mobile app or full-stack project which has a meaningful number of users (I define this as 5K+), you immediately stand out from other new grads. 

I'd highly recommend the [masterclass about building projects that gets tens of thousands of users](https://www.jointaro.com/lesson/OEuX0KMhcnNSTJ50Voee/masterclass-how-to-build-and-grow-tech-products-to-500k-users-for-free/). In addition, check out the [resume masterclass](https://www.jointaro.com/lesson/OnQV2V3J8DYVBBuGbZx6/masterclass-how-to-write-a-stellar-tech-resume-that-gets-you-more-job-opportunities/). 

This is what we spend most of our time talking about in the [Taro mastermind groups](https://www.youtube.com/post/UgkxwHxs-TxzjkWNzxApf_rc8hEIeqNe9I0l)! The groups are set now, but we'll probably do them again in a few months.

Since this is a side project, you should **use tools that are cheap or entirely free**. The working model for most dev tool companies is to have a free tier for hobby projects. You only start paying if your project takes off, e.g. 10K+ users. This works out since, if your project did indeed blow up, you're probably ok paying for it. 

BTW, not related to your question, but I'd encourage you to **have the most simple possible tech** when you're starting out. If you're a frontend dev, I imagine building the REST API with Golang and Gin (+ Postgres) took some time. Why not just use something like Firebase -- it's a bit constraining, but much easier to get up and running.

For #2, **distribution** often becomes as important, or even more important, than the product. If you're willing to dedicate years in a single domain, the best thing you can do is create valuable content in area, whether through blog posts, videos, or tweets. If you're on a shorter time horizon, you can either (1) try to go viral or (2) reach out individually to users and explain the value of your product.

There are tons of ideas!!

**Don't aim for originality; aim to build something people will use**. These 2 are different, and often in tension with one another.

A simple algorithm to follow:

1. Take an existing app with 10K+ downloads
2. Remove some features 
3. Remove all ads

Now you've found something which is simple to build and has provable value to at least 10K people. Congratulations :)

(don't pick a marketplace and don't pick anything with a cold-start problem)

Is this in a live meeting or through chat? 

Since you're new, you should feel empowered to ask a lot of questions and request clarification. Your questions may be helpful to others in the meeting as well, so it's not only a service for you. 

If you feel like pausing the meeting would be too disruptive (the meeting is very large, or it's something that you've already encountered), then you can simply write down where you're confused.

On your own, make your best attempt to look up the terminology and architecture on your own. Then, you should validate your understanding with someone on the team. 

If you have a dedicated onboarding buddy, they're the perfect person to start with. You should also talk 1:1 with each of the people on the team, and you'll find that many of your questions get answered through those conversations.

- [Asking good questions](https://www.jointaro.com/lesson/VrD8EcaG6p7ZS5fTroFB/the-breakdown-of-a-good-technical-question/)
- [Onboarding efficiently](https://www.jointaro.com/lesson/68TtfFRPhcwww0I7hdYT/part-3-meta-intern-success-series-onboarding-efficiently/)
- [How to learn quickly in tech](https://www.jointaro.com/lesson/u9ldIvrTvV1wfWExccDR/masterclass-how-to-learn-quickly-in-tech/)

Is there a quick way to **test the waters** between options #1 (climb the ladder) and #2 (interview around)? 

In a vacuum, I'd lean toward option #1, since Intuit is a great, well-known company, and getting to Staff Eng there will be powerful for your career. Also, interviewing at another company takes a lot of time and energy.

But this changes if you have an **unfair advantage** when it comes to applying for a new job. The best jobs never come through applying the normal way -- they come from: 

- A friend advocating for you and providing a strong referral
- A brand new opportunity that hasn't been publicized yet (e.g. a startup)
- Demand in the market for a particular skill set that you have

If you have any of the above, I'd explore the external opportunity. Some of this is not in your control, but you can put our feelers as well to see how likely it is. The feedback you get should dictate how much energy to split between #1 and #2. **I would not do #3 for an extended period (both job searching and promo grind)**.

The other aspect is how long you've been at Intuit. The one-year mark is an important milestone in terms of perception (to not be a job hopper). Ideally, I'd stick around for at least 1.5 - 2 years. 

How much do you trust your manager? 

- If you do, I think the earlier option is best to give them and the team to prep. 
- If not, you should just wait. It's ok to be selfish here to protect yourself. 

The worst-case outcome would be that the company asks you to leave immediately after your give notice. Since you're likely ok with that given that you have another offer, I don't think you need to worry too much.

Definitely use **Android Studio**.

Beyond being a better tool for the job, if you work professionally as an Android Dev, your team will almost certainly use AS, and that should be an input into your decision. 

Which company do you work for, and where? You might get better answers from the community with that info. I don't think you should assume that your severance will be tied to tenure. 

If the startup is strapped for cash (presumably they are, if they're doing layoffs), all laid-off employees may get the same severance (e.g. a month or so). 

A top company (FAANG or equivalent) will generally give more severance based on years of service, but I don't think there's a "norm", especially in your case given the complication around living in another country.

You want two different things: 

1. Add a project to your resume that looks impressive (i.e. results in an interview)
2. Learn a new tool like Spark, Airflow, or dbt

My answer is different for each. 

- For #1, like Alex mentions, the truly impressive thing is to get traction. That will almost certainly take longer than one weekend. 
- For #2, if you follow a tutorial and then extend it slightly in a creative way, you can easily achieve the learning objective in a weekend. 

An important first step is to understand where your time is being spent today. You mentioned several activities (knowledge transfers, documenting work, review PRs, etc) -- what is the breakdown of how many hours per week you're spending. 

Once you have that, reflect on which periods were most impactful and which were not. You could also segment it in terms of things like where you're receiving help, where you're giving help, and where you're doing IC work.

if you present this to your manager with your reflections, you'll be able to have a very fruitful conversation about how you could improve your deliver speed.

See also the masterclass on [time management](https://www.jointaro.com/lesson/rnX9EKpzc43TgGW9MozG/masterclass-how-to-manage-your-time-optimally-in-tech-and-achieve-more-results/).

Perhaps a dumb question, but may I ask **why you want to build solid products**?

What is the impact of the shoddy engineering work? If the incentive structure is created by the managers, are they aware of the situation, and why are they not concerned?

Before creating friction with your fellow engineers, I'd spend time understanding the mindset and priorities of the management team. Perhaps they're deliberately making the choice to cut corners for expediency, in which case, you will lose any code quality battle you try to take on :)

Two other things worth mentioning:

- An MBA could be valuable if you use it as an immigration tool -- if you get admission into a top US program, for example, that could be a compelling reason to do it.
- From the people I've heard doing an MBA, the coursework is not really valuable. And I can say from running Taro that effectively none of the MBA curriculum would be relevant to my day-to-day life.

Things like accounting or financial projections are completely irrelevant for me right now. We're just trying to keep the lights on :) I'm sure those skills are helpful for a larger company, but I don't see how they help in the early days of a software business.

I don't think an MBA will help if your goal is to do a high-growth software company. In fact, if you ever plan to come to Silicon Valley (you mentioned you're in the UAE), **there's a general disdain for folks with an MBA**.

However, the MBA is not without redeeming qualities. The main advice I tell anyone who wants to start a venture is to (1) find a good cofounder and (2) surround yourself with people who can inspire you and give you ideas. An MBA is one possible way to do that, although quite an expensive one. 

You might have better luck building your network in a high-growth tech company, and you actually get paid!

I'd prefer system design over DSA, since system design is much more about the discussion rather than the solution. 

System design requires a competent human on the other side of the table, and **that is the scarce resource for you**. If Interview Kickstart provides that, use them for that. DSA is comparatively more cut-and-dry, since you can do a decent job evaluating how you did on your own.

I'd also recommend checking out the [system design masterclass](https://www.jointaro.com/lesson/J3I9fTW9ulr6T9KjxpqY/masterclass-how-to-ace-your-big-tech-interview-system-design/) we have.

Instead of ChatGPT for your mock interviews, I'd much prefer a human. Just grab a friend or someone in Taro Premium and talk through some stories with them for behavioral interviews. 

Yes, if you're not writing code, and you want to stay as an individual contributor SWE, I think this will hurt your career. 

Instead of jumping to the conclusion that you need to switch jobs, though, I wonder if you can start to take on coding work at your fintech job now. That'll be much easier (and you have trust built up) compared to finding a coding role at a brand-new company where you might struggle if you haven't coded in a while. 

**The reason to switch would be if you don't think you'll have any kind of growth/change in your contractor role**. e.g. if you simply don't have permission to push code to the repo, that's a difficult barrier to overcome.

Here are great responses about how you can provide value to [career mentors who have helped you](https://www.jointaro.com/question/EsglFrQBpI81Nyd59kcP/ways-to-provide-value-to-people-further-in-their-careers-who-help-you/).

How you best benefit from your relationship with the SDE3 depends on your relationship. How have they assisted you? How much time do they have?

It will help to have a "meta-conversation", to talk about how you would like the relationship to go. Something like this: 

> Hey, you've been so helpful for me in understanding life in a product-based company. You probably know that one of my goals in the next year is to transition into one of those roles, and I feel I could continue to learn so much form you. What do you think would be the best way for me to do that?

I like the idea of a growth plan if they know you well enough and you have check-ins at regular enough intervals. I mention this on the other thread, but I think the one of the best things a mentee can do is to follow up with me as they achieve different milestones -- the growth plan sounds like the first step in that.

Excited for the start of your internship and we're all rooting for you! What I'd recommend: 

- Learn [how to learn quickly.](https://www.jointaro.com/lesson/u9ldIvrTvV1wfWExccDR/masterclass-how-to-learn-quickly-in-tech/)
- Learn how to best [high-quality ship code](https://www.jointaro.com/lesson/iYpRj8XfyzCSaTYnce3y/masterclass-how-to-write-better-code-faster-as-a-software-engineer/), which will be the primary metric you're evaluated on as an intern.
- Alex made this [8 part internship success guide](https://www.jointaro.com/lesson/DPcsvbf5IKk57xcqyiAC/part-1-meta-intern-success-series-internship-program-overview/?ref=jointaro.com) which I highly recommend: it's geared toward Meta interns, but a lot of the lessons should carry over.
- Attend live [Taro events](https://www.jointaro.com/events/) that you find relevant. The speakers are almost all at the top of their field, sharing very tactical advice.
- Finally, connect with others in Taro Premium. This helps not only to expand your network but also to understand how other companies operate (**especially important for interns**). You'll get notified about member-matching in the Taro Premium Slack (you'll receive an invite shortly if you haven't already).

Here's [a blog post I wrote](https://www.jointaro.com/blog/the-ultimate-software-engineer-internship-survival-guide/) about succeeding as a SWE intern.

I question the premise that the timeline for promo is reset when you switch teams. If you've shipped something meaningful in your old team, that can provide further evidence that you're sustaining next-level performance. Of course, the most recent team carries more weight, but your history is not completely discarded. 

Google is slow to promote -- the timeline will depend on the team and manger, but generally at least 2 years is expected for a fresh promo. See more in the [Google description](https://www.promotions.fyi/company/google/performance-review) at [promotions.fyi](http://promotions.fyi).

Here's how I'd suggest [having the conversation](https://www.jointaro.com/question/N0Ej5OF5OheoryAs2Shi/how-soon-should-i-start-thinking-about-promotion/) with your manager about promotion timelines -- you want to strike the balance between being ambitious and also understanding the needs of the team.

David Pan talks about how the best tech leads are able to [progressively de-risk a project](https://www.jointaro.com/lesson/uHqZZ15SK19MatEvLSO6/what-makes-a-truly-great-tech-lead-a-vp-of-engineerings-perspective/) with every passing week, and it sounds like that's where you didn't feel that happened.

The hard part about system design is that there's no right answer- it really depends on the constraints in your company. Here are some questions I'd ask to determine where you are on the spectrum of R&D vs ship-it-no-matter-what.

- How big is your company? How many people will have to maintain/improve the design in the coming months?
- What is the cost of changing the design or fixing it later?
- How much does this body of work deviate from the past work? In your case, how many times has the company redesigned the game engine, and what additional risk is there here?

It's worth documenting the trade-offs and potential issues, then collecting feedback from the team. The uncertainty you're feeling around whether the design would work is not a great place to be, but the feedback can ensure that no one is surprised (since everyone technically signed off on it).

My personal bias is that you should have receipts for your work as frequently as possible, unless you're truly in an R&D role. I'd push you to have some progress update or deliverable that marks progress every week. **A month is far too long in startup-world**. I'm not as sure about how the game industry works, but I'd assume similarly for most gaming companies as well. 

BTW, there are great discussions about this on the [system design topic](https://www.jointaro.com/topic/system-design/) on Taro. 

I don't think the prep for a behavioral interview at a bank will be much different than a behavioral interview at a software company. I generally like to read up on what the company values are, and then adapt my stories to more clearly tie in those elements.

My playbook is to have at least 3 stories ready to go following this STAR template:

- Situation
- Task
- Action
- Result

And then no matter what question you get asked, you should massage one of your 3 stories into an answer. Practice doing this with multiple friends, across multiple days. The benefit of this approach is that you will almost always be able to sound eloquent and thoughtful since you've rehearsed those 3 stories.

On the topic of transitioning from a small software company into a large finance company, you should tie that into a thoughtful question. Ask every interviewer some variation of this question:

> Coming from a small software company, I loved the bias toward shipping and iterating on mistakes. I imagine that's not as possible here, given the importance of stability in a finance company. How do you think about fast iteration speed while also maintaining a quality product?

Remember interviews are a [2-way street](https://www.jointaro.com/lesson/6vf8ksTF1VediypZpbFm/why-being-a-good-interviewer-is-so-hard/)!

How much do you know about the product and priorities of the company? If you can talk to the people at the new company in a casual way, you can start to understand this and build that understanding.

Equally as important is to understand the teams and people behind the projects you'll be working on. I don't think there's much you can do before you join, but [building deep relationships](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/) is very important when you start.

I don't think there's much value in trying to anticipate which tech you might use and prep for that. If you're joining Big Tech, you will use a bunch of different tech, and it'll be a different flavor from what you might get "in the wild". If you are rusty on things like version control, you could spend some time on that, but this is not the highest leverage thing you could do. 

In addition, as a Staff engineer, your code velocity becomes less important relative to your ability to set direction for the whole team. 

Oh yeah, and don't forget to relax! You want to be excited when you start your first day, not burned out and stressed. Companies will give you at least 1-2 months to ramp up. 

A good related question from a contractor at Amazon: <https://www.jointaro.com/question/MVIXqqZjesdoagmfAhAr/how-can-i-approach-looking-for-an-fte-role/>

Michael Lin gave a talk about [quitting a full-time job](https://www.jointaro.com/lesson/klwrSCVZpn6IcHX9seJy/case-study-how-to-quit-your-job-the-right-way-w-ex-netflix-tl-michael-lin/) and he has some good commentary about finding work as a consultant. His Taro profile: <https://www.jointaro.com/profile/Ab2xedZA7RhROW0wo9wBHIJbAsX2/>

I haven't had a contractor role as a software engineer, but I had one as an instructor for [Codepath](https://codepath.org/). I landed this since I went through the Codepath class, and had a portfolio of work demonstrating what I learned, and I stayed in touch with the founders.

I think the same playbook could apply for contractors. 

- Build a portfolio of your work (for contractors, more so than FTE), you're hired for a specific skillset rather than your learning. 
  - Make it clear why your work is impactful and impressive. Having [published apps here helps a lot](https://www.jointaro.com/lesson/OEuX0KMhcnNSTJ50Voee/masterclass-how-to-build-and-grow-tech-products-to-500k-users-for-free/). 
- Leverage your network. If you want to commit to being a contractor, you should spend a good amount of your time in brand-building and *marketing*.
- Get in touch with people you've worked in the past. Offer a concrete deliverable which is fairly quick for you to complete, and builds more trust.

Unless you're desperate (or you're purely doing it for lead-gen), I **wouldn't** spend much time on Upwork or Fiverr. It's hard to differentiate yourself here, and the cost structure favor devs in cheaper countries.

Platforms like TopTal and Turing are better, but I'd still prefer a direct relationship if you can.

> How to build people management skills as a first time engineering people manager.

One of the challenges with management is that so much of your value is in understanding the context and relationships in the company. 

I'd be careful with seminars, especially if they bring together managers across company sizes. The way you succeed as a CTO in a small startup is very different from an EM in Big Tech, and I'd imagine almost all the content is geared toward the Big Tech employee. And hearing a lecture becomes ineffective very quickly. 

IMO the most effective way to ramp up is to have a really solid plan when it comes to understanding the people and priorities of the company. That means [talking to every person in the company](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/), understanding the priorities, and what has been tried in the past.

I also like your 3rd bullet point around talking to other eng leaders. Taro is good for this (both connecting to other leaders and talking to more junior folks to understand their perspective). You could also attend an in-person conference. The nuance and back-and-forth you get with an in-person discussion or mastermind group is significantly better than attending a lecture. One that I'm familiar with is [ELC](https://sfelc.com/).

Some podcasts I've enjoyed (although honestly these are more for entertainment rather than directed learning):

- [Soft Skills Engineering](https://podcasts.google.com/feed/aHR0cHM6Ly9zb2Z0c2tpbGxzLmF1ZGlvL2ZlZWQueG1s/episode/NzMxNWM2ODItODU0NS00NTA5LWIwOTctZjE4MzgyYTY0MjAx?sa=X&ved=0CEAQz4EHahcKEwiYxqDMsf3_AhUAAAAAHQAAAAAQLA)
- [The Engineering Leadership Podcast](https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5zaW1wbGVjYXN0LmNvbS9aOERsX3FBdg?sa=X&ved=0CAMQ4aUDahcKEwjgkrjVsf3_AhUAAAAAHQAAAAAQAQ)
- We also have the #g-nyc-meetup you should join. You can organize a meetup and Taro will cover the snack/drink cost :)

I'm curious what are your favorite resources?

I would be start with a select few people for a recurring 1:1: 

1. your manager
2. your onboarding buddy
3. (potentially) your tech lead.

The first 2 people above (and probably the TL as well) have a vested interest in helping you onboard, so you should absolutely expect (and schedule) time with them for the first few months. The phrasing for these could be something like: "*As I ramp up, I'm really eager to hear your feedback and learn from you."* 

It helps to have an end date (e.g. 3 months after you join), so it feels less daunting to get the calendar invite. 

For the broader team, I'd start with just a single 30-minute meeting. Since you're new, you're still developing relationships and figuring out what you'll work on. It doesn't make sense to book a recurring meeting until you have more clarity on that.

Be proactive about scheduling the first meeting rather than asking for permission. Something like: 

> I'm new to the team and your name came up as the owner for this. \[I saw you've been working on X.\] I'd love to learn more about that and also hear about your experience on the team so far. I went ahead and found 30 min on your calendar for next week, but LMK if that doesn't work and I'm happy to find another time!

Regarding the purpose of the meeting, it can literally just be a "get-to-know-you" call. You can play that card pretty easily as the new person. 

I've absolutely felt this before! Feels like you're struggling with imposter syndrome. As we talk about in this video about [imposter syndrome](https://www.jointaro.com/lesson/dTSdd4ozp298jH3glvnx/overcoming-imposter-syndrome-you-have-so-much-more-value-than-you-realize/), remind yourself that you offer so much value -- I can guarantee that you have something people really care about and/or want to learn from you.

The other tip I have is to focus on working with others. Remember that when you're on the job, you're not going to work in isolation. You'll have a team of people that will support you, along with people who you can help. Things like pair programming, or just grabbing coffee with a coworker helps me a lot to combat any lack of confidence I feel. 

Is a team switch possible? How hard would it be, and are there other teams where you would know your teammates or manager? Honestly, if your manager is unsupportive, it's often easier to simply remove yourself from the situation (especially if you've tried to repair the relationship several times already).

I also really like Alex's answer -- can you agree on expectations with your manager **before** you get too deep into your work? 

p.s. we're not Blind, so no need to share your TC unless you really want to 😇 we'll help you regardless!

There's some detail about Meta's performance review process in this section of promotions fyi: <https://www.promotions.fyi/company/meta/performance-review#calibration>

Also here's [a video on YouTube](https://www.youtube.com/watch?v=OjI8kZgyeBU) I made about how stack ranking is typically implemented in Big Tech today (the more *politically correct* version compared to what MSFT had in the 2000s).

This is a great question and something more software engineers should think about! If you know what motivates your manager, you can understand their actions better, and that can educate how you work with them.

At some point, I'd love to do a full session with Alex about the life of an eng manager (or someone in the Taro Premium community can lead it), but here's how I think about performance evaluation for a manager: 

- Their team should deliver on the key features and outcomes for the business. 
- The manager recruits and retains the correct engineers on the team. 
- The manager coaches and grows high-potential employees, and removes low performers before they cause too much damage. 
- The manager collaborates with other teams to identify potential issues or opportunities. 
- The manager contributes to the strategy and roadmap for their team and broader org. 

**The number of engineers on the team absolutely does matter**. Presumably, a larger team means the manager has more scope, more outcomes, and more influence in the company. All of these are necessary prerequisites for getting promoted.

As you point out, this very often does lead to empire-building. I don't have a great answer on how to prevent that, let me do a bit more thinking. 

At Meta and Pinterest, the 2 companies I'm most familiar with, there is no distinction between a front-end engineer and "normal" software engineer. I didn't realize Amazon made a distinction... is there a pay difference between the two?

I have two thoughts: 

- If/when you leave Amazon, nothing prevents you from calling yourself a genric Software Engineer. You've genuinely done the work of a full-stack SDE, and other companies would happily interview you for your desired role once you explain your experience.
- From the marketability standpoint, I do agree with your friends that you'll have more options as SDE instead of FEE, simply because SDE is very broad 😆 

The more senior you become, the less you define yourself through the technology you know. That's why you'd never hear a principal engineer say something like "I'm a WordPress developer" or "I'm a Python developer" -- the technology they use is a tool to solve a business problem. So from that perspective, I'd recommend framing yourself in the broader SDE way.

This depends on the company, but based on my knowledge of Chime, I'd recommend **focusing on conversations and relationships with the engineering leads**: Directors and VPs. The Human Resources (HR) folks won't have much input on your candidacy for new manager positions.

On the topic of working with eng leadership, I'd focus your effort on the people directly responsible for front-line manager position (the director, in this case). If you shoot too high and talk to the VP, they likely won't overrule the Director on their team. Especially given that you're very close to becoming a manager, and you've already made it known, I'd spend most of your effort keeping in regular touch with Eng Directors across the company.

### An Alternate Angle

One more piece of advice around becoming a manager is to create scope. The premise of your question is that someone has to bestow upon you the manager title. However, in a high-growth company, two paths for management are very common: 

- A new project, feature, or workstream becomes important enough, and you are the person with the most context in that domain. So you naturally become the manager. 
- The existing manager gets promoted, leaves the company, or switches role. This actually happened in your case, but the doubt on whether the position will be backfilled is my last point...

### The Grim Reality of 2023

Finally, I wanted to call out that **it is significantly more challenging to transition into a management role today compared to a year ago**. Since tech companies are not hiring as much, there's not as much opportunity for a new manager. Along with this, tech companies are shifting their priority to builders -- individual contributors instead of managers.

With this context in mind, you should still try for the manager role if you're set on it, but hedge your bets appropriately.

It's really hard to predict the future on this. So much about the technology and the world will change in ways that we probably can't even imagine. 

- The **bull case** is that AI will make software even more ubiquitous than it is now, so there could be 5-10x more engineers needed (or at least people who can put code and AI together)
- The **bear case** is that AI will do all the work for us, so only a few managers/orchestrators are required. 

> This person shows favoritism towards someone else on my team due to a personal friendship

What is the impact of this behavior? My recommendation is to bring this up in a respectful way to your manager and focus on (1) the negative impact of the behavior you see and (2) any suggestions you may have. 

Few more thoughts in [my communication video](https://www.youtube.com/watch?v=kyUHOPYpXs4).

See also [Boz's career cold-start algorithm](https://boz.com/articles/career-cold-start):

> The first step is to find someone on the team and ask for 30 minutes with them. In that meeting you have a simple agenda:
>
> - For the first 25 minutes: ask them to tell you everything they think you should know. Take copious notes. Only stop them to ask about things you don’t understand. Always stop them to ask about things you don’t understand.
> - For the next 3 minutes: ask about the biggest challenges the team has right now.
> - In the final 2 minutes: ask who else you should talk to. Write down every name they give you.

I like Casey's answer a lot. I also think just stating your intention is very powerful and disarming.

> I just want to chat with you: understand what you're working on and see where I could help.

People are generally happily surprised to hear that. You're not requesting anything from them or adding a task to their backlog.

I feel this question! (lots of dangling sentences and incomplete Slack messages...)

What helps me:

- Put every task, even small ones, into a task backlog. Some people call this a "second brain" -- the idea is that you shouldn't use your brain to remember what to do. That should be in your Google Doc/Notion/whatever. 
  - **Before**: Read a Slack message, type out a partial response, and then forget about it
  - **After**: Read a Slack message, make a note in my backlog to reply, and then move on with the original task I was working on
- Figure out how to (1) lower the stakes of dropping things or (2) give yourself more margin for error. One way to do this is to have more frequent check-ins or deadlines on important tasks. You can do this through a calendar invite or an [accountability partner](https://www.jointaro.com/lesson/czwltSPj1pmYIlJUBMIk/not-getting-stuff-done-find-someone-to-call-you-out/).

Here's the full masterclass on [productivity and managing your time in tech](https://www.jointaro.com/lesson/rnX9EKpzc43TgGW9MozG/masterclass-how-to-manage-your-time-optimally-in-tech-and-achieve-more-results/).

There are 2 distinct phases for getting a big tech job:

- **Phase 1**: get interviews
- **Phase 2**: pass the interview

Until you've passed phase 1, I **would not** spend much time preparing for DSA interviews. Just focus on improving your profile (building projects, networking) so that you get an interview.

From the promotion perspective, unfortunately, there's not much you can do. You're at a series C company, so *maybe* the processes are not as rigid as Big Tech and you could ask for an out-of-cycle promotion. But that is very unlikely. 

A more likely outcome (but still unlikely) is to ask for a compensation increase despite not getting a promotion. See [this video](https://www.jointaro.com/lesson/wQ4o4UeSTu9oJDtdH75H/how-to-negotiate-a-raise-at-your-current-job/) for more details on that. Your peers and manager think you are performing at the next level -- do you have data to suggest that you're being underpaid? That would help in making an argument. 

The best way to gain leverage here is through a competing offer that pays you more. Phrase it like this: 

> A recruiter reached out to me, I decided to learn more, and I ended up getting an offer. Turns out, this offer is much more than my current compensation. I really like the work I do here, but I also want to ensure I'm fairly compensated. How might we bridge the gap?

If you're well-liked and important, your company may give you a counteroffer. (Note that some companies like Meta also explicitly **do not** give out counteroffers.)

Amazon actually had a formal term for this called ["dive and save"](https://www.promotions.fyi/company/amazon/performance-review#compensation). I'd do this only if you are truly ok with leaving your company for another opportunity -- you don't want your bluff to be called and then get stuck.

Resources on negotiation: 

- [3 powerful tips on negotiation](https://www.jointaro.com/lesson/8VeEnbxdbPKsZbTcCFm5/3-quick-powerful-negotiation-tips/)
- [The key insight behind negotiation](https://www.jointaro.com/lesson/YliP9kVbd1zym9kmv9Gg/the-key-insight-behind-negotiation/)

On the topic of entrepreneurship, I'd encourage you to create a plan before you venture into the unknown, lonely world of building something on your own. (speaking from experience :P) You're 100% correct that the **median outcome** in working in FAANG is much better than a startup, but you don't have the possibility of an **outlier outcome**.

- What are the success criteria after 1 year of pursuing entrepreneurship? (ideally, a revenue or user target)
- Are you trying to build some VC-backed or just an indie business? 
- Do you have a cofounder you like and trust?

One way to dabble in entrepreneurship is to build side projects. It's not that hard to build projects which get 10K+ users, as we talked about in [this masterclass](https://www.jointaro.com/lesson/OEuX0KMhcnNSTJ50Voee/masterclass-how-to-build-and-grow-tech-products-to-500k-users-for-free/).

I don't think you should make a decision on SDE 1 or 2 at this stage -- let the company decide that after they've interviewed you.

Keep in mind that your compensation (especially your equity) will be higher if you enter the company at a higher level, compared to getting promoted to that level after 1-2 years in the company. All else being equal, there is a huge benefit to aiming for the higher level -- and you have the Taro community and Q&A to ensure you succeed 😃 

When you talk to recruiters, my recommendation is to be vague about what level you were leaving Amazon, and also be vague about what level you're applying for. Most Big Tech cos I know will have a general SWE interview loop, and then the calibration committee will opine on your level.

Also remember that you only need one company to give you the higher level, and then all of a sudden, you have become the higher level. So if you get 5 offers, and 1 of them gives you SDE 2, then you can simply take that role. You have leverage during the job search process that you don't have within the company.

Some other resources on this: 

- Some thoughts on negotiation: <https://www.jointaro.com/question/kvNBGQ1FVXlxvcrI3yHb/i-got-a-job-offer-but-its-below-my-target-how-do-i-negotiate/>
- Senior folks getting paid less than a new person at a lower level: <https://www.jointaro.com/question/KsP9UPFvtHp06s6fWuo1/what-to-do-when-your-company-pays-more-to-candidate-lower-than-your-level/>
- Getting FAANG interviews: <https://www.jointaro.com/lesson/pIMdopWoJFfbANnzo7U5/how-to-get-faang-interviews/>

Kuan is exactly right. Our goal is to highlight the relevant experience and talented members within Taro Premium for companies that are actively hiring. 

If you're interested, you can join here: <https://taro.pallet.com/talent/welcome?referral=true>

Just to be clear, does SDE-3 refer to Senior Engineer? The terminology varies for different companies (see [promotions.fyi](http://promotions.fyi) for examples). 

For senior roles in Big Tech, there will still be a substantial portion of the interview focused on DSA, but you'll also likely get asked about system design. So you should come prepared to talk about the interesting tradeoffs when designing a sample application, along with some good stories about your experience building sophisticated systems.

Here's the Taro guide on prepping for [DSA interviews](https://www.jointaro.com/lesson/V4sTACzfOh22nMVcUV3w/masterclass-how-to-ace-your-big-tech-interview-data-structures-and-algorithms/) and [system design](https://www.jointaro.com/lesson/J3I9fTW9ulr6T9KjxpqY/masterclass-how-to-ace-your-big-tech-interview-system-design/). I'd also recommend going through the [system design playlist](https://www.jointaro.com/lesson/e9hQDgURiLYZC6l5MBDs/system-design-series-taro-playlists-part-1-what-real-system-design-looks-like/) where Alex walks through the details of an actual Taro feature. 

Finally, check out some of the discounts available in [Taro Perks](https://www.jointaro.com/perks/) which give you discounts to services like Neetcode and Formation.

Advanced applications are advanced because they package up a bunch of functionality in a clean, cohesive way. In some cases, the actual code you write has to be "advanced" in terms of clever programming or performance tricks, but that's usually not the case. 

Given this, since you've already built some basic mobile apps using kodeko, my argument is that you already have the necessary ingredients to build advanced applications. **Just start with an existing app and extend it**! Add more design flair, make specific use cases easier, or combine 2 disparate ideas in one app (e.g. *score keeper for pickleball*).

The other option is to observe how others build Android apps, and either contribute or copy them.

Alex open sources almost all the mobile apps he has built (and he's built more than 30!). Links to the most recent repos:

- Android: [**https://github.com/Gear61/ai-mentor-android**](https://github.com/Gear61/ai-mentor-android)
- iOS: [**https://github.com/Gear61/tcg-ios-archive-and-feedback**](https://github.com/Gear61/tcg-ios-archive-and-feedback)

I also have a few Android repos you can take a look at, like this Memory Game app: <https://github.com/rpandey1234/MyMemory>

Here's the masterclass on building meaningful side projects: <https://www.jointaro.com/lesson/OEuX0KMhcnNSTJ50Voee/masterclass-how-to-build-and-grow-tech-products-to-500k-users-for-free/>

A few things to consider: 

- How much clarity do you have on the promotion process at the company? If there's a lot of extra work required for promotion, you should have the conversation earlier to ensure all your ducks are in a row.
- Establish a "**date for a date**": in your next 1:1, mention a date in the future when you can properly dive into your promotion progress and feedback with your manager. This usually works better compared to springing a promotion discussion on your manager. 
- Make sure you have some durable record of what you talked about in each 1:1. This is genuinely useful to remember discussions, but also serves as the paper trail showing how close you are to promotion.

Resources: 

- [1 on 1 Meetings Are An Exercise In Proactivity](https://www.jointaro.com/lesson/ZPnCvmwqV0hqxJEr0kqh/1-on-1-meetings-are-an-exercise-in-proactivity/)
- [The #1 Thing To Remember With Meetings](https://www.jointaro.com/lesson/bgfN3YVJc82YrZSjOXgq/the-1-thing-to-remember-with-meetings/)
- [promotions.fyi](http://promotions.fyi) to see how various Big Tech companies do promo/perf reviews

*How* do they inform you at the last minute? Is it a private message to you, and you have to explain the delay to others and effectively handle the mess? If so, I'd encourage you to create a process where there is more accountability. 

The point is not to shame them, but to bring more visibility to project deadlines and what has slipped for future planning. Some options of doing this: 

- Review open items every as a team and have each engineer provide an explanation for what they had planned, and what prevented them from reaching the goal. 
- Ask the engineer to send out a "post-mortem" on what happened to the team/leadership. 

You're also asking (smartly) about how to minimize the overall impact. The answer here is that you need to make a judgment as the TL around who you trust to get things done, and where you need more buffer or redundancy. 

Trust is earned, and if you feel like this person is unreliable in delivering projects on time, you should either reduce their scope or have a "backup" engineer who can fill in as needed. This is something you should also discuss with your manager. 

As a former hiring manager, I can say that this would **definitely not** reflect negatively on you, assuming you have a well-rehearsed and polished discussion about how you spent the time. Two reasons for this: 

1. Assuming your projects are published and have users, your value as a candidate may actually go up! How exactly this is viewed will depend on the company, but broadly speaking, being able to come up with an idea, build an app, and actually attract users is great. And even if not, if you define this period as freelancing, I'd still count that as experience. 
2. You have the Amazon brand on your resume already. For a hiring manager, your profile is already de-risked in some ways since you've cleared the Amazon hiring bar. So you have much more leeway in doing something that may be considered experimental.

I'd encourage you to document some learnings when you're doing interview prep: an interesting technical challenge you encountered building your own projects, along with your (thoughtful) approach to product development.

Excited to see what you build -- ping Alex and me in Slack if you want feedback! [Here's the masterclass on building projects which actually get traction](https://www.jointaro.com/lesson/OEuX0KMhcnNSTJ50Voee/masterclass-how-to-build-and-grow-tech-products-to-500k-users-for-free/).

We've thought a lot about this. There have been many apps in the past which focus on pure anonymity. Blind is the most prominent example in tech today, while Secret and Whisper existed back in the day (I remember them being very hot around 2015/2016).

The issue is that, once you hit a certain scale, anonymity could create very bad outcomes when no credibility or reputation is staked on an interaction. That's why we haven't opened up anonymous answering.

Philip Su [explained this really well](https://www.jointaro.com/lesson/7ZWW01u4fFbJ9vjI5Wmu/why-he-built-and-shut-down-a-meta-internal-tool-for-pseudonymous-communication/) since he built an internal tool at Facebook which eventually got shut down due to toxicity.

There are good reasons to remain anonymous when asking a question: 

- if you have a sensitive question that may damage a relationship, e.g. a difficult coworker or manager
- if you're concerned about the optics of asking (IMO asking for help is totally fine! but if there is a stigma, we don't want to prevent people from benefitting from Taro)
- they don't think the answer depends on their identity. This is usually not true, knowing things like company/level/geography are really valuable when I mentor anyone.

I don't think you're in too much of a pickle. Here's how I'd frame this interaction: 

> I applied to this company already and would love to genuinely learn more about your experience - this will help me understand what rapid career growth looks like, and I'd love to hear about the specifics of this company.

This doesn't feel transactional to me at all, since: 

1. You are ideally open to a longer-term relationship, and you're sharing your own story. 
2. Even if you get the offer, there are many reasons why it may not be a good fit, so hopping on a 30 min call won't be viewed from a negative lens.

I agree with you that you shouldn't ask questions that are easily searchable, or anything which has a binary yes/no answer. Some of my go-to questions were: 

1. How formal is the interaction between engineering and design?
2. How are new frameworks/libraries introduced into the codebase? (e.g. Dagger, Retrofit, or Kotlin)
3. What is the company's view on in-person collaboration, conferences, and travel?

In my humble opinion, these are the top 10 resources I have on Taro.

Top 10 - Rahul

The best advice in Taro related to getting more done in less time 🕜

Productivity

The best advice for anyone trying to get to Staff Engineer or higher

Staff Engineer Growth

20 year tech veteran Daniel Tomko (11 years at Microsoft and 8 years at Meta) shares what most engineers get wrong when joining a new team, and what to do instead. 

This is a 4 part series filled with practical insight!