Should be fine: I usually sit with folks in a completely different org (I just happened to have worked on some products the org owns and have never been a part of that org officially). There has yet to be any complaints that I need to sit with my team.

Engineer @ Robinhood

Jonathan C

At Robinhood, I serve as a SME for money movements and debit card products. How I got there was:

- I joined early(ish), allowing me to work on many, many projects across the company.
- I effectively stayed on the same team for 4 years (and counting). This allowed me to watch the codebase and the product evolve over a long period of time.
- Every engineer on frontend that could take the scope as a TL/SME either quit or got laid off. By the time headcount was secured to get a senior-enough engineer to fulfill those responsibilities, I already had the trust, experience, and title to be a TL and SME.
- I had impact across multiple stacks. As an Android engineer, my main impact is naturally on Android. But I'm also the main BFF (backend for frontend) contributor in my org, an occassional participant in backend design review, an ad-hoc data analyst sometimes for projects & SEVs, and I've code-reviewed iOS a few times (with no iOS experience).
- I answer most product and frontend engineering questions within the domains I own. I also consistently have a pretty quick turnaround for answering questions.
- My overall commit and code review count is consistenly in the top 10% of all Android engineers. I write a lot of code, review a lot of code, and I'm usually fast with my turnaround for both.

To extract some tangible advice from my experiences:

- If you stay in the same place long enough, knowledge will naturally build up and the scenarios where domain knowledge is needes will come to you.
- Often times, what's complex and/or unknown can be good growth opportunties. You'll never always know everything in every scenario, so it might be more efficient to just embrace that. Don't proactively learn everything you can, but learn thing that better allow you to address business needs.
- Unfortunately, getting good at coding is a good action item for being a SME. Writing code better and faster means you'll have more time to flexibly use. Being fast also means you can tackle more projects, and being able to successfully deliver more projects relative to your peers means you've had more experiences and more impact (and the people around you will implicitly trust you more). If you use that productivity gain to write even more code, your knowledge and intuition around the code will deepen. Deep knowledge also compounds when you apply your mental models across stacks: I haven't written traditional backend code in years, but I'm participate in backend design reviews using the same mental models I have for building Android apps.
- Be helpful to people. Supporting people who need help with something you own helps reinforce domain knowledge, provides opportunities to identify implementation and process gaps, and builds people's trust and visibility with you.

Hope this helps!

1. Execution matters more than the idea itself: even if you pick an existing idea, people will still download it if there's a clear benefit to existing solutions.
2. Off the top of my head: try building apps for a niche community (a hobby, an online community, etc.)

I wouldn't treat a side project like working in a larger company: the focus should be on the execution of the idea not the archicture. Users in the end see the product and not the effort and process that went into it. Focus on getting clarity on the idea, figuring out the minimum set of features needed to use it, and then build it as quickly as you can. If you treat this how you would approach work, you'll likely end up stuck in the forest of ambiguity and ship nothing (either from eventually get bored/burned out at the fact that you're effectively working an unpaid job and you don't even get paid for wasted time).

At my previous startup, I was in the same boat. I was constantly trying to learn and apply best practices because the codebase I was working on wasn't great and the engineers took a slower, more relaxed approach to development. Ultimately, close to zero attempts to change the culture happened and I ended up leaving for greener pastures. While my scenario might not exactly be the same as yours, hopefully bringing in some of that perspective will help paint a clearer path forward.

How I (as a tenured senior engineer) would approach a world where things aren't great is to identify the problem as **1 simple truth**. When problems are identified as a single, simple truth, it's much easier to understand them and to align on them (less is more). If you provide a list, you will overhelm others. If you jump directly to executing this list of things, you're perceived as engineering for the sake for engineering (which reduces your social capital). From your description of the response to your changes, it's clear to me that you started with the list and not a simple truth. Develop the 1-liner statement first and get alignment on that statement. When asked to clarify, state both your perceived observations and the impact together. Bucket things into higher-level problem groups: again, simple truths are much easier to be understood compared to "here's a list of everything to fix". In your situation, you can try something like "Our legacy tooling and practices is slowing development down. I have observed x, y, z themes of scenarios in which this is visible".

Once you've aligned on the simple truth, then **identify what is the single, most impactful effort you can do to mitigate the problem**. This will narrow down the surface area of your changes, lowering the changes you need to make and how many new things other engineers need to learn. You also want to treat each effort as a risk. Every effort you attempt can fail by making it appear you made the status quo worse. If you reach a point where you've made multiple changes and ended with more unsuccessful changes than successful changes (your value is negative from making things worse more than better), you'll have no social capital and will likely get PIP'd/fired soon. Comitting to one thing also establishes focus: you won't need mental overhead to juggle competing priorities.

Once you're identified what effort to focus on, you need to minimize the blast radius of developers impacted by your efforts.

