I would reframe ChatGPT as a tool that can be used to accelerate your coding and help you to clarify any questions you might be having. It's something that will be as ubiquitous as using a calculator, doing a Google search, or looking on StackOverflow. I wouldn't try to handicap yourself by not using it.

I don't think ChatGPT is at a stage where it's able to do everything. It's at a stage where you're still going to have to dive deep into harder problems and figure them out for yourself. Those problems are the ones where you can flex your mental capabilities more.

Eng @ Taro

Charlie Vuong

> people in my org really drill into the design docs and most of the questions are not really relevant. \~40 people would leave comments on a doc on average, which seems on the higher end across the industry, right?

That is a pretty high number, but it's great that people are that enthusiastic that they want to leave comments. Most of the time, you have to really prod people to leave comments. Although, I would focus on addressing comments from a core group of more experienced stakeholders.

> Difficult to start working on it because I don't really like writing essays

I would try to tackle the design doc in the most low-stakes environment possible to get started. This might look like a bullet-pointed list in your personal note-taking app where you are writing down your initial thoughts. If you are uncertain about something, just write it down and add a question mark at the end so you can revisit it later.

The momentum of just writing something down will carry you through to proofreading and fleshing out more of your less refined points.

> Analysis paralysis that I want to have it perfect, but it's just not possible due to all kinds of observability issues (e.g. missing log fields)

This usually happens to me when I try to keep too much information in my head. I start to dwell on all of the possible decisions that can be made and worry about whether I'm missing something or making the best decision. It's easier to just lay out your entire thought process on paper and tackle one problem at a time.

For points that you want to refine further, you can sprinkle some TBDs throughout the document and do a deep dive into them later.

> It's unclear what the project is about so it requires lots of discussion, which takes initiation / social energy

I would start with deciding what you believe the goal of the project is and then fill in the steps needed to reach the goal. Give it a first stab based on what you think is correct.

If the project is so unclear, you might want to talk to a tech lead or manager about the project over a casual chat to make sure you are going in the right direction.

 And, of course, it doesn't have to be correct/perfect the first time. Maybe the social dread comes from having people critique your work? I would try to reframe the design doc as something that's a work in progress which will get better and better with collaboration with your colleagues.

> On a higher level, I can utilize my strength in coding and try avoid design docs, or I can improve on writing design docs. Which option do you think is best?

I do think that writing design docs can help to progress your career because it teaches you how to collaborate with different stakeholders to and how to make the best decisions when confronted with uncertainty. It's these ambiguous situations where you have to make decisions with multiple tradeoffs that no one wants to make which can really help you grow.

> unfortunately it turns out I trapped into tutorial hell and I still can't came up an idea

If you are doing this to learn programming, you can try to build something that already exists.

> Additional: I also find out whether I write blog or write questions, it takes me a lot of time (maybe 1 - 3 hours or could be more depending the complexity), because I try every possibilities to avoid misunderstanding or miscommunication.

You'll get better with both skills over time if you keep the habit up over a long period of time. I would set a time limit for yourself because you'll probably get diminishing returns in quality.

> I enjoy problem solving but I don't have a much interest in software as a craft (a trait that I see from top engineers on my team), nor do I really care about tech products.

The good news is that enjoying problem solving is probably the most important trait compared to the other two traits you mentioned.

When you mention "software as a craft", I imagine you are talking about people who use their extracurricular time to work on engineering side projects or people who immerse themselves in the latest technologies. I do think that's a smaller minority of software engineers. Especially as people grow older and have families, their priorities shift, but they can still manage being excellent software engineers.

Are you still interested in the kinds of problems you are solving? If the answer is yes, it does make sense to continue down the path as a software engineer. You can also explore different roles like being a PM or EM.

I would favor **option 2** in your situation for better work-life balance, because you have already built the trust on the team and you have the domain experience.

**Option 1:**

- You are fighting an uphill battle because the low performer rating has set your manager's expectations for you.
- You will have to work harder to get a better performance rating, which will be even harder if you need to take time out in the middle of the day to address more important family priorities.

**Option 3:**

- You mention that you like your company. This is a very good thing, and it would be such a shame to abandon your company and risk going to a toxic team.
- You're going to have to build up that trust when you join a new company, which is going to be difficult when you have to context switch between work and family during the day.

> might get rusted on software development skills

I would say that this might not be as big of a concern as you think. There are very high-level and fundamental principles about every software project that don't involve getting immersed in the code that will help you guide projects to success.

**On the individual side,**

I agree with Ryan about greasing the wheels by having genuine connections with your colleagues at work. Before the project begins, have 1:1s with different stakeholders because and talk about the challenges that your project will solve. You'll be able to gauge everyone's initial reaction to see whether your project is on the right track. It will also make your project easier to get buy-in for the future because the stakeholders have already been primed with what to expect in your project.

**On the company side,**

A mandate to create a design doc before any changes are made is very important. I am guessing that's what you mean by Architecture Decision Records. The tradeoff is that there may be a lot of upfront meetings in the short term, but the final design would have go through multiple iterations of criticism which will lead to a more robust architecture in the long-term.

> tech lead looking for feedback on a target architecture not finding anyone willing/ready to do so

This may be more of a failure on the organization or company level. A poor architecture will continue to cause pain to engineers (and users) for years depending on the scale of the project. I would make sure that more senior engineers know that getting involved with these architecture decisions reflects very well on them, so they don't think that these decisions/meetings are just a burden on top of their other work. They should get acknowledged for attending these meetings and finding the best solution. It should even be part of their job responsibilities.

> I often need to provide PMs with performance numbers that are not available in the dashboard so that they can communicate with clients or make business decisions. Sometimes this need is urgent, such as needing to write code to find the number of customers who made purchases in the past seven days that meet a certain condition within half a day to a day.

I do believe there's an opportunity for making all of these metrics available in the dashboard so you don't have to write these one-off scripts. You mentioned that you have to provide PMs with this data very often. By allowing PMs to query this data themselves, you will relieve the burden of writing these one off scripts for PMs with urgent timelines, and it will allow PMs to go through a self-serve dashboard themselves. This will move the urgent timeline to them, and it will relieve the work off of you. Making these metrics available to everyone in the dashboard is more of a long-term project, but I think this approach is best for the company because of the flexibility and time it will save.

In the short-term, you can meet with the PMs/engineers and go over the queries you wrote so everyone can agree that the query and numbers look correct. The query accuracy should be a shared responsibility (esp. if the numbers are going to be used in an important way), so the responsibility doesn't fall solely on you.

> I was wondering how I navigate these and make sure I can show my full potential and upsell for this interview.

I would prepare by coming up with a list of questions about the team and what kind of projects the team will be working on. The team matching process is as much for you to find out more about the team's domain as it is for the team to recruit a new engineer. 

Also, If you can ask thoughtful questions about the team, it reflects well on you because it shows how deeply you can think about a problem.

It sounds like there's only one option that's under your control:

> I find some big opportunities that bring huge revenue to the organization

