> So why should I be more productive if I'm just going to have more work to do with no bonus?

> What do you think? should I change my mindset? if yes, what are the reasons?

It's a good question to ask yourself. If you don't feel like you are being compensated for going above and beyond, there's no incentive for you to work harder, except for intrinsic motivation.

If you are feeling short-changed, and your company can't compensate you for your troubles, it may be worth it to explore different companies.

On a non-compensation level, I do think that it's more fulfilling to push yourself more to grow technically, otherwise, you'll stagnate and get bored. If you are working the same number of hours a day, you might as well be working on something that pushes you more because there's a rush to doing something challenging.

It might be an interesting exercise for you to think more about what you are looking for in the next 3/6/9/12 months. If you have a goal, like performance review or interviewing at a new company, you can work backwards to think about what kind of narrative you want to present during these evaluations. What would really make you proud and stand out against everyone else?

Eng @ Taro

Charlie Vuong

I really do think it's worth it to set yourself up for success as much as possible in the beginning, especially when you have that new hire energy. It's way harder to change other people's perception of you the more time has passed.

For how to select the cases, you still don't want to sacrifice your health or social connection because you'll burn out very quickly. But, if you can find pockets of time (1-2 hours) throughout the evening where you can sneak in some code, it can make a big difference over the course of a month.

It's definitely good that you are doing as much research as possible. Doing hours of research is pretty typical especially if you consider the impact of the decision. Your decision could potentially influence thousands of engineers with millions of users depending on how mature your company is.

One thing to keep in mind is that everyone's use case is different, so make sure that you get the full context around what you read on the internet. Because, it's possible that someone is using the library for a pet project which may not scale up. Here are some other things to consider:

1. I would try to involve other engineers in your company as much as possible, preferably people more senior who can give candid feedback based on their own experience. They will be interacting with the library, too. They'll be skeptical because they don't want to clean up any messes, so they'll usually be on the cautious side. Create a design doc with all of your findings, and share it with other engineers. Include the tradeoffs between using each library. Come up with a list of requirements beforehand that the libraries need to meet.
2. Have the libraries been used by larger companies for a long period of time? This is a big one because you can use their experience as a proxy of how you'll consume the library at your company. You'll be able to get a sense of how the library works at scale.
3. Can you create a proof of concept using the libraries tackling the most complex use case of your product? You want to avoid using the simplest use case because you won't be able to see how the library performs under the worst case. If you can simulate the scale, you should try to do that.

For the highest performers, sometimes it's not all about how they structure their day but about what they decide to work on given an allotted amount of time. It's possible to have a situation where you have two people, one with a chaotic schedule, and one person with regimented focus blocks. But, the person with the chaotic schedule may be more impactful because the decisions they make lead to the biggest business changes.

Here's more insight into the Taro schedule:

We have a sprint planning session Monday morning where we plan out tasks that we want to complete. But, there are always changing priorities where new issues will pop up throughout the week. So, we are always adding new tasks to the sprint or backlogging existing tasks.

Since the team is so small right now, I'm grateful to have open blocks of time where I can focus on coding for most of my days.

And if I need to sync with Alex or Rahul, it's fairly easy to get on a call with them to work through any issues.

For productivity and health, I'll go to the gym in the morning. If I miss it, I'll go to the gym in the afternoon. If I'm really not feeling productive at my place, I'll go to a cafe to change up my environment and jolt myself into concentration mode.

If possible, I would try to talk to people that work on each of the teams that you are considering. It looks like it'd be 3 teams, since you're on one of them now, and you used to be on one of the other teams. I would try to ask questions about career growth and self-fulfillment to get a sense of how all of the teams compare to each other.

A career growth question might be asking how many engineers were promoted within the last year.

A self-fulfillment question might be asking about what kind of projects are being worked on.

The current team you're loaned to does sound solid, and if there aren't any big reasons to leave that team, there's no shame in staying on the team. Since you're not worried about things that plague bad teams, you can focus on career growth.

A lot of modern frontend technologies were created because they addressed problems with libraries in the past or because browsers weren't able to handle a use case in a simple way.

For example, it might be hard to understand why people use React unless you've had to add/remove DOM elements using Jquery before. Or, it might be hard to understand why you would use Next.js unless you've tried to render React components on the server before.

You probably could jump into the code immediately, and you'd probably be successful in fixing smaller bugs, but you'd be taking a lot of guesses about how everything is working together.

I would dedicate 1-2 hours reading about React, Next.js, and Tailwind so you can get a sense of what they added to the web ecosystem, and how they work at a fundamental level. This might be reading 10-20% of each of their documentation. I would avoid reading 100% of their docs because a lot of it won't be relevant. You can always go back to read the rest of the docs as you come across specific issues with your particular codebase.

