I wouldn't bring it up unless it explicitly comes up in conversation. Oversharing can hurt  as the company can use that information against you.

Employee @ Robinhood

Jonathan C

Just say you got into this program and it's an opportunity you really want to attend. You can see if you can work remotely for those days to help make things easier.

I just write whatever code is needed to move my projects forward. For example, I started taking on iOS since my team's low on iOS bandwidth. I get like 70% of the way there with most commits by myself, and just ask in the public ios engineering channel for help when I'm stuck.

You can put your meta internship on your resume you apply with next year.

When you get a rejected by a date, you don't walk up to them the next day with your next date and tell them that you should get another chance because your current date is equally as good. Rejections happen: it's just a part of life.

Can you try blocking out time to attempt a few refactors? Knowing how deep the rabbit hole is and how you'd approach it will better set you up for understanding how effectively you can refactor & how deep/shallow you're able to cut based on the context.

The only reason to put them all on is if they're all intern offers & you end up taking a leave of absence to do all 5 internships. Else, just put the one offer you end up taking.

It's valuable if you get paid and you're using somewhat modern technology. If you're doing it for free labor, you might as well do a side project though.

School generally lags far behind the industry, so it's hard to get the same ROI from school compared to a proper internship.

Just spend the bare mininum maintaining above a 3.0 & shift that time saved to find more internships, build more practical software through clubs, or to do some paid research for school.

What if I told you some people I referred I enjoyed talking to enough to the point where I offered to refer them? 🤔

Did you manually test the change before merging & deploying the code?

I went to a very lowly perceived university (for tech) and worked as a contractor and then at a struggling startup for the 1st 2 years of my career. It also took me 5 months to find my first job. I still got calls & interviews from big tech consistently once I got to the 1-2 year mark.

There's a mix of factors that gets looked at:

- Years of experience & what did you did in those years
- School (matters less as time goes on)
- Side projects
- Referrals
- Readability of resume

Honestly, the best way to get noticed is with a referral and a concise 1 pager resume that focuses on the business impact of your work & a nature of being proactive. Time is valuable & candidates who take less time to convince others of their skill are seen as vaulable.