- The first step here is to **act as an owner**. Do whatever it takes to make sure you don't break builds and you don't break/delete existing tooling and processes: **whatever you do, make sure the boat doesn't rock**. It's incredibly frustrating whenever workflows change while working on a timeline (the tighter timelines are, the more frustrating it'll be). Every single issue that is potentially related your efforts, you need intercept and resolve them as fast as you can. This will establish that you're proactive as an owner and that you're not a boat rocker.
- The next step is to **start with 1 person**. Ideally you want to start with who has the most trust in the company, but anyone who's willing to test your efforts will do. (Relative to more than 1 person) it's much easier to be attentive to one person and to get a commitment from management for volunteers. Your goal with this one person is to sell to them that your efforts will (without a doubt) benefit their workflow. Do as many walkthroughs as needed to teach them, write all the documentation is needed for them to reference, and address every question/comment/concern/feedback they have. If they are clearly sold on the idea of your changes and have mastered them, then you can move onto onboarding more people.

Once that individual is clearly sold on your changes, look to onboard their team. Work with this individual to help sell the team on the benefits of your changes and help onboard the team to them. As a member of the team, their team will trust what they say (and that includes their vouch for you). After some reasonable amount of time (up to your discresion, have them fill a simple survey with a single yes/no question: are these changes an improvement to your current workflow? If less than 67% of respondents say "yes", iterate on the feedback of people who said "no" until you have at least that 67% ratio.

After that, it should be a relative breeze: onboard more and more teams onto your chages and keep surveying them to make sure you maintain at least a 67% ratio for people who are happy with your changes. Once the majority of folks who benefit from the change on onboarded, work with management to put a date to delete the old stuff and to move everyone onto the new changes. At this stage, there will be little to no questions: there's clear metrics around the benefits your changes and there's people who will vouch for you. The worst scenario for people now is that they are bregrudgingly willing to migrate.

Finally, you're done! Now if people want you to keep going, pick the next most impactful change and repeat the process starting at working with 1 person.

To compress this down to make it easier to extract learnings: you are probably in the right for taking on efforts to improve tooling and infrastructure, but your gaps are around understanding the people around you and your standing with them. Given their responses to your effort, you tried to directly replace existing tools/processes without direct and thorough consulation with ICs to build clarity, empathy, and trust in your efforts. For me, your current approach would only work if you were a tenured staff+ FAANG engineer in a company with 0 ex-FAANGs (then it's inefficient for everyone/anyone to fight your efforts compared to unceremoniously complying). The key lesson is that social capital impacts your ability to execute: if your name or resume doesn't immediately demand respect, then you need to build up social capital. The larger the blast radius, the more social capital you need. To avoid efforts with larger social capital needs (like company-scoped infra migrations), break down the effort into an incremental set of small steps. The process will be slow, but that reflects on how we (as humans) are generally slow to change.

If you're getting a "Meets most" with 2 years at FB (and I'm assuming you joined at a mid level), you have 2 paths forward:

- Go for an all or nothing hero mode play for a senior promo
- Look for another job
- (With a "meets most" in this economy, there's pretty much no chance for a team switch to be approved. Especially when you only have 1 year left to get a senior promo before facebook's up-or-out removes you.)

Even if you somehow hero mode into a senior promo, you won't be able to get to and then sustain senior level with a healthy work life balance. So I can see where your manager is coming from: assuming you joined at mid level, your more efficient path is to look for another job. But if you were promoted to mid level recently, then you'll have the time and space to try to recover next performance cycle. 

Learning in an academic setting is different than learning the skills needed to succeed at the job: the former works in isolation while the latter requires working in a broader environment under some amount of time constraints.

If you want to succeed as a junior engineer from a non-traditional path, the problem you need to solve is "how I do I succeed at my job" and not "how do I succeed as a student studying computer science". Work with your manager to establish clear expectations for your current level and your next level, your timelines targeting your next level, and the growth opportunities you're interested in. If you try to approach the real world with an academic/student mindset which biases towards hoarding/collecting classes, there will be a high chance of failure (imo). You need to work with the people around you and figure out their expectations for you. Only by understanding and working to meet/exceed those expectations will you succeed.

From the outside looking in, I see 2 things:

- Your tech lead is likely frustrated that you aren't meeting his expectations and isn't doing a good job expressing it
- You're getting pulled around and no one is setting the pace for the work you own

My guess is that the E5 might have planned the project around your ability to hit their expectations for E4, and you're missing those expectations (which is frustrating him). Given the scenario you described and your behaviors in it, there's some gaps I noticed:

- You are letting others drive the navigation of the project
- There's a lot of mentions of people saying/agreeing on things, but no mentions to how it's tracked

Building on this rough view, this doesn't feel (to me) like a scenario I'd expect a E4 to struggle with (and I'm extracting my guess of the TL's behavior based on this). At E4, you need to dictate the pace of the work you own by driving decisions, timelines, trade-offs, and alignment for the work you're implementing.

Given how there's competing deliverables and a lack of alignment, there's clearly E4 scope in my eyes. I think the main behavior change that needs to happen is driving alignment. There's 2 parts to this I'd recommend you to focus on:

- Whenever teammates/xfn staleholders aren't aligned about the deliverables you own, you need to be the one who's in charge of the decision. You need to be the one getting everyone together to make a decision, identifying and looping in the right stakeholders, and creating & leading meetings to get people to talk (and making the call if things need to go that far). If your manager or TL are the ones who frequently end up leading the discussions to clarify your work, you'll likely trend away from E4.
- Document decisions. It's one thing to get people to agree on things verbally, but it's another to have proof that they did. Whenever these discussions happen, have at least 1 person taking notes (or be the one who'll volunteer to take notes). At the end of the discussion, repeat the key decisions to double check that everyone agrees to what was said. After that, publish those decisions in the project channel (the more public the better). If you don't feel people will have confidence in what you say, get your TL or EM to post for you. Since your TL is the main point of misaligment, try having them post these updates. This way if they question what you're doing/prioritizing, you can pull up a post of them publicizing the decisions that led to your current priorities.

Hope this helps!

As you get towards the more senior side of the ladder, the bias/preference for the expected impact actually leans towards problems than specific tools. Tools are simply a mechanic to solve problems, and don't provide any inherent value when used in isolation. Let's say I have 1000 hours: I could build a heavily polished AI-based dating app for cats or I could work for a fast food job for those hours. Generally, the fast food job will net me more value because the cat dating app provides no purpose or value to enough users where a growth/monetization plan can be executed.

If you feel like AI can solve the core problems you or your team face at work, then there's a clear problem space that can be addressed by becoming more of an AI engineer. Else, you're just giving into FOMO and wasting time that could be used to build up engineering fundamentals (communication, xfn leadership, domain knowledge, coding experience). Fundamentals will carry over with time, but anchoring yourself on specific tools or technology will not.

Building on top of the existing advice, I'd also recommend that you start narrowing down on where you're publishing your paper trails at. Often times, if there's no visibility (no easily accessible public artifacts like comments on tickets, design docs, documented weekly updates) on what your process/progress is, your broader stakeholders will often assume the worst case scenario that you're slow and inefficient. Try to identify how you can communicate/document your progress in a more public manner: whether it's by posting regular comments in tickets, asking more clariying questions in public channels in your company's internal messaging app, or providing more granular updates in standups. This will also benefit you individually in the long term as information you've encountered in the past will be more readily available to you (and anyone else who's interested), allowing for a quicker turnaround time when you need information from the past.

You can expect the higher/highest end of the junior band: generally, a PHD is required if you want to start out as mid level after school.

As an entry level SWE, you unfortunately have no influence: your skills and compensation are not at the point where ignoring you will clearly turn out to be a costly mistake. In this scenario, there's 2 ways I'd look to proceed:

- You need to find someone who has leverage (either by role, seniority, and tenure) and have them consistently support your concerns. While you don't have influence, you can leverage theirs. If people trust your opinions when this more influential IC backs them up, that trust will trickle back to you.
- You need to align with your manager on your concerns on the project and the risks of not addressing them. If you aren't able to consistently document your concerns with your manager, call out the risks, and document the final result of the team not addressing those concerns, your manager's view will be that your delivery is terrible.

(Assuming US) If you're getting RSUs that can be sold in a public market directly, it works like this:

- Every vest, a % of your shares are withheld for taxes (this applies to your paychecks as well). The default (and the usual minimum) I see is 22%. So if you do nothing, 22% of your compensation is likely going to taxes proactively.
- You able to change the withholding amount for your RSUs on the platform it's granted through. Keep in mind this can only be changed during certain time windows (usually right after earnings). You can bump this up to 37% (this is the maximum you'll ever have to pay in taxes).
- At the end of the year, you pay (amount of taxes the IRS expect) - (amount withheld). If you overpay, you effectively give the government a 0% interest loan for what you paid extra. If you underpay, the government is effectively giving you a 0% interest loan on what you owe. If you underpay too much, the government will charge a small interest % on top of your missing taxes.

Generally there's an unspoken limit of 16 days, but how strictly unspoken limits are enforced are highly dependent on the company culture around PTO (e.g. if everyone else is taking 20 days off a year, you should too) and your current performance in the company (if you're at least meeting expectations, PTO is less scrutinized). Your manager and your teammates would likely have a pretty good pulse on this, so I'd look to ask them to guage more specifics.