> When the interview is done, I keep thinking about it and then I figure out the optimal solution on my own, and keep thinking why the heck I could not figure it out during the interview. I don't know, it's as if during interviews, my brain capacity operates at 70%, I become super narrow in my thinking, I cannot think comfortably and I'm tense, I really have trouble coming up with a solution and talking to the interviewer at the same time.

It does sound like you're getting performance anxiety, which is understandable because the stakes for an interview can be pretty high. I've been in interview situations where the interview will ask me a question, and I immediately freeze up.

How do you normally prepare for interviews? If you can simulate the real interview process as closely as possible during your preparation, there won't be any surprises when you interview. You'll also be able to build the confidence because you'll know exactly what to expect. So, you might try the following:

- Make sure to put a strict time limit on yourself when you go through Leetcode exercises
  - When you don't get a question correct or aren't able to do it within a certain amount of time, don't just go to the next question. Make sure you really know what happened. Was there a DSA pattern that you missed? Keep a note with all of the missed questions so you can go back to them later.
- Do a mock interview with a friend
  - You might even record the interview to really put more pressure on yourself. But, it's mainly to check your body language, check where you have any pauses, or check your behavior when you're working through a tough question.

Try to develop a growth mindset about the whole interview process where each interview provides an opportunity to collect 2-3 things you can improve on to make your next interview go more smoothly.

I know someone who told me they were consistently bombing interviews, but they kept preparing and preparing, and after a year, they were consistently getting offers from companies they interviewed at. They said a big part of it was just always having something to say when they were working through a technical question.

> within a work-bloc, having longer time spent at your desk - so sitting interrupted at your desk for over an hour, for example. If you're following the health gurus, you should be standing up often, and the Pomodoro technique is classically 25-minute focus blocks, but I don't know how practical this is

I usually only use this method when there's a task that I keep procrastinating on. If you are completely focused and locked in to what you are doing, I think it's better to ride that focus as much as you can until you finish the task. I mainly use the technique to force myself to get started on something because I always have a realization that a lot of the anxiety I have from starting a task is because I artificially inflate how difficult a task will be in my head (or I artificially inflate how boring the task will be). When you can take the feelings out of a task, it's a lot easier to complete.

> cutting out gym time to get more work done - for me, exercise is generally 1 - 1.5 hours of time which I do 3 or 4 times a week, so I can get more keyboard time in if I cut it.
>
> working later into the night and either cutting into sleep time or just waking up later the next day

I would be careful with these two, because once you start missing a workout or change your sleep schedule, you can continue to let them slip, and then you'll have another issue on your hand.

> In my case, I'm onboarding and think I'm behind on my first ticket, hence the motivation for my question.

Can you reflect on why you are or feel like you are behind on your first ticket? I will say that sometimes it is worth it to make a sacrifice, especially if you are onboarding with a new team or company because that first impression is very important. Is it because of procrastination, mismanaged time, or the ticket wasn't scoped well. If the ticket wasn't scoped well, I would communicate with the team what your initial expectations for the ticket were, and how the scope creeped up, so you need to take more time to solve the ticket.

> I don't anyone who would *actually* want to use and not use it because I'm asking/making

There's a book called "The Mom Test" where the author teaches you how to talk to people without biasing them before building our your idea. I highly recommend reading that book to find out how to measure demand for an app.

If this helps at all, here's how I plan out my cooking:

I will usually use Sunday to plan out what meals I want to cook for the week. I usually cook 4 recipes total, two for lunch, and two for dinner, but I cook enough where each recipe lasts 3 meals. For the recipe generation step, I usually will see what's on sale at a grocery market or I'll check my fridge to see what ingredients I have. I'll usually look for a new recipe or see what I've cooked in the past.

It sounds like this is where your app might step in. Do you know what your app would offer me over looking through my notes to find recipes I've cooked in the past?

Since you know most of your teammates from a work context, you can try to talk with them about non-work work, like what they like to do for fun.

> *Is it supposed to feel like I’m doing small pieces that add up over time with this practice? I might be wrongfully thinking every day with software I should be treating it like an intense workout instead of a slow jog with sprint bursts when the problem gets hard.*

You do want to work in a way that's sustainable for the long run. Something like a medium pace where you are still pushing yourself, but you aren't getting stressed out. It's okay to go for the bursts occasionally when there's a tight deadline, but you also want to avoid doing it all of the time, because you'll end up resenting your work, especially when it means sacrificing other things in your life.

> My behavior would be to set expectations with people around me and give a plan to others so I don’t get overwhelmed thinking I need to work late to deliver on these seemingly harder projects at the same pace I deliver the easier high volume projects.

There's something called a spike task where the task is figuring out all of the unknowns. This makes a lot of sense when you haven't worked on something before, so you aren't sure about what the full scope is. I agree with you that you should communicate with your team that you're going to be spending x amount of days researching the issue so you can fully understand it and break it down into individual tasks.