The other two are left out of your control, so they probably are not worth considering. I am in favor of putting in the initiative to find and execute on an impactful, revenue generating project. You'll be working the same number of hours (hopefully), so that time might as well go to something that can help to boost your promotion chances.

I would make sure to align on the project expectations with your manager to validate that the project is promotion-worthy.

> What do you think? Should I just relax, keep pace, and grow my skills, hoping for a promotion by job hopping when the market recovers?

You can also do interview prep in parallel so you are prepared if there is any opportunity that appears. You never know when you might get an opportunity from a friend or a recruiter. You'll have more time to prepare under less stress if you've been preparing in parallel. You might find an opportunity where you get an offer for a senior position where your current Amazon track to senior timeline is still ambiguous even after one year. 

> People in charge assigning projects asked me if I have experience in a specific set of technologies but they are mostly related to data engineering or AI/ML and I'm a backend developer.

I don't have experience with working at a consulting company, but there's a similar underlying job searching theme of "how do I get hired at a company if I don't have the required experience".

I would try to position your experience in a way where you are either 1. a generalist SWE whose experience can transfer to either domain or 2. you are willing to learn about either the data or AI/ML domain during the project.

In the meantime, you find out more about how to get started in data engineerings or AI/ML engineering like @Alex mentioned above.

> I've noticed that my diffs tend to undergo several rounds of revisions, which not only delays their integration but also consumes more engineering time than I'd like.

> Here’s what I’m considering to reduce the review cycles and improve my coding approach:
>
> 1. **Reducing the Size of Diffs**
> 2. **Pre-Review Checks**: -- Any suggestions here would be great

Since you just started, your reviews will be under a lot more scrutiny, which is good since it'll prevent you from merging in bad code or causing any incidents.

Your suggestions about how to improve your PRs make a lot of sense. Opening smaller diffs can actually get your code accepted faster. It can be intimidating for someone to open a PR and see that hundreds or thousands of lines were changed. They might decide to look at the PR later in the day because they don't have the time to give it a thorough review in the middle of the day. But, if they see a smaller change that only takes 3-5 minutes to look at, they will be way more likely to close that loop immediately.

For pre-review checks, this will be less about the semantics of the code and more about being on the right path. A small explanation or bullet points about what you intend to do in your code change can prevent you from going down the wrong path and wasting a lot of your time as well as your reviewers' time. It will also help grease the wheels and get your review accepted faster because the reviewer knows exactly what to expect in the code review. There's nothing more demoralizing than someone blocking your review because the implementation is completely wrong.

There's a few things that might be able to help you gain the confidence to speak out:

1. You can explain your full line of thinking behind how you came up with your opinion. People will be able to clearly follow your thought process and acknowledge that your opinion makes sense given the assumptions that you provided.
2. You can give tradeoffs between selecting different options. You can take it one step further and suggest the best option based on what you are trying to prioritize.

The articulation of the thought process is the most important thing because it shows you are really thinking about all of the different cases. At the end of the day, the first opinion you give might not be the best, but you put the different cases out there for you and your team to think about. This will help start the conversation towards finding the best solution to your problem.

I've given 1 month notice in the previous two jobs that I've left. I found that this gives enough time for your manager to go through all of the paperwork and meetings when someone leaves a company without feeling rushed. it also gives you enough time to wrap up any loose ends on projects and let your co-workers know that you are leaving.

> Should I give my 100% into the onboarding?

It's not a good use of your time to continue the onboarding process. I would finish out your time by setting up meetings with your co-workers and letting them know that you're leaving so they know that everything's okay, and you are leaving on good terms. They might want to join you later on :)

> Some hurdles I find:
>
> - There might be a big difference in our roles (for eg. system eng and product manager)
> - There might be differences in seniority where I feel like I feel like I'm not able to provide enough value to my match (I might not be able to provide any value/insight into any challenges/goals of my match)

I would try to keep an open mind because there might be more similarities than differences in the projects that both of you have worked on. It can be helpful to get the perspective of a person who is in a different role than you because it could help drive how you decide to navigate a project with different stakeholders in the future.

Also, you might not need to provide direct value to your match in the form of advice. There are many times where others can find value by giving you advice. It gives them a chance to refine their own thoughts about a particular subject. It also feels good when you are able to help someone else.

> what mindset should I keep to have deeper/meaningful conversations

At the end of the day, we are all humans, and we all have different interests and struggles. I would try to tap into these. If someone starts to elaborate a lot about a certain topic, they are probably very interested in it, and you can tease out deeper questions about why they are so interested in that topic.

You should take the offer because there's much more you can gain than you can lose. If you come in as a mid-level engineer, you could perform as a senior engineer immediately, but it's not guaranteed that you will get a quick promotion.

When you join as a new employee, people will have lower expectations for you, so you'll be able to use this time to adjust to the senior expectations.

> I'm a hard worker and have good soft skills so I wonder if this will be enough to aid me while I get up to speed.

This will be your biggest attribute to your success in the role. The goal is to get as many quick feedback loops with your work so you and your manager can agree on whether you are hitting expectations.

I would make sure the core functionality of your side projects is working. If the interviewer were to ask you to demo the side projects, I would make sure you'd be able to do that. It's rare that they'd ask you to do that, but it would be a bad sign if you tried to demo the product, and you weren't able to perform the main use case.

For you Spring Boot app, I'd try to get the data fetching working since it's core to the app.

For more mature companies, it can be harder to find opportunities to work on greenfield projects, so you may have no choice but to work on maintenance projects. But, I don't think this is necessarily a bad thing for your career. The most important thing to consider is what kind of impact does your work have at the end of the day.

A bug may also have wide scope. There are some really obscure and gnarly bugs that can span multiple levels of the tech stack and can have extremely high impact on important business metrics.

It helps to work on high-impact projects where you are the one driving the project forward. This works in two ways:

1. Your current company will have to take your involvement in the projects into account when determining your performance.
2. If you are looking for opportunities at other companies, you'll need to be very clear about your involvement on the projects you worked on at your current company.

It also helps to be the subject matter expert for a feature or service at your company. You'll be such a valuable asset to the company because the success for that product depends so much on your contribution.

You may also want to consider having a way to toggle between the legacy library and new library in prod easily. This will make it easier to recover from cases where migrating to the new library caused an issue because you don't need to wait for a new build and deploy to go out.

I've worked on projects in the past where we migrated UI components or consumed a new API version. We usually gated the logic behind an experiment just in case we needed to mitigate any issues as soon as possible. 

> I mentioned that I did not have confidence in going ahead with the task without understanding the cause of the unexpected results. My team was unhappy with this as the code has been working okay so far without any issues and the unexpected results were likely because of a gap in my understanding.

The most important thing in this situation is to have very clear communication with your team where you come up with an action plan of 2-3 things you are going to try, how long you expect them to take, and what you will do if these things fail. Make sure to report back with exactly what happened when you executed your action plan. You want to avoid being stuck in a limbo zone where there is no progress being made at all. You and your team should be clear about what the next steps are. Make sure to reach out to people if you are blocked.

> How to work with an unknown or hardly known area of code on a tight deadline?