You don't really need to bother posting on linkedin unless there's clear value for your brand you're trying to build through social media. I personally post on linkedin every day trying to connect with Mr. Beast to only satirize how linkedin is mostly filled with low quality influencer content.

For my current skip, the conversation for me feels like a dynamic where they're giving me trends/direction from broader leadership while I'm providing trends/direction from the IC level (for example: my main focus with manager 1:1s has been pushing for the platformization for Robinhood's payments experience & creating the space to define what successful platformization means). I think ancedoctally for me to get into this position, I was able to provide a fairly nuanced view as an IC backed by years of domain knowledge in the company/product.

Extracting my anecdotal experiences into advice, I'd say the main thing is to look to provide your manager an on-the-ground view of what's happening. Your value as an IC is that your high level view has grounding in what's building it and who's building it (whiles managers hold more of a high level view and rarely/never have to dive deep into the weeds of coding with other people), and you should use that to support the M2 define the direction of the team (in a way that balances the health of engineering with the health of the business).

If your goal is to increase compensation and job security, the best path forwards would be to start interviewing and look to secure other offers. Within your current situation it seems like the variables you want to budge aren't budging, so if you want something to change you need another offer on the table.

No one's really that safe from layoffs in this economy, but big tech does have larger war chests. So Amazon's not that bad of an option if you just want to settle on a job that's relatively safe.

(To provide an anecdotal data point to the scenario you're running into, I got my senior level promo with a first-time manager)

Getting a new manager who's new to management leaves a fairly unclear path, especially if you're a mid level trying to grow to senior. You mention that working with these managers are often times stressful and unpleasant for you, but why is that so? Are there any common patterns around behaviors you can provide a general summary for? I would go through this exercise and then talk to your skip manager about your past experiences with first-time managers and talk to them about the common themes you're identified around why those experiences weren't great. You can also look to talk to your skip around what support is being provided for your new manager: getting a clearer view around the support system for your new manager might help give you some relief that your new manager isn't just going into management blind.

Can you look to provide some examples of scenarios in which you feel the team is not communicating better and where you feel the gaps are? While this is a not an usual problem, there's definitely a lot of contextual nuance that impacts how to approach the problem.

(I've reported to M2 twice: once as my official direct manager and once when my manager left the company and I needed a temporary manager)

From my conversations with M2s, I was able to get much a much higher level view of what the direction of the org/projects look like and what were the broader problems in the org and product. I felt like I was able to come out of those conversations with a much broader and/or deeper view of what's next, which made it easier to adjust my line of thinking for the future to match the direction of my org.

Since your current position puts you in a spot where you have to fight for E6 scope and your skip manager seems to be on board with supporting your growth to E6, reporting to your skip manager feels like a strong path forwards. This puts you in a more direct position to get a view on the org and will likely provide you opportunities to tackle org level problems.

Hope this helps!

As a junior engineer, a lot of your contributions to those documents are just going to be questions (usually along the lines of "why did we do &lt;x&gt;", "did we consider this alternative", "did we consider &lt;y&gt; alternative"). It takes years of nuanced experience to properly give feedback, so I wouldn't worry too much about providing good feedback. Focus on executing on your existing work/projects, take up increasing broader ownership, ask questions along the way: you'll gradually build up to foundations to provide more nuanced perspectives on those docs.

For design docs, what I usually look out (as a frontend engineer) for is:

- How cleanly is the doc broken down: is it clear that I can indepedently review pieces of the doc? Is it clear how the project is broken down into subdomains, milestones, etc to allow for clearer separation of concerns, parallelization of workstreams, more granular incremental rollouts?
- What schema changes are we making to APIs. Common questions I'd have is: how flexible are these changes for future products, are these changes backwards compatible, and if logic is shifted to be on the other end of the stack does that simplify the design.
- How granular is the business logic broken down. Generally, I use the design docs as a heavy reference for how I write code, so the less thinking I have to do to map the doc into code, the better.

For OKRs, it's more nuanced and vague: a lot of it comes from working backwards from what domain(s) the team owns and what problems the team is currently facing. Another part of it comes from experience on what OKRs did/didn't work previously for the team (or for previous teams engineers were on). I can give you my view to provide a starting reference for thinking about OKRs as a senior product/frontend engineer.

- A team should have between 1 and a handful of metrics they're driving to be bigger. Products generally drive users to behaviors that positively influence the business, so the team should know what causal chains they can/want to influence within the realm of the product.
- I'm not a big fan of having a flat goal as the top level goal OKRs (i.e. "10m new signups in 1 year", "+$50mil for revenue in 1 year"). Quantifiable goals are great for establishing a baseline to relatively tracking progress, but often times external factors can drive teams to be closer/further away from numerical targets (example: for 2 years, my team hit goals despite shipping very little at all). So I like structuring OKRs like "Our goal is to do &lt;x&gt;. We plan to do &lt;x&gt; through &lt;y&gt; projects, and we project &lt;z&gt; metrics to change" and pushing the team to focus on doing &lt;x&gt; as a goal. This way, the team is more focused on the goal rather than trying to think about hacking the last bit of value to hit &lt;z&gt; metrics.
- When thinking about projects or OKRs for the team, time should always be considered: more specifically, time to execute. Is the time to execute something the team is comfortable with? Are there clear bottlenecks in development present across every project? If there are clear bottlenecks, incorporate projects to tackle those bottlenecks in the OKR doc and call out how those projects will help the team in the future (depsite usually not generating any immediate ROI).

Hope this helps!

As for your concerns about your growth and your career: thess is an opportunity you're clearly excited about, there's a comp increase, and the company is able to hire tenured talent from other notable tech companies. Just take the job: what determines your career growth is less about the companies you work for, and more about the behaviors and fundamentals you develop throughout your career. If you want to make sure you'll have the support needed in the new company, work with your manager to have a clear growth plan and maybe even find a mentor who's willing to take you on.

Android Engineer @ Robinhood

Congrats on the new job! It's great that you're excited about the opportunities ahead and proactively thinking about how you'll hit the ground running. 

Unfortunately, planning too far ahead (especially without reputation or a clear structure with the team/company) won't end like you'll expect: it's very likely that you won't be able to execute on that plan at all (either due to the company putting you on previously committed priorities or because you don't have the reputation needed to get traction on suggestions). This is a wrong turn I've personally taken down and a common one I've seen among junior and mid level engineers. The more detailed you are with things without a nuanced grip of team/business context, the more likely you will fail and waste time for little yield. Things are constantly changing in any healthy team/company, and attempting to force structure into something preestablished will not work. If you fight against the natural flow, your time and energy will be spent for little value and the current will probably just plow you over (aka your manager or TL politely tell you to work on some other task/project instead). Don't get me wrong: the things you are proposing are nice and generally good things to do/have, but the question is: does the team/business actually need these things right now? And are you even the right person to solve it?

If you want make the best impressiom you can and build a healthy path for senior, the main recommendation I have is to start out by being more passive and progressing with the flow of the team/company:

- Be thorough with your onboarding tasks and projects. Ask questions around the tools and frameworks used in the company, and try to clearly understand their interfaces and why the company chose those tools/technologies.
- Oberserve the people on your team and on your projects. Who is on your team? What responsibilties do they usually fulfill? How do they behave when they're interacting with different stakeholders?
- Instead of introducing solutions and trying to find their problems, observe the problems and then fix them. If there are any technical/process gaps you've observed during your onboarding that you have the exact experience at that moment to efficiently fill them in, look to fill them. If the team has a problem with writing tests efficiently and you have experiences with a framework that solves that problem, introduce it. If your teammates have a hard time chasing xfn threads, own driving some xfn discussions into clear action items or outcomes. As a senior eng, I will say this is most important thing that makes or breaks if you're perceived as a senior eng/lead: it's very easy to tell the difference between a junior/mid-level engineer who's trying way too hard and thrashing around and a senior engineer who's passively identifying and resolving issues they encounter.

Do you have metrics set up quantifying the value that you're bringing? If your team's goals is to save customer support time, it might be helpful having metrics around the time needed for customer service to onboard a new feature. Once you have that value, you can multiply it by the dollar average a customer service agent gets paid to paint a clear picture.

Another line of thinking might be you're trying to get acknowledgement from the wrong crowd: engineers generally don't have that much visibility about support, but the folks on support who are using your tools would. If you get acknowledgement from customer support leadership, that might help get acknowledgement from the engineering side.

It's a bit hard to have a complete grasp given the vague description, but it seems to me the scenario is that they're unhappy with your velocity and they do a terrible job expressing themselves. If you aren't the only person the project lead is overseeing, you should ask your teammates privately how they feel about your project lead's behaviors. If there's a general negative sentiment that can be documented, I'd look to talk to your manager about your project lead's behaviors.

This is a great opportunity for growth for a more experienced engineer, but as a new grad this is unfortunately an opportunity that will inhibit your growth in the short term. Since you're at the beginning of your career, you need a stable environment to build up your fundamentals as a professional. There are things you can do though to push for a better situation:

- I would voice your concerns to your manager that there's instability in the team due to a lack of domain knowledge and tight delivery timelines. I'd push the recommendation to your manager to push back on the timelines and to look into having a team lead (either by empowering an existing report or by getting one through an internal transfer).
- If you feel like there's information gaps around things your team is doing repeatedly, write things down on a public document and share your notes with your team! This might even push other teammates to do the same, creating a stronger knowledge repo.
- Building on ^, one of the main ways I built up domain knowledge in a critical domain in Robinhood that had no stable owners was that I'd help people. I tried to answer as many questions as I could about my team and the products I owned, I'd provide advice to help others debug, and I'd loop in the right/better owners if I couldn't help but I knew who could.
- Worst case, you can look to transition into a team that's more stable and with work you're more interested in. Generally, the expectation for an internal transfer is that you need to be meeting expectations at your level on your team. I'd start thinking about this option around 6 months into the job.

Hope this helps!

I'd follow this format (from top to bottom):

- Work experience
- Side projects
- Skills
- Education

As a new grad, having a limited resume is fine. A lot of your time was dedicated to school, so it's fairly hard to find something meaty enough to properly fit on a resume.

The general steps I follow are:

- Write small pull requests. Smaller pull requests are much easier to read for everyone, making the overhead with interacting with the diff lower. Reviewers can provide much more narrow feedback, you're much more easily able to write focused tests, and it's much easier to infer context from the code.
- Write detailed summaries on the pull request. This usually varies based on what the pull request is for, but I do a mix of: linking project specs (and designs if it's for the frontend), writing a test plan, explaining how I arrived at the current code for the diff.
- For any pull requests that touch code, write a test plan on how you tested the code (manually, existing tests, new tests, etc.). If you cannot perform any sort of testing, explain why the changes can't be tested.

tl;dr pick any language/framework/platform and stick with it. The skills will naturally come as you get more experienced.

If you're at the phase of your career where the one of the main questions you have is what tech-stack/framework to use, the general & narrow advice I'd give is to focus on any 1 tech stack. Learning how a framework works takes a lot of cognitive overhead (and the domain knowledge is generally isolated to that framework) and learning multiple new frameworks means that you're incurring this overhead multiple times. Repeatedly operating in the same framework allows you to eventually thinking less about the how the framework works and think more about the nature/quality of your code and why the framework is designed the way it is. Once you have a strong baseline of writing code in that framework, you're able to leverage that as baseline for understanding how other frameworks, tools, language works. As you grow more experienced, you can find yourself building soft skills around this baseline since your understanding of the framework serve as a baseline for how you communicate technical details in an abstracted manner (for non-technical stakeholders).

Hope this helps!

In this economy, the power dynamic is in favor of the company. Especially since you're working in Amazon, the only way you have a chance of getting a retention offer is if you have a written offer letter from another company with signficantly higher compensation. Having this offer letter in hand is very important: if you bluff it, the company will simply ignore you and might end up treating you as a flight risk (so they'll try to manage you out).

I'd break the conversation down into 2 buckets:

- What projects can you work on
- What behaviors are expected from you

At L5, you need to demonstrate that you can own projects end-to-end independently (through a mix of technical leadership and/or raw code volume). Every team/company has different expectations on what that looks like, so it's important to work with your manager to figure out what projects you're able to own and how to execute on them.

From my experiences, companies (at a high level) will ultimately focus more on the deadline versus the quality of code itself: deadlines can be treated as binary, while code/product quality can have a lot of nuances in the discussion (which a lot of upper management stakeholders aren't either equipped or don't want to handle). As the tech lead (not on the upper rungs of management), it is your job to own quality & velocity and abstract way any nuanced concerns away from upper management (and provide them simple, clear action items if there are).

For your scenario with the junior engineer, I have a few thoughts:

- If your peer/colleague is in a position to judge the code of the junior engineer, why not pair them up together? This way you can set up the junior engineer to better learn about writing quality code without having to oversee them yourself.


- What does the test plan of their code look like: is the junior engineer writing detailed test plans or writing exhaustive test suites (unit, integration, etc.) ? If the junior engineer is doing neither, I would block their PR until either condition has been filled.
- How big are the junior engineer's PRs? Code gets exponentially hard to read or judge with more lines of code, so breaking up code into smaller PRs makes it significantly easier to give nuanced feedback.
- Do you have regular 1:1s with the junior engineer? This would allow you to create the space to support them: either through actionable feedback or pair programming (like you called out).

Asking system design directly in a manager call isn't something I'd recommend doing: it'd likely create a weird dynamic since you're trying to assert dominance on the manager when the dynamic is in clear favor of the manager (since they're the one hiring). If you want the discussion to be technical, focus on asking the manager high-level questions about the technical challenges of the org and letting the discussion naturally flow to higher or lower level discussions. Questions like:

- What was the hardest technical problem your org has recently solved? What made it so challenging?
- What are the technical problems you're looking to solve within this half or this year? How does the org prioritize engineering projects on the roadmap?

would be good. You want to get the manager to talk about their org and what they own & see if the technical problems the org is facing interests you. If you want to make a good impression, focus on showing that you can hold and guide a conversation and not on trying to IQ test the other person.

Maybe we can select the right approach by working backwards from your offboarding plan. Do you have a rough estimate of how many people you'd need to offboard and how thorough your knowledge transitions are? You could look to ballpark a time estimatr for that and use that to figure out your path forwards. In the end, 2 weeks is just a loose custom and you're able to leave whenever it's most comfortable for you (I assuming you're in the US with at-will employment).

Well aren't most popular products like that? Even though they're dominant in their product domain, they weren't really first. Maybe you can look to take an existing app someone else built, see where the issues are, and just built your own version that fixes them?

My previous company went though a similar phase when we went through an agile transformation: I ended up just saying "42069 story points" every time an estimate was needed from me. Eventually, people just caught on and left it alone. This definitely won't work for your use case, but maybe you can overestimate your story points for each task to bump the number higher. Or if you're feeling risky and want to throw some satire in the mix, you can give yourself 1 single simple task (like a copy change) and assign it a large amount of story points (like 50000).

At Robinhood, we have a mix of screenshots tests, unit tests, integration tests (powered by Selenium), and manual QA.

While all those different testing frameworks are very valid approaches to improving test coverage (and quality), I think you should identify what is the single, largest you're looking to address by introducing new testing paradigms/frameworks. All of those avenues take a significant amount of time to introduce and to support: introducing all of them within a timely manner will drain a significant amount of resources in the short to mid term (an immediate block of focused dev time is needed for the implementation to be successful) and will lower the overall velocity in the long term (more tests needed per commit means slower turnaround for code to be landed).

If you don't have a clear understanding of the problem you're trying to solve for the business, then you'll likely end up hurting the business (if successful) or your ideas will get shot down since it isn't clear how the proposals will be a net gain for the company. I recommend loosely computing the yield for every testing practice you wish to introduce (benefit to the business / time needed to implement) and then pushing the 1-2 practices at the top of the list.

Hope this helps!

You are not obligated to bring up your pip and there's no way for your new company to know unless you tell them. Just give a vague answer that your old job wasn't a great fit.

Generally once you're in a fairly notable large tech company, getting an MBA won't get you that much yield as an engineer. The skills needed to grow and promote you don't align with the MBA program and will potentially take a significant amount of your time, which makes you more susceptible to [Meta's up-or-out](https://www.jointaro.com/question/X3ccTVVCpuS1T76HI5fX/how-does-up-or-out-work-and-whats-the-transition-generally-like-for-e3-greater-e4-greater-e5/).

If you want to grow faster, you should look to work more closely with your manager to fine-tune your growth plan or find strong mentors/role models that you can emulate. If your immediate goal is to get to senior, there's lots of resources on Taro and a [Tech Lead & mentorship event tomorrow](https://www.jointaro.com/event/tech-lead-mentorship-mastermind-groups/) that might help paint a clearer picture of your growth.

I'd say it's a mix of them being able to sustain their current level and finding enjoyment in their side projects (Alex also explicitly took a lower level at Robinhood so that he could have more time to take things on outside of work). My post really isn't about characterization fixed paths, but about identifying goals. If you do not have a clear goal in mind for taking on side projects (besides just wanting to do them), then you'll likely won't make signficant progress on your side projects and won't really have that much to take away from the experience.

For the new company you're joining, have you looked into talking to ex-employees (assuming the company doesn't NDA)? This might help you get the perspective you're missing.

If you're happy at your current company and they do counteroffers, have you considered letting your manager know about the offer and giving them a chance to counter? This way you get to keep the comforts of your current job but have higher pay.

It depends on what your goals are with your time.

- If your goal is to get the most enjoyment building software and you're not getting much enjoyment from work, do just enough to consistently meet expectations from work and focus your spare time on side projects.
- If your goal is to maximize your income, learning new things with side project won't provide that much value (unless you have an idea that has a clear path to monetization). Learning new tech can give you a better perspective on software and give you some nice hits of satisfaction when you've built up decent mastery over new tools & libraries, but often times it won't carry over to your day to day job (since the main bottleneck is convincing others the investment is worth the time).

If you want a midway-ish balance, you should look to identify bottlenecks in your day-to-day work and look to learn technologies that might mitigate them. Especially if your coworkers are experiencing similar issues, you'll have a stronger case to explore certain tools and technologies.

My high level view of your situation seems like the system the product is built in isn't sustainable, which is bleeding into developer bandwidth which then means that developers have less bandwidth to deal with customer concerns.

I don't have the full picture (since I'm not directly in the weeds with you), but have you looked into fixing the issues at a systemic level? If escalations and SEVs are happening frequently to drain developer bandwidth, there should be enough data for some common themes to be extrapolated. Especially when customers are dropping because developer bandwidth goes to responding to these issues & not into feature development, then there's urgency from the business side to recitfy systemic issues (since the raw $ value of the lost customers can be quantified & we just need to sum them up).

If you've already taken attempts to identify and scope out fixes to systemic issues without any support from management, then I'd say you should to switch teams or companies.

If you don't have the motivation to grow your career and you're comfortably able to sustain your current level, maybe you should look to find a hobby that'll motivate and fulfill you outside of work. Even though careers are generally a big part of our lives, it doesn't necessarily have to be the only thing in our life. Senior level at big tech pays very handsomely, so perhaps you can use that to give yourself the flexibility to explore.

For an ancedotal story that might give some perspective: when I joined Robinhood (when it was \~500 people and was one of the hottest startups at the time), I had a coffee buddy with a very senior Android engineer and one of the conversations we had was around career goals. He mentioned that at this point in his life, he wasn't really as passionate in software engineering and that he was only in it still because the pay was really high. He also mentioned that if software engineering didn't pay as much, he'd gladly pivot to another profession that would.

Based on your rough description, it seems like the ballpark is midlevel. So I'd set that as your target baseline. You should feel free to apply for senior though (if those are the only open roles) and see what happens: usually, big tech companies give you a +/- 1 level range for roles.

If your goal is a full-time return offer, I would look to be explicit with your manager around the expectations for a return offer and look to see if they can define behaviors and milestones they expect you to meet during your internship. Every 2 weeks - 1 month, I'd skew the 1:1 conversation to get a sense of where they think you're trending. If you have a mentor, I'd look to lean more on them for tactical feedback (if you don't have one, get your manager to pair you up with one).

There's a lot of variance between the expectations of each level between each company, but this is the general guideline I follow.

- Junior engineers can execute on code indepedently, but need support with breaking down and defining tasks.
- Mid level engineers can execute on parts of a project indepedently: if someone tells a mid level engineer to "build x", they will be able to build x with little to no handholding.
- Senior engineers own projects and are expected to be able to lead projects to completion with little to no oversight.

Hooe this helps!

The framework I usually operate on is "strong opinions, weakly held":

- As a senior engineer, you need to break discussion stalemates to move the project forward.
- Often times, people don't exactly disagree in discussions (so they're fine with most/any reasonable outcome, but don't really want to say it) or they don't even know where the discussion should begin.
- So that's where "strong opinions" come in: you need to be ready to put your opinion down to serve as the starting point. Although you need to put something strongly down, you should be explicit about what specific details that helped you formulate your decision as you vocalize your opinion. This is so the broader group can understand how you arrived at your line of thought and see where they should/shouldn't be building on. Once you've done that, you should end with asking people what their thoughts are.
- This is where "weakly held" comes on: you need to pull input from other participants and keep the discussion going until the group has arrived at a consensus. It doesn't matter if the final outcome is completely different from your opinion, someone else's opinion, or something completely new that was thought of mid-meeting: you are simply a conductor to drive people into agreeing on something reasonable.

As a big tech worker (or least working in a company that mainly hires from big tech), I don't think I'm particularly smart. I got B's and C's in high school, went to a fairly bottom tier college, spent most of my life until junior year of college playing Maplestory, and took \~5 months to find my first job.

Reading over your question, it seems to me that you feel like there's a gap of technical and domain knowledge between you and your coworkers. If I'm indeed interpreting the question right, then I'd just put yourself in scenarios where you're interacting with coworkers more. More iteractions means that there's more oppotunties for their knowledge (domain and technical) & frameworks of thinking to stick to your mind. I'd recommend a few things.

- Review more artifacts such as code reviews or design reviews. In these reviews, ask questions on why things were designed in that particular way or if another specific design as alternatively consideted.
- Ask more questions in meetings. Similar to reviewing artifacts, look to ask questions when something is unclear to you (why did we decide this, have we tried doing x, how do we imagine y to scale when z conditions happen, etc.). You obviously don't want to ask too many questions to avoid slowing down the meeting, but if you ask a small amount of short, focused questions every meeting people will generally be comfortable answering those questions.
- Find a mentor. In big tech companies, there's generally a lot of experienced engineers who are willing to help mentor and grow others. See if your manager can pair you up with a more senior engineer who can help provide the information and support you need to be more productive.

Hope this helps!

I have a few loose recommendations around execution:

- Whenever you're given a feature, I'd recommend breaking it down into smaller milestones that can be demo'd indepedently. Give clear time constrained estimates for each milestone (make sure to give yourself more buffer as the milestones are further away): estimates will be tighter the smaller the scope and the smaller timeframe of milestones allows you slip in more time/buffer with less scrutiny.
- See what parts of the feature can be parallelized: instead of doing everything at once, can some parts be done independently from the other? Are we able to build the Angular frontend on a backend that's returning stubbed responses?
- Be defensive of your time by opting out of meetings you feel like you're not actively participate in or by reducing the frequency of recurring meetings you need to be involved in. You'll save time with less meeting and save time by having to context switch less (from my experience, a signficant amount of momentum for coding can be lost with a badly timed interruption).

Outside of execution, it seems me the problem is that your manager has been pressuring you to ship faster, but doesn't have a clear view on why you can't & is not proactive with setting you up for success. This is leading to clear stress and frustration on your end, which is making you less likely to ship in a timely manner. I'd escalate to your skip manager (manager's manager) and tell them how your manager is putting pressure on you in an unhealthy way. You can likely get the feature out faster if certain conditions are met, but is doing so meaningful to you or the company in the mid to long term view? And is it worth the sacrifice of shipping faster for a potentially much more brittle feature (and ownership of said feature)?