> Im sorry but I’m just feeling icky that sometimes behavior over output also means reaping spoils of doing more with less work even at the execution level

Another way to frame this is making sure you are striving for "impact" rather than "output". As you become more senior, your coding output will probably slow down because you'll be more responsible for coordinating projects and thinking about the higher level impact of different projects.

> Our deadline is in a month, as I'll be going on leave. I wanted to do a portion of the FE just to learn more about frontend technologies and was assigned tickets, however my senior engineer has started work on these and it looks like most of the work I'm going to be doing, apart from my tasks, are going to be reviewing/testing my senior engineer's PRs. I've worked with this part of the product before but I was hoping to get more exposure and practice.

I would chat with them to see if you can help them with the frontend work. If they are more senior doing FE, there's probably some work they are doing that they've done a thousand times. Those tasks will be a good match for you because:

1. They'll be able to support you through the task if you need it
2. They'll be able to work on something that pushes their limits a little bit more
3. The task will still be novel to you where you'll be learning

Here are some paths you can go down to generate ideas:

1. Is there anything in the development cycle, from coding to build to deployment, that is frustratingly slow or inefficient?
2. Are there a lot of incidents happening in production? If you have on-call, is there anything that could be better?
3. Every company has a set of metrics that they are trying to move. Can you brainstorm any ideas where you'll be able to improve those metrics?

Once you have some ideas, the next step is to decide whether they generate enough impact for you to pursue them.

Is there any way you are able to categorize the questions into themes? I think that a lot of questions can be bucketed into two themes:

1. Execution
   1. What's the high level solution you're going for, and why is that the best solution out of the other solutions?
   2. What's the timeline for your project?
   3. Are there any blockers?
   4. Is there anything that can make your project move faster?
   5. If you have XFN stakeholders, do you have buy-in from them?
2. Impact
   1. What kind of impact is your solution actually going to provide? (quantify if possible)?
   2. Can you think of any cases where you end up shipping your solution but it doesn't actually have the impact?
   3. Is it actually worth solving this problem?

> Follow up: What to do when you're thinking about an answer and don't have the answer in your L1 cache and you're trying to think while answering

Can you say out loud how you are approaching the problem. For a question, you'll probably be given a set of input and some constraints or maybe it will be completely open-ended. What will help is to think about the ultimate goal and work backwards. Talk about any tradeoffs you have to make while coming up with the solution.

You don't need to have the perfect solution from the very beginning, but your thought patterns should be rational and flow smoothly.

I know that all seems super abstract, so maybe a counter-example will help. I've interviewed candidates that will just throw out multiple random solutions like there's a grab bag of solutions prepared beforehand. I would avoid doing this.

You could try to build a flashcard or notes app. Is there something that you keep track of each day in a note or spreadsheet that could be its own app? This would be a CRUD app that should exercise a lot of the learning muscle.

For UI library, you can import components from Chakra (<https://v2.chakra-ui.com/>) to use in your React app. If you do this, you won't need to worry about building out individual components, so you can focus on the higher level React state management and data flow concepts.

You might want to just try to wing it to see how disorganized the code can get before you need to apply some order. Creating folders for components, lib, constants, and hooks can get you pretty far.

That's an interesting challenge. You might be able to delegate a lot of the HTML/CSS work by using a UI component library like Chakra (<https://v2.chakra-ui.com/>). This will give you a palette of pre-built components that you can use. You probably do need to go through the React docs (<https://react.dev/>) though, but you can understand the core principles of the framework within an hour.

React is the most popular framework used across most tech companies, so I would definitely invest time in learning it. I would start by going through the official React docs (<https://react.dev/>). If you are just getting into front end engineering, I would try to get the most basic webapp working before trying to overcomplicate things by looking into different libraries and design patterns. You can get pretty far by just using vanilla React.

As far as project ideas, I would try to brainstorm 5 things that you think would be interesting to build. And pick the idea that is the most interesting. This will be a very personal thing because someone else might have an idea but your energy/motivation to work on it may be low. Your goal is to milk all of the momentum and energy you have right now to ship a webapp.

If there isn't a testing framework set up yet, it's probably not worth it for you to set one up right now. I agree with Rahul about focusing on development velocity as an intern. There will be a lot of discussions between multiple teams if you want to implement a testing framework that every team can adopt.

But, I do think there is a point where companies do need to adopt some automated testing when the number of engineers increases, the frequency of incidents increases, and incidents become more costly. You'll know when this point comes because it feels like you are always taking a step back with every commit, and you can make no forward progress because you're constantly fighting fires.

You can do all of the above :)

For a more substantial increase, you'll probably be looking for a promotion, either internally, or externally.

You can uplevel your current knowledge by working on projects with more scope. When you get these projects under your belt, you'll be able to interview externally to show that you have senior-level scope. You'll also be on track to be promoted internally if the external interviews don't work out. So, you can work on two parallel paths to increase your total comp.

When you are working on projects with more scope, you'll be interacting with people across different teams. When they leave the company, and they had a good experience with you, they'll probably reach out to you for opportunities, too.

Here are some thoughts:

- Can you quantify the time saved on your projects? You can compare the time it used to take before you built out the tool versus after you built out the tool.
- Can you quantify the scope of your project by how many engineers were affected? You can talk about how many engineers you worked with or how many engineers are using your internal tool.
- There must have been a good reason to build the internal tool, so I would lean into that as much as you can.

I'll reframe this question to change California into the Bay Area because California is a huge state.

I do think it's worth it to start your tech career in the Bay Area if you are very career-focused. You can meet a lot of other ambitious software engineers who are on the same path as you. You can meet software engineers who are on one step above you who can give you the inside scoop on how they progressed in their career.

That kind of information can help you to short circuit making a lot of mistakes that people make. It's not as tangible since there isn't a dollar amount, but it can help you to get promoted faster or learn about a company who has a high growth trajectory.

It's harder to do this remotely because a lot of the info comes out when you start having deep conversations with people outside of work.

Also, the weather is amazing :)