Action is the key here, too. Just start breaking things and printing out comments to make sure the code is functioning as you expect. If there's a part of the code that raises a question, try to break it, or try different inputs to see what happens. It can be easy to get intimidated with a codebase that's new because there's a barrage of so many unfamiliar ideas. The best thing is to test your assumptions by breaking the code (locally, of course).

> I would like your thoughts on how "wise" is it to be SWE2 with 15 years experience.

Given your situation, it is probably the best option given the other available options. This will give you an opportunity to continue interviewing at different companies while in the country and while earning a paycheck.

But, I wouldn't stay at this company long-term because you could be looking at 1-2 years before you get back to your previous position, then another 2 years to reach staff engineer. It could be 4 years before you get back to the position that you were almost at before.

In the ideal case, your interview prep goes well, and you will be able to find another job within 3-6 months, ideally as a senior or staff SWE. You won't need to put your current role on your resume. This would be ideal because this position would peg you as a SWE2 when you are interviewing at other companies. It would lead to a lot of confusion.

> Would my age become a factor for further career progressions as they would prefer younger people?

In the interview panels I've been involved in, I don't ever remember a time where we've had a preference for younger people, and I'm not even sure that's legal. If anything, age and industry experience can be seen as a positive.

> While this has helped me learn new things, I am beginning to see a mental pattern emerge.

When I started coding 15 years ago, and I came upon a coding roadblock, I'd go through the following sequence:

1. I would do a Google search describing my problem.
2. I would usually click on the first StackOverflow link to find the answer. I'd have to read through a few answers
3. I'd have to tailor an answer to my specific situation.

I'm pretty sure this is how a lot of people who came up coding around my time learned how to solve any coding problems they were having. I learned a lot this way. But, with these new generative AI tools, you can learn even faster because you can ask the tool about very personalized pieces of code, and you can ask follow up questions within the same context. The previous flow is reduced down to:

1. Ask ChatGPT how to solve my problem given this very specific piece of code.

For me, these tools have been the biggest time savers when I need to integrate multiple libraries together. This is because the most time-consuming part can be parsing through the documentation of different libraries. A lot of libraries don't have the best written documentation. Being able to get an example piece of code of three libraries being used together and tweaking that example saves me a lot of time.

> Is that an optimal path I am headed for? Or should I introduce an emergency tweak in how I work to better my career as a stronger, confident software engineer?

Knowing the higher level concepts is the most important thing. If you are just blindly copying and pasting code from ChatGPT, that is going to catch up to you because you will be forced to come up with your own solution when ChatGPT can't give you the answer you are looking for.

If you know the underlying concepts, and you are using ChatGPT to speed up your work, there's no issue. Even as a professional software engineer, you end up delegating work and working on higher level system design as you get more and more experience.

> Sometimes this also leads to drag, as I am left explaining the context to GenAi.

In my experience with using ChatGPT, if it doesn't produce something useful within the first few responses, I will usually give up on it and figure out the solution myself. I've found that when I try to add extra context, ChatGPT will still continue to give poor results. I haven't used Claude yet, but someone told me they had better coding results with Claude.

> I understand networking is a long term game, but I feel stuck trying to build deeper relationships and especially trying to level up

> I'd love something actionable on how I can add value to people and network that doesn't rely on my job/college

You are right that networking is a long term game. It can be harder to build connections with people when you only have one-off interactions with them. Having repeated interactions with other people is the best way to build trust with other people, especially when you are able to break down the professional shield you have when meeting people for the first time.

I'm not sure where you live, but if you live in a city with a large population of tech workers (SF, Seattle, NYC), find an activity or club that you are interested in, and you are sure to find other people working at different tech companies there.