Hope this helps!

It's impossible to completely avoid last minutes errors for every project: we often don't see bottlenecks, bugs, and/or errors until we're knees deep into implementation. This is a reality that every lead/owner ends up having to eventually accept, but we should always analyze the nature of how the error came about to avoid similar issues for the next project. For your particular scenario, the breakdown of questions I'd have would be:

- **Could this bug have been caught and prevented earlier?** There's generally multiple layers of process in a project that we can catch issues in: design review, code review, unit tests, intergration tests, bug bashes are the main ones top of my mind. Looking at the bug and the state of your company's software development process, could this bug have been caught in an earlier part of the software development process? Could processes be introduced or better improved to catch these issues?
- **Were there direct controls that were planned around that would derisk the migration?** Migrations are always risky to perform: one overlooked piece of business logic in a migration could lead to a different (often times, broken) flow of code for customers, so there should always be controls & rollout plans to mitigate the potential negative impact caused from failure. Questions I have for this would be: is the migration behind a feature gate, was an incremental % or whitelist based rollout possible (and planned), and did you plan for when the migration has to be rolled back?
- **How are you communicating progress?** Are you communicating progress only when critical events happen (hitting milestones/when issues come up) or are you proactively communicating progress at a fixed interval? From my experience, the former is often why "communication" issues are called out: if communication is only focused on the highlights & lowlights, issues often times feel more jarring because there's a lack of visibility on what potentially built up to the issue. Management may not always know exactly what's going on, but they do want paper trails when issues come up.
- And mostly importantly, **are you going to retrospectively think about the issue and share those thoughts out to the team?** There's 2 standard processes in the SDLC for retrospectively thinking about issues: a SEV report or a retrospective. From my very high level view, it seems like this was a last minute issue so I would except a SEV report at the very least. Regardless of how you end up retrospecting, you need to call out: why this issue happened, what was the overall impact on the business, and how will the team/company look to prevent similar issues in the future. You can use the previous bullet points I have to get a rough starting point on what questions your retrospection should look to answer.