It's probably worth a shot to explain to your manager that you really like the team and the work, but you also need to be close to your family. You can explain the impact you have in the company and how you wish to continue to work there, just to make sure your manager really knows how valuable you are. Hopefully, they'll be able to make an exception for you. It does sound like you have a lot of leverage right now.

How would you weigh career progression compared to staying at your current company? It's possible that you'd still be able to progress quickly at another remote company. Maybe, you can even come into a new company at a more senior role and that would check two boxes. (I'm not sure what level you'll be coming in for your new offer)

A lot of companies will have some criteria they use to decide whether someone is ready to be promoted. I would try to start from the end goal: what does a senior software engineer looks like at your company.

It usually boils down to project scope and influence scope. Project scope is related to how impactful your projects are to either other engineers (for example, in engineering productivity or internal tools) or to your users (for example, increasing conversion). Influence scope is related to how impactful you are to other engineers in your organization (this might be input on technical design or mentoring other engineers).

Once you have those in mind, you can brainstorm what projects or actions would get you to that scope.

You want to make sure everything is in your favor during your interview especially since it's so high leverage to be able to get the job offer. I also agree with Sai and Alex about using wifi calling (and checking to make sure wifi calling is stable and clear).

I've given interviews where the other person's connection is unstable, and they connect/disconnect frequently. It does alter the experience of the interview experience because it's harder to stay focused on the solutions that the candidate is proposing.

**Overrated: mechanical keyboards**

I like using the built-in MacBook keyboard or the external Apple magic keyboard more than most mechanical keyboards because you don't have to press the key as far to register the key. There's enough haptic feedback when pressing a key without the key press being obnoxiously loud (I was even using pretty quiet keys).

**Underrated: office chairs**

If you are going to be sitting down 8 hours/day, 5 days/week, how you sit can have a huge impact on your back health and posture.

But, I could also see this being overrated because the gold standard for ergonomics would probably be standing.

> Moving from consumer to enterprise at the first glance doesn't seem interesting. I am not sure how will it go with time but if anyone had this experience in their career, please consider sharing.

I have moved from working on a consumer cloud sharing app to working on ads. At the beginning, I had similar feelings to you. I "knew" consumer apps because I use them every day. But, I don't know anything about enterprise products.

You start to change your thinking to: given this space that I know nothing about, how can I provide the most value to users, and you start to think of it as a set of challenges of learning about a new domain. Even if you're not personally excited about the enterprise product, your audience is still users. They are users that are just working right now. You can make it easier for other people to get their jobs done more effectively.

> Then I start getting asked simple questions I didn’t think to prep for.

Those trivia type questions can take you for a ride because you either know them or you don't know them. I'm actually not a huge fan of them compared to Leetcode coding questions because you can't reason through them.

That being said, it's probably worth it to look up common interview questions for backend engineers to make sure you don't stumble up on those questions if a company does ask trivia-esque questions. Although, focus less on the rote memorization and think about tradeoffs between using different technologies. For deeper learning, you can connect the technologies with your own experience.

As far as mindset about the job market,

Your peers are probably having issues with the job market, too. Is there anything you can do to differentiate yourself from them? Think for job searching as a funnel. Can you get more opportunities to widen the funnel?

As far as learning as much as possible,

Have a more proactive attitude for solving issues. Instead of just taking tasks, propose actionable solutions to technical problems that you're seeing in your day-to-day. Don't shy away from impactful problems because those are sources of opportunity.

> We know onboarding is already tough - meeting new people, understanding new codebase, etc. In the first few weeks especially, how do you manage so many things?

There are definitely a lot of different priorities to juggle, but your team will be more forgiving to new hires, so you do have some leeway. That being said, you should really strive to put in the extra work at the beginning to ramp up as quickly as possible. I also see that you are an intern, so they'll probably be even more forgiving :)

