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.

Android Engineer @ Robinhood

Jonathan C

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.