Without being directly involved in your project, I can't give as nuanced of a response as I'd like. But I do hope this feedback helps give you a clearer sense of how to proactively and reactively respond to issues when they come up.

I was in a similar position when I started working from home at the start of the pandemic. It took a while to figure something out and I'd narrow down the core theme of finding my working process to: there has to be a clear difference in ceremony between getting ready normally and getting ready for work. There were 2 things I eventually introduced in my WFH process that established this boundary :

- I always wear socks on work days. If I don't have work, then I don't actively try to wear socks.
- For my monitor setup in my room that I use for work, I stopped using my personal laptop on it.

Maybe try changing up your WFH process to establish this clear boundary between work from home and just being at home. What works for me might not exactly end up working for you, but hopefully it gives you somewhat clearer direction on what could be changed.

Engineer at Robinhood

Jonathan Chiou

You can think about real life and strategy games in the same way: there are infinite paths of how things pan out in game/project/meeting/building a system, but a lot of individual events in these broader moments are effectively repetitions of a small number of fixed events. What makes things tricky is how these events permutate. A set of 3 potential events might sound small, but if we have an arbitrary sequence of 10 of these events and each event has 10 outcomes we can see how the "what ifs" can blow up and be overwhelming to think about.

In isolation, we can say "oh well that's just how it is gg" when confronted with the near bottomless amount of outcomes we can encounter. But in reality, we do have control of either (or both):