I would also recommend [**Taro Networking**](https://www.jointaro.com/networking/) to introduce yourself to people in the community. Your first interaction with someone might not lead to a significant relationship, but you might meet up with them again at a local Taro meetup or you might grab coffee or lunch with them. If you can stack multiple interactions with people, you'll really be able to build that trust with them and reach out to them in the future.

> Personally, I struggle with comprehending problems, whether they are coding or business related. I often need to read through the problem multiple times to fully understand it

There can be comprehension issues when it's hard to connect the problem to some context or goal. If you aren't able to do this, it's easy to just passively read something but not grasp it fully.

It helps to have higher company goals or principles in mind as you read through a problem. As you read through the problem, you can think more critically about whether the problem can solve a higher level goal or whether it distracts from the higher level goal.

You have such a wonderful gift to be able to completely focus on writing code and block out any distractions, and I can guarantee you that a lot of people would love to be able to have this same superpower.

I probably would avoid the pomodoro technique. IIRC, it's more for people who have trouble starting and continuing work. It involves setting a timer to work for "x" amount of minutes before they can take a break. In your case, this seems like it would disrupt your flow because you are basically interrupting yourself in shorter intervals of time. If you are into the work, you should really ride the wave, otherwise, you are handicapping yourself.

> What strategies have worked well for the code machine archetype to get their work done but without burning themselves out?

The burnout piece is more concerning. If you are constantly burned out after these regular bouts of productivity, it can cancel out all of the productivity that you've had. I've seen this before in people. They will work for extremely long hours for a few days, then they will completely crash for a few weeks where they don't feel like doing anything.

I'm not sure if that applies to you, but if it does, you should try to make space for yourself in the mornings/evenings to do something that's unrelated to work. Especially since you mentioned "undervaluing" of your body, it leads me to think that having some physical activity either in the morning or in the evening could help to reset your body and create that space.

> It is much like the stereotype of Poppy Li in Mythic Quest unfortunately

I hadn't heard of this show before, so I ended up looking at clips. It looked very funny, and I added it to my queue of shows to watch. I used to watch Community, so seeing Danny Pudi in it was a welcome surprise :)

> but in my view it's excessive and leads our team to spend too much time addressing stylistic or minor changes that don't materially improve the codebase

This is a situation where I would take the time to add a linter as part of the CI process. There is an upfront cost, of course, but the time spent to set it up will help the entire team save time down the road. The current cost isn't just fixing stylistic errors, but the cost is the turnaround time it takes for the TL to read the code, write out the comments, and for you to address the comments.

I recommend writing out a doc with the recommended rules and invite the TL to contribute to the doc, too. The goal of this is to establish a set of rules that you, your teammates, and your TL can agree on that will save everyone time in the future. it's also an excellent project to boast about in your next performance review.

Grades are a very clearly defined metric of success. When you are in school, you can develop a mindset for prioritizing good grades at the expense of other things, like social connection. And, this can work really well as a student because good grades are a path to getting into a good school or good internship. There are a few dangers to this:

- When you sacrifice social connection for studying more, it means you are getting less practice with how to communicate effectively with other people. This is very important in the after-school life because a large part of being effective is being able to manage expectations with other people.
- You can become too boxed in to pleasing other people. A large part of doing well in tests is coming up with the answer that someone expects of you. After school, there's a part of you that becomes independent and people pleasing can hold you back because you are more concerned with how others perceive you. So, you might not go after what you truly want in life.

That being said, I don't think there's a higher proportion of average students that do better than high performing students. If you can figure out how to solve a test, you can probably figure out how to communicate with people even if it's later in life.

20+ hours is a long time to do research. There could be a few reasons why this is happening.

- It's easy to fall into a trap where you watch the videos because it's easier than writing out code. Watching videos can give you quick satisfaction where it feels like you are making progress even though there is nothing to show for it.
- You don't want to write incorrect code. The great thing is that there's no one to judge your side project code. This will give you an opportunity to throw the kitchen sink at the problem and try everything.
- It is also possible that you haven't been exposed to enough CSS, which is why you are looking for a comprehensive course that can teach you everything. While this is good for learning, your goal is  shipping your project within a certain timeline, so this isn't the route to take. I haven't tried this before, but have you tried to ask ChatGPT questions to point you in the right direction? This way you can avoid learning things unrelated to the problem you are trying to solve.

It's also helpful to break down your tasks into smaller tasks (like max 1 hour time) and timebox each of your tasks to make sure you don't spend too much time on them. For a side project, it might make sense to cut tasks to keep that momentum going.

Haha, the ellipsis can make the word feel like it's drawn out like a depressed sigh. I found a video of Eeyore (the sad donkey in Winnie the Pooh) that shows how people might interpret the ellipsis:

<https://www.youtube.com/watch?v=CQI0E1WCLMU>

> Specifically, I need to enhance my technological proficiency, deepen my understanding of business dynamics, and integrate seamlessly into the organizational culture

There's a balance you can strike where you can go on a needs finding exercise by talking to other senior members but also getting into the codebase to see the issues for yourself.

During your conversations with other senior members, you'll be able to get different viewpoints about things that are broken or suboptimal at your company. One of your superpowers is that you have a fresh perspective on the issues that are going on in the company. So, don't feel boxed in to some of the solutions that people may suggest to you. Try to think about the problems more holistically to see if there's a different way to solve the problem.

Once you have a list of potential projects, rank them in terms of ease of completion and impact. Do the projects that are the easiest and most impactful first to get a quick win and build the momentum for the other projects.

> I do have a side-project on my resume I did involving TypeScript/React, and so I was wondering if creating an iOS app with Swift and putting it on my resume would kind of hinder my chances at web dev jobs or would it still be something that could help land me an interviews for those jobs?

It shouldn't hinder you, but it could raise some questions, especially if someone less technical is taking the first pass at your resume:

- Is this person more suited for a mobile development role?
- Is this person trying to pivot into a mobile role, so they aren't interested in web anymore?

But, any of the above concerns can be resolved by declaring what kind of position you are looking for at the top of your resume. You can move the side projects into a secondary section on your resume to signal that you are passionate about coding in your spare time, but it's not what you've worked on primarily.

I keep a note in my note taking app with a queue of projects that I want to work on. The ideas usually pop up organically, and I'll add them into my queue.

If you are having issues coming up with ideas organically, you can prime yourself each morning to actively look for problems. You can set a goal to write down one problem each day. Then, you can evaluate which of the problems is the most compelling to you and create a programmatic solution for that problem.

> For example, I recently was so focused on the more difficult part of a ticket, thinking about edge cases and trying to really polish this bit of functionality, that I spaced on reviewing the ticket before creating a PR. This meant the lead engineer reviewing my PR had to explain to me that I missed some other aspects of the ticket.

I try to brainstorm all of the test cases I want to go through before even starting the task, and I write them down in Notes/Notion. I will add on to this list as I'm working through the code because you'll think of different edge cases as you do work through the code. I make sure to manually test those different edge cases before I create the PR.

As part of the above process, you can translate the requirements from the ticket into more bullet points to testing in your notes app.

It also doesn't hurt to re-read the ticket when you add a reference to your PR on the ticket.

> Another time, I spent a while trying to right a really good question about a solution to what I suspected was a tough issue. The problem? I hadn’t thought to test my hypothesis and confirm that this issue would occur (it didn’t) before formulating and asking my question. So I needn’t have bothered anyone else or myself about navigating this hypothetical problem.

Before I ask someone a question, I try to think about what answers or questions the person might respond with and how I would respond to their hypothetical responses. 

In this case, you would imagine a fictional person asking you what error message you were seeing when you tried your hypothesis, and you would have realized that I need to actually try this flow so I can get the error message. But, when you try it, you would see that you wouldn't run into the error.

> but it seems when I focus on being thorough it perpetuates the problem like in the two examples above.

It's good that you are thorough! You just need to refine the system you are using :)

I agree with breaking down the process into granular pieces and focusing on fixing the relevant, breaking portion.

Here are some things you can try:

- Save the transformed data into an output file and use that outputted file as the input into the load step
- Break down the input from the output file into small page sizes and load those smaller page sizes into the load step (similar to what Alex is saying)

> There must be a way to work super hard, write high quality code, learn from mistakes, all while being chill even through difficult times and unplugging 100% during time off.

Early on in my career, I used to be on edge all the time where I was taking my laptop with me on hikes and getting plane wifi because I was always worried that something would go wrong, and I'd be at fault.

1. You'll mentally fatigue yourself where you won't be able to perform well and you'll emotionally drag down your team with your body language.
2. Most companies are well-oiled machines where there are ways to mitigate issues quickly if something goes wrong.
3. Most engineers are working on something that will cause a minor inconvenience to the end user if it goes down.

It can be easy to exaggerate the consequences of something going wrong to be astronomical. Sometimes, we just need to zoom out and think of what's the worst that can happen and how they can be mitigated by processes that are in place or need to be added.

> It could be healthy to a degree to stress about it so that I do a retro, make action items, and fix the process for next time. But it is a major negative to take it too seriously to the point where I go over it 100 times in my head or when talking to coworkers I become defensive, give excuses, or want to start thinking about blame.

You are doing a good job by doing the retro and coming up with action items. Once you get all of your thoughts out in a retro doc, there isn't a use in continuing to dwell on the matter anymore especially if you are going over the same thoughts in your head.

That does sound like it can be frustrating. Before you completely jump ship (and assuming you like the company and team you are on), can you pitch a project to your manager that has high impact and high visibility?

I would try to paint a full picture of how you see your career right now and where you want it to be 6 months or 1 year down the road. This way, your manager can more clearly see how your work isn't aligning with the trajectory that you want to be on.

I highly recommend using [FrontendMasters](https://frontendmasters.com/) because their courses provide structure and use best practices since they are taught by people who work at large companies. The quality of their instruction is 10x better than finding multiple different sources online and trying to synthesize them all.

As far as projects, you can add Typescript in gradually to any existing project, one file at a time.

You can record yourself giving the presentation and go over the recording with a friend who has more public speaking experience. The recording will reveal areas where you can improve your body language or speech patterns.

> However, I'm just tired because every time I need help for brainstorming and pairing, my peers will help me, but not without bragging themselves in the end ("how come you don't know this?", "I managed to be able to do this for the 1st time", etc).

A lot of this is a reflection of them rather than a reflection of you. Their way of thinking can be very toxic because it breeds a culture where looking smart is the ultimate goal rather than learning. Then, everybody on the team is afraid of asking questions, including your teammates who are afraid of asking you questions.

I find that a lot of people with this kind of attitude have never tried to do anything outside of their comfort zone. Otherwise, they would have developed the empathy to understand that everyone has different starting points, but we can work on our weaknesses and improve on them. 

> Everytime I do something good outside of work such as becoming a tech speaker or teaching a bootcamp and I share it, I feel like I'm being shot down with words such as "I've done better than that", "Why did you even take up that speaker gig? Are you pretending to be a senior?". I mean, what's with the bragging? The insecurities? If you're more senior than me and you have more experience than me, of course they all look simple to you.

It takes a lot of courage to speak or teach because you have to put yourself in the spotlight, so kudos to you for doing that! There are a lot of flaws in their thought process: you don't need to be the most senior person to teach and provide value to others. You also have a unique perspective because of your background. What can matter more as a speaker or teacher is how you convey the material. A lot of times, the most skilled athlete doesn't make the best coach.

Your peers' feedback are largely irrelevant because they are assuming that you can't provide value to your audience and students. Only your audience and students can tell you that information, and I'm sure that they'd tell you that they've learned a lot from you, which is what matters the most :)

**Morning**

- Cetaphil Gentle Skin Cleanser
- Timeless Vitamin C Serum
- CeraVe AM Moisturizing Lotion

**Evening**

- Cetaphil Gentle Skin Cleanser
- CeraVe PM Moisturizing Lotion

My routine is pretty minimal. I was always using the cleanser for many years, but I added the AM/PM moisturizing lotions mid last year. Then, I added the Vitamin C Serum at the end of last year. Would love to hear about everyone's favorite product.

Your goal should be to get something shipped as soon as possible to build momentum early on and set a first impression of getting things done.

I would pick the easiest task, regardless of whether it's on the infrastructure or feature side, to solve first. A lot of times, these tasks will introduce you to how code review is done, how to build the application locally, how the build system works, how tests are written, and how the code is deployed.

A word of caution, sometimes the easiest tasks can actually be more difficult than you think, especially if it's a task that has been in the backlog for a long time. I would come up with a list of three tasks, brainstorm how you would solve them (without coding them), and then meet up with your onboarding buddy to validate whether your solutions seem sound.

> Insights into the challenges and expectations specific to AI/ML teams that I might not be aware of coming from a different specialization.

Although I don't have a background on a AI/ML team, you can ask the EM about the kinds of projects their team is responsible for and what the team KPIs are.

By getting a history of the team's projects, you'll be able to dive into a deeper conversation with the EM about the particular challenges from that project and the problem that the project was trying to solve.

I would also advise talking to multiple EMs so you can triangulate the expectations among different teams.

**The Talent Code** by Daniel Coyle

**Audiobook**: Yes (Audible)

**Synopsis**:

The author does a deep dive into how certain geographic locations produce successful athletes (Brazil with soccer or the Caribbean with baseball) or musicians. It goes into how you should be practicing on the edge of your abilities to get better at a skill (deliberate practice).

I would have conversations about the codebase in a holistic way to try to find out how it evolved while your mentor has been working at the company. This way, you can understand the design decisions that led to the current state of the codebase.

Make sure to also use them as a sounding board when you start your larger projects. Have them review your design docs, so they can help you not fall into any design traps.

You can also ask them about their career at the company to understand more about what projects they worked on and what different teams at the company do.

Can you set up a meeting with them where you can at least get their code to run on your own laptop?

- You can document the process along the way to set up the project
- You can walk through the code with them so you'll be able to understand what's happening
- You can plan out the tasks that will be required to port over the project to the cloud
- You can get their POV about what they would do differently if they had a redo on the project

I would try to grade each type of documentation along how much time will each doc save versus the amount of time it will take to write and maintain each doc. It's easy to underestimate how docs can also lead to confusion if they get outdated.

For example, if there's an onboarding doc that every new engineer will use, and it saves them each 15-20 minutes, it's probably worth creating the doc.

For dev work, most documentation is captured within the code, PR description, or task, so it's probably not worth doing any additional documentation

For exploring a new tool, it can depend. If it's how to use the tool, people can usually refer to that tool's docs. But, I could see a case where it might be worth it to outline the tradeoffs of a new tool versus other tools so other people can understand the history of why a tool was selected.

I also agree with the consistency piece. Consistency starts with building sustainable habits you can do for years. It's hard to maintain David Goggins intensity over a long period of time.

Starting with a strong foundation for diet, exercise, and sleep is key. Having those locked in will get you 80-90% of the way there, then you can start adding more of the incremental things later.

- For exercise, the most important thing is to just get to the gym. Find a workout, class, activity that you really enjoy and can see yourself doing ten years down the line. There is less of a chance for you to quit in 6 months. Even if the exercise "isn't optimal", it's better than doing nothing.
- Set a schedule for when you want to exercise. For me, that's usually in the morning, ideally, before I start work. I am way too tired in the evening to want to do anything that requires any willpower.
- Make sure to get enough sleep each night. You build muscle and consolidate memories during sleep.

> - And how can I make a good impression with my new interim manager?

Try to make it as easy as possible for your new interim manager to understand the context behind all of your work and your team's work. You want to be the person that the interim manager can lean on when they have any questions, and they should have a lot of questions. Be responsive to their messages and addressing any problems in this initial period.

Having a 1:1 doc with your manager and peers is key. At the end of the meeting, summarize the action items to make sure you are both on the same page of what needs to be done. Determine what is urgent from those action items and prioritize it among your other work and let the other person know where it fits.

> This is especially hard when the advice is not immediately actionable (i.e. situation based).

Can you operationalize the situational based advice in some way? I do try to set monthly goals at work. If you can operationalize the advice, you can set a work goal to "do so-and-so behavior 10 times this month" and hold yourself accountable to that.

> I am seeking strategies to maintain our pace without the need for constant updates or taking on the tasks myself, aiming to achieve our desired goals.

Communication will be key. There's a good medium between constant updates and occasional updates. I do recommend standups, maybe twice a week, and maybe through chat where people post what they are working on and whether they have any blockers.

Make sure to really pay attention to the updates and really try to unblock people. You don't want to get into a zone where you are passively looking at the updates.

You want to be careful about jumping in to do the work for your team because you don't want to be a crutch for them. If they are new to the team and technologies, pair programming can be worthwhile to really accelerate their onboarding process.

I've tried to break down some action items in the immediate term, short term, and long term:

Can they roll back their code immediately to not let the wound bleed any further? It sounds like they are trying to do a forward fix, but it's taking a while. I would at least try to mitigate the current problem and bring the system to a stable state. They will need to do as much damage control right now to not let the problem compound further.

In the short term, I would make sure that new PRs have a code review from a different person before they can be merged in. The PR descriptions should have a template that include what the author did to test their code. I would also try to schedule a retrospective to outline what went wrong and what process changes could have helped prevent the issue. This can be presented to leadership to try to help save your friend by diverting the attention from him onto the missing processes.

In the long term, I would make sure there is some staging environment with either automated tests or manual tests that can detect the most basic, and most impactful, outages.

I would take the job with your previous company and prepare for interviews (and actually interview) while you are working because of how fickle the job market is right now.

I am someone who has quit their job without anything lined up in the past, but after hearing about how difficult the job market is, it's very risky to not have something lined up.

Not all mistakes are equal, so it depends on the severity of the crash that he caused: was it due to negligence, how long was the outage, and were they actively involved in the process to fix the mistake?

> His team allowed him to approve and merge his own code into production

By approve and merge his own code, does this mean that no one reviewed his code before he could merge it?

If the engineer made a mistake because they didn't even run through the most basic flow to check that their code works, I would have a discussion about them about this.

It also sounds like there are really tight guardrails around software engineers if they were just able to gain the privilege to merge in code even though they've been at the company for almost one year. There has to be freedom for engineers to be able to make mistakes so they can grow.

I would look at whether there could be any process changes that could have prevented this issue. Is there a staging environment that runs tests on the new build that could have caught this issue before it was deployed to production?

A few reasons:

- Frontend can feel very repetitive when you are just adding buttons or creating another form
- Frontend can get tedious if you are spending a long time trying to get everything pixel perfect
- Frontend can be less exciting because it can feel like you have less technical scope

I would also make sure that you are asking a diverse population of developers and that the sample wasn't biased towards backend engineers.

Some questions you can ask:

1. What would you have done differently in your career?
2. What project did you work on at the company has given you the most satisfaction? (it could open the door for them to explain a problem that had a heavy technical aspect)
3. What teams have they worked on at the company, and what was their motivation for joining each team? (this will give you a sense of the company needs and how easy it is to switch teams in the future)

Try to meet them somewhere with the least friction available for them, so let them pick a time and meet at a coffee shop that is close to their work.

> Plus Front-End is something I genuinely am drawn to and enjoy doing.

If you enjoy front end work, you should definitely pursue it, otherwise, each day is going to be a struggle for you.

> I’m closing down my options, and limiting myself to Front End

Most companies are open about letting engineers switch roles and teams. You are also not locked in to doing pure front end if you start down that path. A lot of times, you'll have to dig into different code bases or work on the backend or devops side to solve a problem, so you'll end up getting full stack knowledge.

> A lot of family friends in the industry telling me that Front-End specialization will be a waste of time since the industry is very saturated with it

If a company is growing very fast, and they have a webapp, they are going to be looking for frontend engineers to hire to help them build faster. Companies are always drowning in work to be done. The key is making sure you are open-minded to solving problems beyond your realm and expanding your knowledge over the course of many years. You'll be so much more valuable if you can dig through different technology layers to solve a problem rather than just deciding that something is out of your scope of expertise. You'll want to be a universal problem solver at the end of the day.

I would set an expectation that it's very normal to feel overwhelmed when you are starting a new job. Take a deep breath and understand that the anxiety is completely normal, the imposter syndrome is completely normal. Most teams expect that the first few months will be a period where you'll be learning and making mistakes.

I actually think your bias of starting on tickets immediately is actually good. A lot of people fall victim to reading through too much documentation or passively going through tutorials where it impacts them from actually getting any work done.

You're probably in a place where every corner you turn just seems like there's a block. That's okay. Write down any questions or misunderstandings you have so you can ask your team when they get back.

As far as a problem solving framework, I would try to timebox each problem to a few hours. If there's a problem where you aren't actively making progress after making your best attempt, I would meet with someone and lay out the full context of how you are understanding the problem and solutions you've tried, and they'll probably be able to answer your question or steer you in the right direction. Sometimes, there is just tribal knowledge that's been passed down that can only be answered by someone who implemented the system or has been bit by that problem before.

> I want the communication to be more natural

It's okay to also talk about your personal life with your manager. It doesn't have to be all about business. You'll be able to foster more trust and comfort which can make it easier to talk about hard conversations in the future.

The ideal person is someone who is more senior than you and can vouch for, back up, or amplify your impact since the last performance review cycle. You'd want to have worked with them enough where they'd be able to write a few paragraphs about the impact you've made. 

I agree with Rahul about meeting with them and reminding and priming them with what you want them to talk about in their feedback.

I would reach out to enough people where you have enough signal to make a good decision. If you are asking active employees, I would also try to read between the lines to make sure they aren't trying to hint at something negative without actually saying it out loud.

I used to make the commute in the opposite direction, from Sunnyvale to SF. We had a WFH day on Wednesday, so I did this 4 times/week. It was a 10 minute drive to get to the Caltrain station, an hour Caltrain ride up to get up to 4th and King, and then a 10 minute walk to the office, (times 2 since I'd do the reverse commute in the evening), so I can understand where you are coming from.

I was similar to you where I didn't have the energy to go to the gym at night because I'd get back to my place at 8pm. I ended up going to the gym in the mornings instead. If you do want to continue your commute, so that's an option.

But, I really regretted the long commute after doing it for years because of all the time I wasted during my commute. It sounds like you know where your priorities lie and health and community are more important than work. I really do believe you'll be able to find another job where you can get paid the same amount, if not more, have time and energy to go to the gym, and be able to socialize with your friends at the end of the day. I remember being a zombie for the entire day when I was doing that commute.

If I was in your situation, I would strongly recommend you try to find a company that is in the city or has a better remote work schedule.

Be careful that you aren't just looking for opportunities to refactor for the sake of refactoring. There can be so many opportunities to refactor different parts of the code base, but you have to make the calculation of whether it's a worthwhile place to refactor. If you are finding it hard to identify places to refactor, I would hold off until you're more familiar with the codebase.

A good signal that you should refactor is that you and other engineers have a loss of productivity when building in a certain part of the code. If you get a sense of anxiety when touching a certain part of the code, you can probably add it as a candidate as a place where you can refactor the code. You should be having regular 1:1s with people from your team and people on other teams, and you can gauge where frustration in a codebase lies.

I could argue that companies that ship products faster forces you to move faster, which will make you grow faster because you'll get more experience in the same amount of time as a company that ships slower.

I would also say that you should focus on company revenue growth because great engineers want to be part of a fast growing rocket ship. As a result, you will work at a company where you can learn from other great engineers. If you compare this to a company that's stagnating, a lot of the great engineers will recognize this and will have moved on to greener pastures.

It's great that you are taking a step to finding a mentor. You'll be able to avoid a lot of common mistakes and optimize your career trajectory by doing this.

A lot of times, mentorship relationships are organic. They consist of cycles where you ask a mentor questions, act on their answers if they make sense, and then report back to them with the results of their advice. After a few of those cycles with someone, you will unofficially be a mentee of theirs. The important part is acting on their advice and reporting back to them because it shows that you are serious about the advice that they are giving out.

Take a few minutes to hammer out what you are looking for in a career so you can trace the steps to get to that point. This will help to focus the questions that you ask your mentor.

I'm also using this as an opportunity to plug our [Taro Networking Service](http://localhost:17655/networking/). You can find other Taro community members who are more senior than you who are open to coffee chats or mentoring.

I wouldn't take a step back because you'll feel like you're digging yourself out of a hole to get back to where you previously were. Many software engineering companies want software engineers with strong problem solving and critical analysis abilities. Can you tailor your resume to show that you've made impact on engineering projects. Focus more on the impact rather than the technologies being used for these projects where you feel like you might not be using the technologies that an employer is looking for.

If you've been using the more desired tech stack in your personal projects, I would highlight that at the top of your resume. That way recruiters will at least get you through the first pass and not immediately reject the application.

Senior Software Engineer at Taro

I agree with applying for the role even if you aren't sure of the outcome. Worst case, you'll gain valuable insight about what kind of questions get asked for backend engineers or what kind of experience companies are looking for.

I would also spend some time crafting a compelling story on the backend work that you did, even if you think it's just "easy".

If you are currently working at a company, can you also consider taking on and leading more impactful backend projects at your current job (possibly even switching teams)? That will help to boost your application and provide you with more backend experience.

There's probably been one time every year where something related to operating systems or computer architecture comes into play, but honestly, you can just search for it and find an answer quickly. Unless you are very interested in those subjects, it's probably not worth it for you to dedicate hundreds of hours to go through a textbook to learn those fundamentals.

As you get to each problem, you can figure out the solution for that problem at that time. Over the course of a year, you'll have gained so much knowledge and experience. The mental block may be that you feel like you need to know the answer to everything up front, which is not the case. People are constantly learning. The harder the problem, the less likely there is a clear answer, which makes the problem fun because you get to obsess over it :).

Software Engineer @ Taro, Pinterest

> The project is still in its early stages so there aren't many features. But I'd still like to keep stakeholders updated and get them excited to gain some visibility into whats being built.

It's great that you recognize the value of project visibility. You can invite the stakeholders into a Slack channel or equivalent where you can share updates about your project, ideally with screenshots/gifs.

> I obsess about the quality of the work / code being written that sometimes it reaches a point of decision paralysis, where I'm afraid to take action / build in new features. A lot of the uncertainty arises due to concerns about my lack of experience (which I sometimes fear could lead to sub-optimal work)

You ideally want to try to bias on action because you'll be able to get more reps in and gain more experience quicker than if you obsess over something small. If you are a new grad that has just started, you have a lot of leeway to make mistakes. The mindset should be to move fast so you can get those mistakes out of the way quickly, which in turn allows you to ramp up quickly.

You mentioned being "afraid of building in new features". Ideally, the list of features should have been decided beforehand in a design doc. This will help with any scope creep and free you from the decision paralysis so you can just code.

> Since I'm working on this project totally on my own, I feel things can get a little siloed (ie : I'm the only person writing code and working on this project and have just 1 person reviewing my code).

This might be the nature of the project. Since you just joined the team, you should try to have regular 1:1s with your other teammates to find out what they are working on. It could be a leading off point to decide what you want to work on after this project. It's also a great way to build relationships with your teammates.

100% a team sport, all the way through. Some examples include:

- When you first onboard, your team is there to jumpstart you so you can start contributing.
- When you open up a new PR, your team is there to make sure your code looks correct
- When you come up with a design doc, your team is there to provide feedback
- When you work on a roadmap, your team is there to discuss the tradeoffs in working on certain projects over other projects
- If there's an upstream service that is causing your feature to fail, you are dependent on another team to fix any issues with their service

 

> how do you suggest I ramp up? its so many people and so many layers of code and tech. I have a good amount of experience in data/ml and also eng. I don't think I'm a 10x engineer but I am pretty proficient at getting things done.

I would at least try to land one small code change.

Try to avoid getting stuck in a state where you are only reading documentation because it can become a form of procrastination. You should have some actionable item that you can bring to a "done" or "completed" state which is why I recommend landing a small code change.

I would also start a doc for yourself and bullet point any processes that can be improved. These might include:

1. Slow dev ops process
2. Slow onboarding practices
3. Unclear or missing documentation
4. Inefficient architecture

Your fresh eyes can be invaluable for identifying bottlenecks that other engineers have adapted to.

If the project is higher level and influences multiple domains, it will probably be higher level. 

I agree that you'll probably be writing design docs that are more focused on the granular parts. You'll generally stick to the accepted patterns in the code base for now with the end goal of getting your project shipped.

As you progress, you'll be focused on more system design related projects and thinking about the best way to design for scalability and picking between different tradeoffs.

You are taking a great career step forward by being proactive and thinking about ways to provide value to your company.

I would start to talk to other people that are within the same domain of the project that you are thinking about working on. This will help in two ways:

1. You can validate whether the problem you are trying to solve is truly a project with wide scope.
2. You will get to know people that can vouch for you in the future. If they see that you've done the due diligence and thought hard about the problem, they will help to enable you to succeed.

I wouldn't worry too much about other people trying to poach your project. People will probably have their own projects scoped out for the next few months, and they're probably too busy to try to steal your project. If you end up being the first to have the conversations, publish a detailed design doc, and set up meetings with different stakeholders, it's really unlikely that someone would try to lead the project since you are already taking the lead on it.

I would also speak your manager about this project. They would probably love to support you on it because if you are able to execute it well, it makes them look good, too. You can probably talk about the resources needed with your manager, too.

Everyone is probably too busy with their own work to read it. Make sure to mark the doc as being in process just in case someone does read it. But, no one is going to judge the doc prematurely especially if you have the doc status set to being a draft.

I agree with Rahul about finding alignment with individual stakeholders first. You'll avoid going down the wrong path, and you will partially have their sign-on by the time you publicize the doc.

Can you bullet list the actions that you take from the time that you receive a task to the time that you meet for the second time?

You might be having a mental roadblock where you are feeling completely frozen and not sure what to do at all because the task sounds overwhelming. You might just need to do something, anything. I would start by taking 10 minutes to just summarize what you think you need to do to accomplish the task with the expectation that you could be completely wrong. The goal is to just have some path you can take and execute on rather than keeping everything in your head. When you do this, it's easy to dwell on the imagined impossibility of the task.

Once you have this path, I would have a casual conversation with your senior engineer to make sure you are on the right path.

1. You'll have done the work by taking the initiative since you came up with a plan. If you didn't do the prior steps, you won't grow as an engineer, and your senior engineer might get irritated because you've just unloaded all of the work to them.
2. They can help you identify any flaws or mistakes in your plan.

Now, you'll have the high level idea figured out, you just need to execute.

Do you find yourself just frozen in your code editor, not sure what to do? Start by just adding log statements and trace through the code. This is better than just doing nothing. Remember that you are coding in a local environment, so you can treat it as a sandbox where nothing bad can happen.

You need to clearly define what you are trying to do. Write down the different approaches you've taken, why you think they should have worked, and why they ended up not working. Then, you can bring this to your senior engineer to try to figure out where your assumptions might have led you astray. You can categorize where your deficits are: not understanding the codebase, not understanding the programming language, etc.

It also sounds like there's a sense of imposter syndrome. Try not to get too caught up in where you are now, but try to look at where you could be in 5 years if you just get the reps in and learn a little bit more each day.

How far along is your current startup? If there are urgent, high severity incidents happening every day, this could be a sign that more resources need to be dedicated to making sure the devops process is more refined. You could even be the one to run the project if you and your manager agree that this is the core issue. I would also talk to your teammates to see if they are equally stressed because this could be an opportunity for you to improve everyone's day-to-day work.

Are you the one that's solely responsible for responding to the urgent issues? Can this work be distributed among other teammates where you have an on-call schedule?

This definitely isn't sustainable in the long run for your own health and the company's health. Maybe this happens once in a while, but it should not be like this every day.

Software Engineer @ Taro, ex-Pinterest

On the one hand, you'll be able to gain trust from your manager and develop credibility with other stakeholders in your company if the business impact is high like your manager says. This can help with promotion and performance review in the future.

On the other hand, it can be difficult to juggle two projects at a time especially as someone who just started their engineering career. There will be a lot of context switching which will delay the deliverability schedule for both projects.

I would sit down with your manager and weigh the business impact of the two projects. You mention that you believe your current project has a lot of business impact, but the new project may not have as much business impact.

Can you find out why your manager believes the new project has such high business impact? Maybe they have some context that you don't have. At the end of the day, a lot of projects align to increasing revenue for the business, so you'll have to weigh that between the two projects.

You can also express your concerns that the new project might not align with your interests and career trajectory, but one quarter goes by quick, so you could set up an agreement to help out with this project for the next project to be more relevant to your interests afterwards. You just have to be firm with this in the future if they try to keep pushing down projects that don't align with your ultimate goals.

I would also set some expectations with your manager that this new project is going to take away resources from the current project. Ideally, you should wrap up your current project first before moving onto the next project.

Congrats on landing an interview!

I used to work at Pinterest. The interview process became a lot more standardized from when I first started there to when I left last year.

The phone screens are one hour long. There's around 5-10 minutes of introductions where you'll talk about what you've worked on, \~45 minutes for answering the technical question, and 5 minutes for you to ask any questions about the team/company.

You will be asked a Leetcode question for the technical question, so it is important to prepare yourself for these kinds of questions. You'll be using a collaborative web IDE called Coderpad to implement your solution. Each technical question has a scoring rubric attached to it that the interview uses to grade your solution. You need to have a working solution to the technical question to pass the phone screen, or your score won't be high enough to pass the interview.

Like Alex said above, I would verify with the recruiter about what kind of technical question they'll be asking, because it's possible my info could be outdated.

Good luck with the whole interview process!

Yup, I'm the first and only software engineer hire so far! **Most of my time is spent coding.** 

- There are three focus days where I am heads down and coding.
- There are two team collaboration days where I meet up with Alex and Rahul in person.

I am a pretty structured person, so my focus days look pretty similar. I use the first half of the day to knock out any bugs or smaller tasks. I usually have more concentration in the morning, so I can get into a nice coding cadence/flow. In the second half of the day, I will tackle larger projects or tasks that require more debugging.

On the team collaboration days, we will usually discuss the overall vision of the company or work together on tasks that require frequent input from everyone.

Compared to my last job, there are significantly fewer meetings and a lot less delegation.

There are a few questions you can ask yourself to inform your decision better:

1. How many users do you currently have?
2. How many features do you currently have?
3. What is the impact if anything breaks?

If there aren't a lot of users using your web app, then you should focus your efforts on either building out critical features or acquiring new users.

If there aren't a lot of features to test, then it should be quick to make sure you aren't accidentally breaking any existing features when you commit new code.

If the impact when something breaks is not severe, then you can tolerate some bugs if it means you are pushing the business forward without too many regressions.

It can be easy to underestimate how much work is involved with automated testing. It can be easy to set up your first few automated tests, and it even seems magical in the beginning. But, you end up having to develop and maintain your automated testing framework. There is also a maintenance burden of maintaining your automated tests (can be flaky or change often).

When you reach a stage where your product becomes critical and any downtime can really impact the customer, you can start building out a lean automated testing framework with tests for the critical paths.

Senior Software Engineer [L5]

It will be your responsibility to handle the code in the future, so I would be proactive now to make sure the code meets a certain expectation before it gets merged in. I've seen cases where hard-to-understand code gets merged in, and it ends up creating a situation where nobody on the team can understand the code, and no one wants to touch it. Everyone ends up treating it like a magic box. Then, when an incident happens, you are forced to dig into that code under a high-pressure situation.

I would recommend trying to make an attempt to understand the code, then I would talk to the PR author about the code to make sure you are both aligned. Then, I would ask the author to break down the pieces of code that are the most confusing. I would also make sure that there are clear tests written to handle all of the edge cases for that code.

When I have a design meeting, I will be taking notes in a doc, and I usually have a section that lists out of scope items. When someone is bringing back the topic, then you can explicitly refer to the list of out of scope items.

I would also start by defining the goals and timeline. If the item is out of scope, then it's usually because it doesn't pass the goals or timeline requirement, so you can use that as the reasoning as to why the item is out of scope.

Given your timeline, current experience, and desire to join a larger tech company, I would avoid trying to learn another programming language. I would instead study for general algorithms and data structure interview questions since these are the questions they will ask at larger tech companies.

Once you are in, you can start to dabble in other technologies and really hone in on what you want to do for the next few years.

1. [FrontendMasters](https://frontendmasters.com/) has courses on Node.js from instructors who work at big companies, so you can be guaranteed that the patterns that you learn will work across larger projects and companies.
2. I would also look at the source code of the Node.js libraries that you use to learn even more patterns.

To start, each morning, you can brainstorm 2-3 things that you can talk about so you aren't caught completely off guard. These things don't have to be extravagant. They can be as simple as something you ate recently, a show you started watching, or a new interest you started to pick up. Over time, you'll be able to come up with things organically.

The goal is to give the other person something, anything, that they might be able to elaborate on, either through a shared experience, or just because they are curious about what you are talking about.

You should also turn the tables around and ask them how they are doing, and be curious and open-minded about other peoples' interests.

Can you give more details about what kind of projects/work interest you the most as a software engineer? From there, we can work backwards to see whether you need to get more experience with other programming languages.

Also, what does your timeline look like for switching jobs?

If the timeline is longer, you can try to switch teams internally and work on a project where you can build up experience with those languages. If you need to switch jobs immediately, you can look for jobs where the requirement is Python but the work is adjacent to what you want to work on. Then, you can eventually switch teams and work on projects that are more relevant to your interests.

Onboarding

Testing

Playlist name

Playlist name 2

Playlist name 3

Playlist name 4

Playlist name 5

Another playlist

Really long playlist name really long

One more playlist

This is a new playlist

Networking

This is a description for the big tech playlist.
Let's make sure that this goes through.

Big Tech Playlist

Comms Playlist

Another Comms Playlist

Test

Internships are the most powerful gateway towards landing a high-quality software engineering job, especially for Big Tech. Use the resources in this playlist to become a rockstar intern and nail that return offer.