> Let's say I don't have ANY frontend experience in the past, but somehow get hired at a FAANG as a frontend dev.

The good thing is that you can do some supplementary studying to get a better grasp on frontend technologies. I recommend [Frontend Masters](https://frontendmasters.com/) to learn more about web technologies. Focus on the courses that apply to the tech stack that you're working on.

I would try to think about what your end goal is for watching the online course. There's usually some reason for why you decided to watch the course. What do you want to get out of the course? As you go through the course, constantly try to connect each section with whether the content gives you some tangible action items for how to achieve your goal.

I am always taking notes when I watch courses. My notes are paraphrasing the content in my own voice or associating the content with ideas related to other subjects. I also take a lot of screenshots and annotate the screenshots. Watching a course should be a very active process.

I usually timebox watching courses to 30 minutes/day. Any more, and I start to zone out. My mind ends up feeling like a leaky bucket where any new ideas just stop sticking. Sometimes I need a good night of rest to really make sense of the new concepts from a course.

Hi, it's completely understandable to be feeling this way. I've talked to many people who are in the same position as you, who are feeling similar negative emotions. So, you definitely aren't alone :)

> Especially when seeing few classmates land jobs and I'm still struggling here

It may be useful to disconnect yourself from them getting the actual job and try to break down how their process is different from your process. Maybe you can reach out to them to ask them what worked well for them. I'm sure they have a lot of positive energy right now where they'll be happy to go through their process.

> Struggling to land a job in this market has me feeling like a failure/I'm doing something wrong even though I did all the "right" things when starting college (get good grades, do LC, get internships, do projects, network)

It's easy to fall into these negative thought patterns and dwell on them endlessly. There will always be something that you are lacking that someone else has. So, these thoughts won't just stop after you end up finding a job. Can you try to do something actionable with that energy? The worst thing you can do is to just lay down and just keep running through these thoughts over and over.

> Posting in a large group specific guidance doesn’t always yield practical advice due to its broad focus

There's probably a diffusion of responsibility that goes in these larger channels everyone thinks someone else is going to answer. Or, people have effectively blocked out the messages in that channel because it's too noisy.

Can you try to directly reach out to people who have worked in an adjacent project or within the same tech stack? These people will probably be able to help you out because they are familiar with what you are working on, and they can end up being an informal mentor for you.

While it's true that companies might be outsourcing some roles, I've also seen companies be reluctant to outsource roles because of quality concerns, especially for long-term projects with large impact. If you need to eventually refactor their code or hand hold someone, they can end up being a net negative for the company. Of course, this isn't true across the board because you can have the same issue with onshore software engineers as well.

Companies usually mitigate the risk hiring offshore engineers into roles where they can speed up the code development of a project, but less so with making higher level decisions. So, if you can up your experience in leading larger projects from start to end, you may be able to shield yourself better from this.

A lot of the larger tech companies have return to office policies which is also a sign that there is something special about being able to work within the same proximity as your teammates that can't be replicated remotely. In my experience, it's a lot easier to hash out a complex problem in person because you can resolve any issues immediately rather than waiting until the next day(s).

Hmmm, you could be very blatant about it and ask about how the codebase has evolved over time. Many companies significantly transform their code bases as a result of poor preexisting coding patterns or have to switch frameworks/programming languages for performance gains, so I don't think it would be that offensive to the interviewer if you asked this question. The answer could provide some valuable insights about how engineering leaders thought about the future when making the decision.

If they do hint at a refactor, you can ask about what the initial goals were with the refactor and whether they ended up achieving those goals. The answers will usually give you a good sign about whether a refactor was justified or not.

I agree with Rahul about making code changes as soon as possible. You'll be able to learn a lot from anyone on the team. The intern will be able to give you some pointers because they're more familiar with the code than you. Take that advice as early as possible.

As far as other tips, I would just go crazy in your local development environment to test any assumptions you have about the codebase. When they don't align with what you had in mind, keep track of them so you can ask your teammates about them when you get into the office.

There have been many times where I have experienced company-specific domain knowledge that I wouldn't have been able to figure out just by going through documentation. Either because internal documentation is out of date or there's one gatekeeper of the knowledge that hasn't written down the information yet.

I find that it slows me down because as my code evolves, I have to refactor my tests to fit the code.

When I write code for a new feature, I have a general direction that I want to take it, but along the way, I will discover a better way of writing the code. The new way is usually incompatible with the tests that I initially wrote, so it can slow down development to have to refactor the code and the test.

> It feels a little disheartening to constantly see other people being smarter than me when learning new things or navigating things on the fly.

I can totally understand how this can feel bad because you are judging the rest of your trajectory based on this one piece of information. But, you don't know what kind of prior experience someone else might have that could have given them a leg up on that thing in that one moment.

It's more fruitful to focus on where you are at now and how you can improve that situation. Think more about how you can refine your process of how to get better at something.

I'm more familiar with seeing Node.js used as a backend for web applications because Node.js has a richer developer ecosystem for supporting your webapps. Although, that doesn't mean that you can't use Go as a backend for a web application. You can absolutely treat your frontend web app as something that's decoupled from your Go backend.

But, one big benefit of using Node.js as a backend for a React webapp is being able to render React components on the server and serve the rendered pages to the client. You are able to share the same React components on both the frontend and backend.

> This also happened with cochroach db interview where this very senior engineer figured out the material I was using and asked a targeted question that he knew was a flaw in design but not discussed in educative course

This can be tricky because they need to test the depth of your system knowledge so they can evaluate you accurately.. They need to figure out where book smarts ends and experience starts.

Another resource you can use is <https://www.quastor.org/>. They send a newsletter out that summarizes technical blog posts that companies publish. These technical blog posts are usually more in-depth, and they go over challenges that companies face while implementing their systems.

**Is it possible for you to continue doing your hobbies and have family time?**

You might end up resenting or regretting the time you used to learn something new if it means you miss out on these opportunities. 

Can you find 1-2 hours in the day for study? This might come in the form of cutting down on less significant activities like streaming shows, offloading chores, etc. You could also sleep later or wake up earlier for studying.

It might be worth it to track how you spend your time each hour for the span of a week. Are there any items, where, 10 years from now, you wouldn't have any regret if you didn't do these items? Cut those items out, and use them for study.

> How to enjoy sitting long hours while learning a new thing for several weeks or months

Can you break down what you are trying to learn into 2-week chunks? If it's a blob of "I just need to learn X", it's hard to see what the end goal is. Ideally, you can create goals for each 2-week period, like you want to ship X that demonstrates what I learned in that 2-week period.

I agree with the "**Give responsibilities back**" piece of the article. When someone new joins your team, it's because they can help your team achieve its goals more effectively. It's not to create more work for you but to reduce the amount of work that you have to personally take on.

It's not sustainable or fair to Joyce to have to do her team's work:

1. The team's growth will be stunted because they won't have the opportunity to learn more if someone is doing their tasks for them.
2. Joyce runs the risk of burning out quickly by not taking time to disconnect from work on the weekends.

For me, **\#3** stood out the most for the following reasons:

1. You were responsible for the **execution** of the project from start to end. Your teammate may have done the high level design, but I wouldn't downplay the work it takes to actually carry out the project to completion, which I would argue is even more important.
2. If there was another team who consumed the service, you had to communicate with them to let them know about the new changes so everything worked seamlessly during the migration. Without your work, the service migration would have been blocked.
3. You were able to break down the task into smaller parts for a new grad to work on. This demonstrates mentorship ability. it shows that I can trust this person to lead a project with multiple stakeholders involved.

Technical complexity can be low, but the business impact can be high. When the prompt says "challenging", they didn't necessarily specify technically challenging.

> This second-guessing is causing a great deal of mental load for me. I also feel like if I ask my manager too often whether I am prioritizing correctly, he might feel like I am not behaving like a senior engineer. Any thoughts on how I can get out of my own way here?

One thing that will help is thinking about the end goal and working backwards. The end goal might be improving a team OKR, working on projects with enough scope, or mentoring "x" other engineers. This will give you confidence about whether you are working on the right thing.

When you have 1:1s with your manager, make use of your 1:1 doc to outline exactly what you are planning to do and what you've done. This will hopefully remove any ambiguity about what you are working on since your manager is basically signing off on what you've put in the doc. Your manager should flag any work that's not high priority and help you course correct if they think you're going down the right path. It's okay to go over who you are helping to mentor and how you are helping them.

Here's a list of recipes that I cook that optimize for saving time, being nutritious, being able to cook in large batches to last the week, and being low-cost:

- Chipotle burrito bowls (<https://www.youtube.com/watch?v=OChZDrivjJw>)
- Egg omelette with potato hash (<https://www.youtube.com/watch?v=WqrV-OOM_QU>)
- Harissa honey chicken + rice (<https://boldappetite.com/harissa-honey-chicken/>)
- Balsamic chicken thighs + rice (<https://www.youtube.com/watch?v=TNr0IRTXJPc>)
- Quesadillas (<https://www.youtube.com/watch?v=DIBCFVCQqfs>), I actually haven't made this yet, but it's on my recipe queue

I don't think it's necessarily a bad sign. It could be as simple as the team having a brainstorming session for new hire tasks before you onboarded, and they realized they were lacking in unit tests. It's a good way to get familiar with the codebase without causing any incidents.

Most teams are pretty forgiving with new hires, so they probably wouldn't lose confidence so early. I would just make sure to be pretty diligent with getting the unit tests done as quickly as possible. I imagine they will have some tasks with increasing complexity lined up for you after you finish writing the unit tests.

I worked at a company that had an IPO, and we had a 6-month lockup period where we couldn't sell our shares. I imagine there may be a similar case with Stripe, so you wouldn't be able to sell your shares immediately after Stripe IPOs.

There are two schools of thought about how to treat your shares once you can sell them:

1. You can treat your shares like cash and sell them immediately.
2. You can hold on to your shares and reap the significant financial benefits if the company continues to grow.

Option 1 is one way to derisk yourself because you can sell your financial concentration in one company and use that cash to diversify into different companies. The con is that you end up eliminating your upside if a company does well. A common question people ask themselves is: "Would you invest in the company if you had cash reserves lying around?"

Option 2 is the riskier approach, but it can come with significantly more upside if the company does well. The concentration into a single company is how people can become very wealthy.

I would try to think about companies in a long time horizon, say 5-10 years when you make your decision. It can be easy to be reactive when you see short term fluctuations with the share price. Here are some other questions that you have to ask yourself:

- Do you need the cash now? Maybe you need a down payment for a house.
- Do you see any reason why Stripe would/wouldn't succeed? How much conviction do you have?
- Does the company have a moat where competitors will have difficulty competing with them?
- How sticky is the product? How much effort is required for a company to move from Stripe to a competitor?

For junior and mid, I'd be more interested in the scope of the projects that you've undertaken. I would define scope by complexity of project and collaboration with stakeholders. This gives a good signal about the technical depth and communication of the candidate.

> However, for lower levels (junior and mid), if impact doesn't matter, and execution is 100%

I would argue that even at junior and mid, demonstrating business impact is still more important because it shows that you understand "why" a project had to done in the first place. Especially at larger companies, this is what you'll be judged on the most.

This issue can be difficult because you don't want to blame them back even if they contributed to the mistake. It's also not great for the engineering culture because people will be afraid to make mistakes. This can start to present itself when people want to do the minimum to decrease the potential surface area of their mistakes.

For larger incidents, you can look into having [blameless post-mortems](https://sre.google/sre-book/postmortem-culture/):

> For a postmortem to be truly blameless, it must focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior. A blamelessly written postmortem assumes that everyone involved in an incident had good intentions and did the right thing with the information they had. If a culture of finger pointing and shaming individuals or teams for doing the "wrong" thing prevails, people will not bring issues to light for fear of punishment.

You can come up with a template for a blameless post-mortem and talk to your manager about it to get it spread throughout your team or org. We used to have a weekly meeting where we went over incidents following the above protocol to make sure issues don't happen again.

Every time I think I've had a novel idea for a side project, I usually find out there's a company already doing something similar. Ideas are cheap. It's all about execution.

It's true that more mature companies have the resources to build out a similar product, but they also have disadvantages. They will move slower because there are more levels of approval that decisions have to move through before a new product/feature can be built.

A smaller company can just move faster. They might not have the most polished product, but they can get it out the door faster and capture the market share, possibly creating network effects making it difficult for existing users to move off.

When I was interviewing, I would schedule my lower priority companies first and schedule my higher priority companies later. Here are the benefits of scheduling the lower priority companies first:

1. You can get the interviewing anxiety out of the way.
2. You can find out whether you have any gaps in knowledge.
3. If you get an offer, you won't feel guilty about letting it expire since it's not from a company at the top of your list.

If you are feeling the interviews are too hectic where it's affecting your performance, it's okay to space them out more.

Make sure to have an interview retrospective at the end of each interview to go over what went well and what could have gone better. Use that knowledge to decide what skill you need to invest more time into.

If you are building out a new testing initiative, it's helpful to gather all of the previous incidents to show that your new initiative could have helped to prevent \~60% of the previous issues.

Moving forward, it's helpful to get a benchmark for how many incidents and their severity before your testing initiative. Then, you can track to see whether the number of incidents and their severity have gone down.

> For 1-on-1s like this, what strategies do you use to build strong relationships quickly?

It's very helpful to find out if there's a similar connection between you two, maybe a hobby or where you live. Even when there's no connection, you can dive deeper into what the other person likes to do in their free time. Once you get the wheels greased, it's easier to talk about work-related items.

Try to provide value to the other person by connecting them with other people, showing them easier ways to get something done, or by pointing them to a resource to help out any problems they are facing.

Here are some tactics:

1. For an interview, it can depend on how much leverage you have. If you have other offers, you can hint that you have other offers (if you actually do have offers) or that you are actively interviewing.
2. You can set up a meeting with someone to work through a technical problem and pair program with them. It's possible the person just psyched themselves out with the task, and they are procrastinating on it because there's a lot of uncertainty in the task. It can help them a lot because you can clear up any uncertainties as well as to show them how to do the task effectively. This is useful when you have more experience than someone.
3. You two can figure out an ETA for when a task should be done. You'll be able to set up an anchor point for when to at least expect the task to be done. It forces the other person to think about their schedule and where they can slot in a task among their other work.

Your manager probably recognized that it can be frustrating to have to "redo" work that is already working.

> But I’m confused why I’m getting praised. It feels like I’m getting praised for breathing.

Haha, that's a funny way to put it. From your manager's POV, there's probably no harm in making sure that you aren't upset that you have to refactor your code. You took the right action to quickly refactor the code, and it will probably reflect well from your manager and the senior eng's POV.

I would wait to see what the results are before looking too much into it. It's possible the interviewer could be asking standard questions without paying too much attention about your answers.

I would try to do this without looking at the code to see how far you can get. Really struggle on the problem because that's where the learning will take place. Try to think of 3-5 different solutions to solve the problem. And remember, the solution doesn't have to be the best solution.

Lee had a really good response for preparing for the Amazon behavioral interviews here:

<https://www.jointaro.com/question/oG3Wf6gTA3Q7JtvYYDYe/how-to-prepare-for-amazon-behavioral-interview/>

I would make sure you are telling stories that demonstrate leadership abilities with a large scope and an impactful outcome.

I have journals for every subject where I want to improve: cooking, nutrition, gym, work, podcasts. When I don't reflect on how something can be improved, I find myself getting into bad habits that I might not notice or address for many years.

An entry will usually be the date and a bullet point of what didn't go right and how it could be improved. I try to make it as simple as possible. Example entries might look like:

- 4/16/24 (in the cooking journal)
  - Cooked "X" for 2-3 minutes too long, came out very dry
    - Start checking temperature at the 10 minute marker
- 5/1/24 (in the workout journal)
  - Did "X" exercise, but feeling it in "Y" muscle instead of "Z" muscle
    - Lower elbows and bar next time to feel it more in the "Z" muscle

I do make it a point to make the notes short to reduce the time it takes to write them as well as reflect on them later. Every 3-6 months, I will sit down and review the notes.

If you have robust logging and an automated way to turn off the switch in the case of a high failure rate, you could make the case that you'd be able to detect any issues as soon as you enabled the switch and roll back immediately. I have experienced cases where we gradually ramped up an experiment, and we only started to detect issues when we rolled out to a higher percentage of the population.

But, if the service is a high TPS service at the scale of a big tech company, I'd imagine you'd want to mitigate any failure rates if you can avoid them, and that would mean having a gradual ramp up period. Definitely ramp up to internal users first to make sure nothing silly/obvious mistakes get rolled out to external users. The higher the impact of the service, the more care you want to take.

Either way, you should have a very good logging system in place to make sure you're not flying blindly into a mountain.

Congratulations on your offers!

I'm so grateful that you shared your experience with others on Taro because it can encourage other people to trust the process and continue to chug along.

> To be honest, I feel like the biggest gap was DS&A

For others looking to improve their DS&A skills, what do you think helped to improve your skills the most?

This is a great question because we like to focus on the potential upside to switching jobs, but it can be easy to discount the downsides.

I've seen a phenomenon happen where someone will start to burn out at their current job and become jaded about the company. It can be easy to accumulate negative experiences with the company the more time you've spent at the company. They'll switch jobs, and then they'll experience the exact same issue after a year or two. And, the cycle will continue again and again with their next jobs.

You can miss out on career progression if you make too many lateral switches in your career. If you switch companies, but you end up at the same level, you can potentially delay your promotion for 2+ years because you have to prove yourself at the new company. If you stayed at the current company, you have a long list of projects that you've worked on at that company, so there's more reason for you to get promoted.

Note, the above isn't relevant if there is a true fundamental issue with the company, like if you are working in a toxic culture or the company isn't moving in a positive direction.

> What might be the mental model to forget the past?

It can be difficult to wipe out memories from the past, especially if they are traumatic. It may be more useful to try to reflect on the experience to think about what went wrong and whether any of issues were under your control. You can reframe the experience as something to be grateful for if it led to successful behavioral change (if there were things that were under your control).

> Sticking around for almost two years now, what might be the correct time & way to reach Next Level?
>
> Currently working on multiple projects at the same time and grabbing almost whatever task is offered and somewhat gained trust I believe. But the quality of those tasks are not too much complex rather modular & takes more time. I can keep on doing this way but not sure what is the right thing to do.

The next level is about being more independent and proactive as a software engineer. Most software engineers who are just starting out play a more reactive game where they are assigned tasks, frequently get stuck while doing their tasks, and have to ask people how to get past the tasks. At the beginning, it can be harder to grasp the full depth of an issue can be, so your code can end up causing negative side effects because you don't understand the full context.

For the next level, you should be able to scope out more complex tasks end-to-end with very little hand-holding.

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.

> 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.

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.