- The number of events that can be sequenced within the scenario: more specifically, this refers to breaking down the scenario into smaller scenarios. There are potentially infinitely many ways a LoL game can play out and it would impossible to talk about the game if we need to be able to mentally track every outcome, but the discussion becomes much simpler if we break down the game into 3 common stages of early, mid, and late game. Each stages of the game has a much smaller set of potential events, so it becomes much easier to discuss and focus on particular details.
- The number of outcomes within a particular event. We can think about this in exponents: if we have 2 sided 6-sided dice, we have 36 outcomes. If we have 2 4-sided dice, we have 16 outcomes. By lowering the amount of sides for each dice, we can lower the amount of potential outcomes. We want to think about individual events in the same way: by boiling them down to as simple of decision tree as possible, we can drastically reduce the outcomes that we have to track. My recommendation is to think as individual events as binary: either the outcome is &lt;blah&gt; or not &lt;blah&gt;.

Reeling this back into system design/soft skills:

- Break down systems into smaller, sequential milestones and focus on each milestone one a time. When we have to think about what work is needed to move a milestone forwards, ask yourself "what is the smallest amount of work needed to say we've progressed". Once you have some thoughts/ideas, rule them in or out with "does this make sense" (only has 2 answers: "yes" or "no").
- For discussions with people, it's not like systems where you get 1 giant thing at once to potentially break down & you have more control on where you start. Start by asking questions that can be answered by "yes"/"no" or by providing opinions that can be also supported/disagreed with with "yes" or "no".