If your application is not getting noticed, it means that you're focusing your resume on the wrong things. I'd recommend this [resume course](https://www.jointaro.com/course/get-more-interviews-write-a-stellar-resume-as-a-software-engineer/) to better align with the expectations of hiring managers.

1. Yes. If the project is urgent, shipping the project with more people is better than not shipping it at all. I'd frame to your manager thar you and the other senior engineer are not familiar enough with the technologies involved to ship high quality code in a time manner.
2. Focus on 1 tool/technology at a time. Try picking up sequence of tasks that focus on a specific tool/technology that you need to learn.

1. It's a very uphill battle to pivot nowadays. A lot of larger companies have been burned from hiring pivots, so unfortunately the big tech dream will have more friction (the hiring bar is higher, the bar for performance when you get in is even higher). If you worked a solid career in finance, you'll be scrutinized less (since finance is seen as respectable from the eyes of most tech recruiters). I'd imagine that mid sized companies (sub 1000) will give you the most yield: big enough to support interns, but small enough to still have a culture of taking chances.
2. You are viewed below undergrads and above bootcampers.
3. You need to ruthlessly prioritze (classic big tech term) getting internships and strong side projects. Internships are harder to get traction on without experience, so I recommend side projects first. The [course on side projects](https://www.jointaro.com/course/build-side-projects-with-500k-users-coming-up-with-an-idea/) will be very helpful setting up a baseline around what to do with side projects. [Devon Crebbin](https://www.linkedin.com/in/devoncrebbin?trk=blended-typeahead) also hosts regular [side project accountability hours](https://www.jointaro.com/event/side-project-accountability-hours-93912/). The general rule of thumb recruiters follow is: if real users aren't using your code, you might as well write no code.
4. The top candidates generally apply for internships the year before the target start date & most of these positions are filled up by them. The earlier you apply, the higher the baseline "perception" will be. I've heard a few folks are setting alerts for when new positions open and immediately applying to maximize this perception to their advantage.

The bar is much higher for software engineers coming out of the pandemic, but it's not an impossible bar. The focus should be skewed heavily towards writing practical code that is exposed to real users (either through an internship or side projects actively used by real users). This will be a tough balance to strike with school & you will likely spend a lot of time planning around how to use your time. Before things take off too far with your career transition and school, I'd take advantage of Taro events (office hours, coffee chats, side project accountability) to get a better view on what to expect.

I think your manager is getting pressured to PIP their reports and this project is being used to make a decision.

There's nothing much you can do about whoever's making the call to PIP, but Alex's advice covers what you can do to control your impact on the project.

Honestly if you're paying for Taro, trying leveraging the community first. There's events for interview prep fairly often & it's not hard to find someone else in Taro to pair up with.

Yeah it's fine to ask your manager for another mentor: I know someone at Meta who did that because they weren't getting along with their mentor.

(Note: I had ChatGPT ingest my taro profile, and give out this response)

Every engineer, at every level, has shipped a bug that made it to production. It’s part of the job. The fact that your manager and teammates aren’t making a big deal out of it should tell you something: **This happens. What matters is how you respond.**

### **1\. Own It, But Don’t Dwell on It**

You already **acknowledged the mistake**—that’s step one. No need to keep beating yourself up over it. Instead, **shift your focus to learning and improving**.

### **2\. Identify How It Slipped Through**

Instead of just feeling bad, ask yourself:

- What kind of test could have caught this earlier?
- Was there a gap in validation? Could a better unit/integration test have helped?
- Were there warning signs in the code review that you or others overlooked?

### **3\. Build a Simple Fix & Prevention Plan**

- If a fix is still needed, **prioritize it and make it right**.
- Then, take the initiative to **improve the process**—maybe by adding better test coverage, refining code review checklists, or automating something that would have caught the issue earlier.
- When you do this, it **shows growth and ownership**, which will impress your team far more than the original bug.

### **4\. Zoom Out—This Won’t Define You**

Your reputation isn’t built on **one mistake**—it’s built on **patterns of behavior over time**. Engineers aren’t judged by whether they make mistakes; they’re judged by:

- How they **respond to them**
- How quickly they **recover and improve**
- Whether they take **ownership and level up**

### **5\. Move Forward with Confidence**

Take what you’ve learned, apply it, and **keep shipping**. No engineer—no matter how senior—writes perfect code all the time. What separates great engineers is their ability to **iterate, improve, and move on**.

This won’t be the last bug you introduce. But if you use this as a learning opportunity, you’ll come out of it as a **stronger engineer**—and that’s what really matters.

Absolutely! It’s **not only acceptable but encouraged** to ask others for help—especially if it keeps you unblocked and moving forward. Here’s how to approach it effectively:

### **1\. Prioritize Your Manager First, But Don’t Be Stuck**

Your intern manager is your primary point of contact, but they **expect you to be proactive**. If they’re busy, it’s totally fine to reach out to others. Just be **transparent** about it so they’re aware you’re taking initiative.

### **2\. Start with Team Members Who Own Relevant Areas**

- If you’re stuck on a technical issue, **find the right person on your team who has context** and ask them directly.
- Look at past commits, documentation, or team Slack channels to **identify the best person to ask**.

### **3\. Be Thoughtful in Your Ask**

- **Be specific:** Instead of "I’m stuck," frame it as **"I tried X and Y, but I’m still running into Z. Do you have any suggestions?"**
- **Respect their time:** If someone seems busy, ask **"Is now a good time?"** or use async communication (Slack, email).

### **4\. Keep Your Manager in the Loop**

Your manager **won’t feel sidelined** as long as they know what’s happening. A quick message like:\
*"Hey, I had a quick blocker on X, so I checked with \[teammate\] since they worked on it recently. They helped me move forward!"*\
This reassures your manager that you’re being resourceful, not bypassing them.

### **5\. Balance Self-Sufficiency and Asking for Help**

- **Try to debug first** before asking—this shows initiative.
- If you’re stuck for **more than 20-30 minutes**, it’s time to reach out.
- **Watch how your team communicates**—some teams prefer Slack over direct messages, so adapt accordingly.

### **Bottom Line**

Your goal as an intern is to **learn, deliver, and integrate into the team**. Being proactive while keeping your manager informed shows both **Ownership and Bias for Action**—qualities that will help you stand out.

Crafting strong stories for an SDE2 interview is all about **clear impact, structured storytelling, and natural alignment with Leadership Principles (LPs)**. Here’s how you can make sure your stories are strong enough to pass the interview:

1. **Start with High-Impact Examples**

   - Choose projects where you **solved a tough problem, took ownership, or made a significant impact**.
   - If your story doesn’t clearly show your contribution or impact, it might not be strong enough.

2. **Use the STAR Framework**

   - **Situation:** What was the problem? Keep it brief.
   - **Task:** What was your role?
   - **Action:** What did you do? Highlight **decision-making, trade-offs, and leadership**.
   - **Result:** What was the measurable impact? Metrics help make your story stronger.

3. **Embed LPs Naturally**

   - Don’t force LPs into your story. Instead, **align your real experiences with principles like Ownership, Bias for Action, or Customer Obsession**.
   - Example: If you fixed a critical bug under pressure, focus on **Bias for Action** and **Customer Obsession**—why was fixing it urgent, and how did you ensure a long-term solution?

4. **Test Your Story’s Strength**

   - Would someone unfamiliar with your work **clearly understand your impact?**
   - Does it **naturally align with LPs** without feeling forced?
   - Get **peer feedback**—practicing with others helps refine weak areas.

5. **Iterate and Improve**

   - If a story feels weak, refine the framing—maybe the challenge isn’t clear, or the impact isn’t strong enough.
   - **Clarity matters**—don’t bury the key message in unnecessary details.

At the end of the day, **strong stories are simple, impactful, and clearly demonstrate leadership**. Keep iterating and testing them until they feel natural and compelling.

The window for up-or-out is 3 years, which isn't as bad IMO compared to the &lt;1 year generally given for E5s (senior) to land on their feet. Senior expectations is multiple times higher than mid level. The money is higher, but the expectations are even higher. I've talked to a few folks who are being pressured for not meeting senior-level expectations (often with a threat of PIP): it is very stressful and the feedback is ambiguous. (A lot of feedback at senior level and beyond at FAANG is very indirect because they expect you to be skilled enough to figure out the action items.)

If you get a high mid-level offer, take it. If you were underleveled, you will get promo'd very quickly.

Do you actually need to meet across a wider span of hours? You're doing it, but it's clear to me you're not thinking about if you actually need do it in the current way.

Do you need to do these things that are burning time out of your personal life in the way it currently is? What's stopping you from organizing your portion of the workstream around more standard working hours?

- Start writing code ASAP
- Start writing code ASAP
- Be proactive around trying to write production code ASAP and getting your manager to funnel things that can be coded to you

Code should be your #1 priority.

- If you are joining at mid level or below, your code output (speed and quality) will be scrutinized. If you fall below the average, you will be PIP'd.
- If you are joining at senior level or beyond, you do not want your coding skills to get in the way of other behaviors and responsibilities expected from you. If your code execution skills are the main blocker for achieving impact from the projects you worked on (there's a clear lack of speed and/or quality compared to other engineers), you will get PIP'd.

I'd say 2 ways.

- Show a clear mindset around shipping for impact
- Have a clear track record working with other "exceptional engineers"

The simplest litmus test is how easy it is for you to get a good referral and phone screen at &lt;insert names of current hottest tech companies&gt; (OpenAI/Anthropic/Perplexity/Cursor for our current AI boom). Exceptional people generally know other exceptional people, so it's pretty easy to get a strong vouch.

(I've even heard rumors that OpenAI believes this so such that they pretty much only consider referrals).

- You should be escalating to her manager too instead of only just yours. People generally don't listen to people not in their line of command.
- If she's so confident that the permission change isn't needed, why don't you have her make the change and have her write in the PR that permission is not needed? Assuming everyone in the company can see the PR, there's a clearer paper trail to follow if she's wrong.

My general advice for folks who are at the stage of building mastery is just write more code. There's many behaviors and actions that can help build more mastery, but writing code will handle the bulk of guiding you to the write learnings.

- If you need to learn something, you will be writing code for it at some point.
- If you need to be better at understanding and explanation a part of the system, it's easier to explain when you're written code for it (compared to if you've written less code or no code).

If you write better code faster, you also get more opportunities (both given to you and by better being able to identify them). The more opportunties you're able to execute on in a year, the more you will learn from them.

Short tenure's not an issue when it comes to finding another job, but you won't grow as much in a short tenure. Especially with RTO and geo-location, it'll also be hard to find a high-growth job if you're moving to somewhere that's not a major tech hub.

- If you're optimizing for career growth and keeping your job when you move, the Meta offer would have been your best choice (assuming you'll still be near an office after moving)
- If you're optimizing for WLB, I'd stick with Amazon.

Week 1: every intern is more or less trying to get a return offer, so I'd be more upfront for internship return offers (since it's more normal compared to something like a staff level promo).

My honest advice is just focus on writing more code. The more code you write, the more you have learned about what it takes to write code. Your slow velocity is because you haven't done enough reps writing code to have that subconcious base-level understanding. There's 2 things that will help building up the learning loop when it comes to writing code: space and velocity.

For space, focus on one task at a time. Start with the one that has the highest level or urgency and/or impact. Focus on that one single task until a PR is up. Then switch to another task. Do not switch off of that task unless something more urgent comes out.

For velocity, the main bottleneck for you seems to be getting help. So let's look to improve the process of how you get help to reduce the total time needed.

- If your question is more specific to a commonly used programming language or a framework and you're pretty sure the answer can be Google'd, ask ChatGPT.
- If you feel like your question is more towards proprietary code in the company, look through Slack (or the Slack-equivalent) and see if anyone asks a similar question. From my experience, there's usually a record of someone else saying something if the context is common enough.
- When you ask your questions, try to narrow it down to a "yes"/"no" question. The smaller the decision tree, the more likely you'll get help. If you have a guess on what's going on, include that into your question too.

Your best chance of getting into the US is to work at a big established US company. Immigration is a very messy and expensive process in the US, so usually only bigger companies are able to afford it.

For getting into these bigger tech companies, a lot of it will boil down to your experience. There's an initial downwards perception that foreign developers are generally weaker than the US-based talent pool, so you need to make sure your experiences, your narratives, and your coding skills are clear to your interviewers. That and the cost of the immigration means that the bar you're held by will be much higher.

As an middle path, you could just switch to a company that's based in the US but has offices in other countries. You can get in for a non- US based office and then transfer to the US office. This will require less upfront effort when it comes to immigration, but will take more effort overall.

I also wouldn't do a masters/phd at any school unless the company pays for me. The time and money invested is signficiantly less than the growth from just working hard.

The main thing I'd call out is mentality. A lot of the engineers I've noticed who are struggling/not doing as well are waiting for something to be given to them before they succeed. Unfortunately, nearly all opportunities aren't given and almost always requiring some action on our part to initiate.

There's never really any perfect circumstances, but there's always an opportunity to make it better. Instead of accepting the circumstances, look for opportunities to improve something you don't like. Then there's a clearer path towards painting a narrative that you're someone who's proactive about improving their environment, but your current enviroment won't let you improve things as fast as you like.

It's just sales and hype: a lot of it is just exaggreration to get people to use AI more so AI company evaluations and hype.

I tried using AI tools to write CrowdStrike QL and it was not super helpful. I don't know about vibe coding, but I spent the entire time complaining out loud how much it sucked.

Pretty much there's some spreadsheet somewhere that aggregates a few factors such as:

- bands for each level
- inflation
- what other companies are paying for similar engineering talent
- attrition
- your latest perf rating

And spits out a number. There's very little room to go for more pay unless:

- you convince your manager to try to argue for more pay without a rating change or a higher rating
- you have a competing offer much higher than your current compensation

For growth for compensation, the answer's pretty simple and a mix of:

- Get better ratings
- Get promoted more
- Get stronger competing offers

But if question is moreso "how do I grow faster so I can get paid more", you can check out the [mid level to senior level course](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/).

Recently, I've been learning through a mixture:

- Spamming diffs
- Running things through ChatGPT/Claude (to limit test how large of an ask I can give it, debugging smaller issues, more quickly parsing documentation)
- A little bit of pair programming

I was recently looped into an effort around reducing on the backend and I'm a bit out of the water since:

- I'm an Android engineer and I haven't done backend in years. I was the first (and currently only) frontend engineer to be looped into this effort.
  - The backend service my team owns manages payments (so the cost of a mistake is very high).
- I ended up getting tasked with some complex metrics query in a query language I wasn't super familiar with (CrowdStrike QL for humio).

My progress looked like:

- I put up a backend diff (unit tests included) within a day of me making the call to start putting up some backend diffs myself.
  - I cleaned up some code along the way. Also I took a few mental notes on how I can even further clean up the code if I have some spare time.
  - (The diff landed and didn't break prod!)
- I scheduled an ad-hoc \~30 mins IRL pair programming session with a backend engineer to figure out the query
  - After I built up some basics from working with this backend engineer, I started using a mix of trail and error and ChatGPT/Claude.
    - By the end of the next day, I had a bar graph segmented by hours set up for one of the metrics we were tracking (I even tweaked the query to discard the last hour since it'd potentially have incomplete data).

5-year of practical software experience is enough to get interviews at most companies with a recent resume. Just apply.

I just work here @ Robinhood

Don't jump on the latest trends. Focus on getting good at writing code in some modern language by quite frankly writing more code.

If you're looking for entrepreneurship, a PM job likely isn't that much of a jump. Honestly, being proactive at finding opportunities & convincing others is the better shift to make (and that's not really tied to any job).

Focus less on titles and more on what skills & behaviors you want to build & loosely rank them on how important they are for you. See if you're able to find opportunities to build those skills/behaviors and leverage your manager to help you opportunities as well.

Roles are just a string and there's not hard-coded fixed list of things that narrowly defines what is OK/not OK in each role. The control over the skills and behaviors developed in your career is what matters for progressing to your goals. If that results in a role/title change, so be it. **But don't be dependent on needing to switch to PM as a deciding factor to move your career towards entrepreneurship: doing so is 100% a skill issue.**

Since you're joining at mid level, the good news is that a lot of the momentum is coming from individual skill.

The main behavior I'd demonstrate to show that you're serious is being proactive.

- Don't wait to take up more tasks for your project(s): just take them.
- Someone has a question around your domain? Give them an answer and potentially some references.
- Code isn't as clean as you could be? Fix it along the way of your current task.
- Are there tasks on someone's else project that could be parallelized with an extra set of hands? Jump in.

Being close to E5 at Meta means nothing to your Anthropic manager: so you need to set the baseline that you're doing more than what's needed beyond E4/mid-level and that impression can be seen. If your manager views your baseline as an average mid-level engineer, they likely won't take you as seriously. Once that baseline is set, I'd look to the following two:

- Ask your manager for opportunities to lead projects to show senior-level compotency. If you really want the senior-level promo, bring this up every 1:1 or every other 1:1.
- While you're proactively poking around the broader scope of the company/team, see if there's any gaps you can help fill around existing projects when it comes to project leadership. Why wait for your manager to give you opportunities when it could be faster finding them yourself?

Before switching teams, do you know if other engineers on the team feel the same way? If it's just you encountering this level of friction, your manager sees the world like this:

- E6 with longer tenure with more equity is doing things the way they always do. This has historically had impact for the team/company/org.
- You (new E5) comes in and doesn't work well with the E6.
- You complain to manager.
- E6 gets paid more and has longer tenure =&gt; bigger risk to the team/org to disrupt them.
- Therefore, your manager will bias towards the E6.

In order for your feedback to be received, you need to put more weight on your side of the scale. You would need an E5+ in your org with tenture to also vouch for you. If not, your manager won't take any action.

Coming from someone who's in the position your E6 is, the main thing that causes me to more aggressively shoot certain people down is if they don't follow the same principles as I do. I'd look to figure out the following:

- What does your E6 value when it comes to engineering?
- What patterns does the E6 display when it comes to reviewing artifacts (code, docs, etc.)?
- How does your E6 view the world around them?

Once you figure those out, try to see if you can proactively incorporate those learnings into your workflow. Download your E6 and work with/around their behaviors. It might help to have your manager mediate in case you don't feel like your E6 will respond well.

(A few other misc notes)

- It's plausible that you might be taking enough scope to risk their E6 standing. If you feel like the friction they're putting is often amounting to nothing, start documenting these occurances and if they amounted to some changes.
- One key piece of feedback I got growing towards a TL was that I needed to shoot people down more.

A sprint is just an arbritrary construct to ensure some level of consistency. I'd focus less on completing the sprint and more on proactively calling out if the corners you're cutting should be cut or not. In the end, business impact is what matters the most if you want to judge the value of your work.

Yes. Depends on the mood: sometimes I go for more fast-paced music when I need to spam code, but usually I do a mix of city pop & random youtuber drama videos.

Yes. I had my role as Software Engineer (Contractor).

When I contracted at Pinterest, I just said I was contracting at Pinterest during interviews. Even as a contractor, the big tech name does attract eyes.

Let's start by looking at metrics and measuring impact with it since that was explicitly called out.

How would you prove your code actually did something for your team/company? 

Some line that the company is tracking is going up. That line is a metric. If your project helped the company, the line's slope goes up more. That change of slope is your project's impact.

For larger efforts, the main expectation is that you are able to disambiguate what needs to be done.

Right now, we can see from your question you're leaning towards thinking about it as one big thing. You've broken it down to a few sub items, which is a good step forward.

The next steps would be: how should the work be sequenced? Let's start with the first step: there's always a first step in the project. Out of the different things you need to do, what should be done first and why should it be done first? And are you able to break it down into an even smaller action?

That's a lot of questions, so let me start with one to help you move forward: what's stopping you from doing everything right now without needing someone else to carry you? Answer this question and see if you can narrow down on something from that answer that you can immediately do independently.

For general junior =&gt; mid level advice, I'd recommend:

- <https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/how-this-course-works/>
- <https://www.jointaro.com/course/grow-from-junior-to-mid-level-engineer-l3-to-l4/how-this-course-works/>

The best to understand a programming language is to write more code in it. Your diff count is the main metric used to guage your skill level. To repeat: **just write more code**. Anything else you can potentially try to do provides negligible value compared to getting better at writing code and landing diffs.

The main heuristic for junior engineers is diff count. If your count is low, you will not get anything above meets all. If you are an expert, it will show in your diffs (volume and quality will be examined, but volume is an easier step forward & more quantifiable).

- Dig into why your management thinks that this on-call is a high impact opportunity.
- Not every opportunity is tied to your role & and the highest growth opportunities beyond senior are often outside your role. Take an extreme ownership mentality: focus on potential impact that you're able to execute on and not if it fits the bound of your role.

Take whatever # of diffs you're averaging in a day and 2x the volume. A lot of code you're writing will be specific to Meta & learning outside of your codebase won't be as valuable.

Since your marriage is 1 year away, I feel that's enough for 1-2 attempts at switching jobs. Given your years of experience and your current job at Amazon, you should be able to secure mid-level interviews.

But the honest question you want to ask yourself is: do you really want to live in the Bay Area? The weather's nicer and all, but housing here is quite expensive and it's like 80% sparse suburbs. If you don't like the bay area, it's going to be a potentially expensive reversal (time and money). I'd start with having a ranked list of what you're looking for and working backwards towards what that maps to location-wise.

Are you always afraid when you're walking down any stairs that you're going to fall and get injured? Is your mind working in overdrive to figure out how to put one foot in front another?

(Assuming your body is perfectly fine) No you don't. Becauae you've spent so much time naturally walking and occassionally using stairs that you just do it.

It's the same thing with coding: just write more code. If you are actively trying to improve at coding, you will start spend less energy and effort writing code. With one less thing overworking your brain, you'll have more mental bandwith to focus on other things that need attention.