By thinking about things in terms of these smaller "yes"/"no" pieces, the cognitive load should be lower when interacting with systems and people and you can shift that load towards building up the muscle memory around knowing how to ask narrow questions, what questions to ask to certain people, and if there's any common themes around how certain roles react to certain questions/information.

Hope this helps!

Unless you honestly had a great experience, I wouldn't send a thank you email. It might come off as a bit weird, especially when you didn't interview with anyone directly. It'd be even more weird if they decided to fail you.

Regardless of your title/role, the main way you should treat code velocity is "am I writing code at a reasonable velocity and quality to meet the expectations of my project and/or level"? If you're able to meet the timeline of the projects and sufficiently match the expectations of your level/next level (based off the expectations of your manager), just call it a day.

I'd expect a notable increase of velocity and quality for junior to mid level though, so I would look for these improvements (off the top of my head):

- Being proactive with testing (writing thorough test plans in pull requests and also writing tests)
- Lower turnaround time for putting up pull requests and merging in code. This usually means that you're getting more familiar with the codebase and the processes, so we should expect this to naturally decline as you're spending less time thinking and more time coding.
- The surface area of questions you ask to support your code is lower. You'll never stop asking questions in your career, but the question should be narrower and feel a lot less like you're asking someone else to effectively write your code for you.