In the beginning, you're probably going to be given less time-critical tasks, so it's a good way for you to learn the codebase and go at a reasonable pace so you can start to calibrate how long it will take for you to do different tasks.

I'm not sure if I would even ask your manager about whether you are going at an appropriate speed. Because, if you are going as fast as you can, what can you do if they say you need to move faster if you are already going at max speed? I would spend the next few weeks orienting yourself around the codebase by fixing as many tickets as you can, so you can get a sense of how to calibrate how long it'll take for you to fix issues.

After a month or two when you are making larger code changes, you can start to let your manager know that "task A is going to take a week because X, Y, and Z need to be done", and then you can gauge whether that's an appropriate amount of time by their response.

Eng @ Taro

Charlie Vuong

The best senior+ engineers that I've worked can do the following:

1. Identify the best problems to work on
2. Go through the work of scoping out the problem
3. Create buy-in from different stakeholders to agree on the problem
4. Carry out the solution end to end, usually by delegating the work across many engineers on different teams

And, they are able to juggle multiple of these projects at the same time

I would show them your potential by being very thoughtful in the kinds of questions that you ask. When you talk to them about potential issues, you should be fully laying out your entire thought process, possible solutions, how you decided to go with one of the solutions. This demonstrates that you can think for yourself.

You want to avoid falling into a trap where you are just taking, taking because you know there's a resource available that can give you the answer immediately.

Definitely make small talk with your co-workers so you know them on a deeper level. It's easier to trust someone if you know you have the same values as them. A lot of strong networks are built on the foundation of trust.

I wouldn't use self-deprecation. I think how you speak about yourself can change your perception about yourself, and you can end up creating a self-fulfilling prophecy.

I haven't found an LLM that can analyze the entire codebase across multiple files and understand the context that well. I'm using Cursor with Claude 3.7 right now, and the codebases I've been working on are primarily mid-size React projects.

Here's what has been working really well for me:

- Autocompleting and updating references
- Creating utility and helper functions with a clearly defined input and output
- Stubbing out new components
- Writing out comments and having the LLM come up with functions
- Learning a new code base by highlighting confusing logic and asking what the code does
  - (this one works really well for me because Clause will show example inputs and outputs)

But, from the above points, you'll see that the LLM mainly works well within a single file.

I probably wouldn't live in San Jose since it sounds like you are prioritizing social life. I would check out your company's shuttle route because they probably have stops in SF which bridge the gap between social life and work.

I would probably not worry about 4 because you'll probably only go to conferences a few times a year.

I would include both:

1. The real world experience shows that you can work on a team on a (maybe?) mature code base
2. The project shows that you can take a project and run with it to get users so you are product-oriented, and you can think about projects beyond just the technical part

I would try to go through the worst case scenario and decide whether you'd be okay if that ends up getting realized.

The financial expected value is probably higher by going to Big Tech, but it's possible to have more upside in a startup. You have to also factor in that at a public big tech company, the stock will most likely be appreciating by 20%+ each year, and it's very liquid. Whereas, at a startup, if it does end up succeeding, you might not be able to access that money for 10+ years. (but, the paper money can definitely grow way beyond 20%= each year).

> aspirations to be a founder.

If you have founder aspirations, you are probably very risk-on, and you probably care less about career trajectory, so you probably know deep down what choice you want to make.

> When I do get interview calls, I become desperate, fearing I won’t get another chance for months. This anxiety leads to poor performance, making me feel like I’ve lost my only way out.

I would try to focus on being more interview prep oriented. Your prep is within your control. When you are going through the interview, there is a lot that's out of your control, like the questions you get asked, how you are feeling that day, etc. After the interview is over, you can reflect and use the feedback to update where you spend your practice resources.

> I remember in my past internships in these "tricky" implementation parts

There are a few ways to handle the tricky implementation:

1. Try to find out how necessary it is in the overall product. Is it something that only affects a small percentage of users. Is it even necessary to implement?
2. Try to brainstorm ideas, usually with a PM, to see if you can think of out of the box, novel solutions to get a similar result with less work
3. Split up the task into smaller tasks so you can fast follow in the next sprint
4. Sometimes, you just have to deal with the problem. Make sure you can articulate why the edge case is a pain to handle and flag it to your team, so they know, and maybe they can offer some insight

I will say that, given enough users using your product, if you try to merge in a change knowing about an edge case, someone else is probably going to discover it, too. So, it's better to flag it or deal with it now rather than in a production outage where there is more visibility and pressure on the line.

For work threads and messages, you can be more succinct. It's actually probably better to be succinct otherwise people will glaze over your messages when there's a wall of text.

The places where it's more appropriate to take some more time are documentation or email, or anything that is more of a source of truth that has a large audience looking at it, so lack of clarity can cause confusion or slow people down.

That's a difficult situation. I would say that it's unfair of your manager to solicit feedback from the team that late into your internship because it doesn't leave you enough time to address the feedback. Usually, your manager should have had regular checkpoints with your mentor to collect feedback.

Do you know if there was a rubric with expectations at your last internship? Sometimes you do have to take things into your own hands and cross check everything with your manager to make sure you're exceeding expectations. The issue is that people can be busy, and they might not have your best interest always at the top of your mind.

> This means I have to make everyone on the team happy, not just my manager. How do I get honest feedback from everyone on the team?

It's hard to accurately comment on what happened during your last internship. If you were trying your best with the code and taking lessons from each code review, it's unfortunate that things worked out the way they did. It can be hard for someone to offer feedback when prompted, but I would just make sure to have regular syncs with the people that you are working with and just be very proactive with them about what you are trying to do and why you are doing it. Then, they'll be able to give more direct feedback about your thought process.

I would actually have imagined that contribution would have been increased because you'd be able to consider new perspectives from the LLM output that maybe you didn't think about before.

One thing I've been exploring is asking the LLM to come up with a more descriptive prompt for me by giving it a set of goals that I want the prompt to accomplish. You can try that to see if it helps with the output.

What model are you using?

I wouldn't try to detach yourself from using AI tools because of a bad experience. You'll lose a lot of the efficiency gain if you don't learn how to use them now.

I am in favor of using AI code generators. I actually think you can learn faster by using AI code generators if you actually take the effort to critically think about the code output and your prompt takes a first stab at the problem.

In a given unit of time, say an hour, I believe you can learn 10x faster using an AI code generator versus not using one. There's just a lot of minutiae of looking up documentation for different libraries, seeing what the input/output is, gluing libraries together that doesn't help with your higher level understanding of the code. Or, you have to interpret cryptic error messages that block you.

> I then thought of multiple ways the user could mess up when using the program.

Another approach is to come from the perspective of a malicious user who is trying to cause as much chaos as possible to the system. A malicious user might try to use bad input, send many requests in parallel, or try to find a way to extort the system to send payments to themselves.

It sounds like the main problem is interview coding, which, like Ammar says, is a different skill because it's more about general algorithmic problem solving rather than solving a domain specific problem. Plus, you have to deal with how to handle the anxiety of someone watching you code with there being high stakes at play.

Do you remember what you felt when you were going through the interview? It's possible that your mind just immediately raced to the conclusion that you can't solve the problem as soon as you heard the question, so you mentally tapped out early. Can you try to reframe the interview as a collaboration between you and the interviewer to solve a problem together. Think more about finding the truth to the riddle rather than being judged by the interview.

I would actually try to do the opposite of you did, where you want to embrace that you're currently freezing, so you actually want to do more interviews until you can rid yourself of the anxiety.

> Always feeling I am not up to the mark.

I recommend reading the book called [Mindset by Carol Dweck](https://www.amazon.com/Mindset-Psychology-Carol-S-Dweck/dp/0345472322). It'll help you develop a growth mindset where you are more empowered that you can improve on your current situation by putting in more work.

Sorry you have to deal with all of these issues. It's never fun to have to go to work when you have to deal with these kinds of personalities.

It's hard to tell exactly what the behaviors that they say you are doing from the post. What kinds of things are they saying to you, and what do you know to be the truth?

> what makes us as a difficult target for such people?

> I've experienced area leads taking my credit

If you can document and leave a paper trail of all of your work, then it will make it very difficult for other people to take undue credit. If they try to take advantage by saying they did something, you have a paper trail to show otherwise. This paper trail can come in the form of status updates through email/chat or through commits in your code repo. Try to get ahead of anyone taking credit from you by being more proactive in showing off the work you've done.

Your manager probably has certain expectations of you fulfilling SWE duties since you recently joined, so I would focus on doing an amazing job there to build trust and prove your worth.

Being a really good SWE will also help you to become a really good PM because it gives you a better understanding of how a tech company operates from a SWE point of view.

As far as timeline, it can take a few months for a new grad to really onboard and feel comfortable in their new role. You really want to show that you can lead a project, not just on the technical side, but you want to be involved in the needs finding phase, design, and project management side as well. This will also help you build trust outside of the team, which will make the conversations easier because your manager is probably going to have side conversations with the people you worked with to see if there is a possibility of you switching roles.

You should basically already be doing PM roles before you ask because it takes time to train someone in a new role, so you want to show that you are already at a certain level or have potential to be at that level given you're able to dedicate more full time hours in that role.

I would look at your company's expectations for each level and try to work backwards from the next level. You want to try to figure out what the delta is between your current level and the next level and work on a project that can fill that delta.

> I incorrectly think that asking many questions about "small details" makes me look like an inexperienced/ unreliable engineer.

> When someone asks me "Am I making sense? Is this clear to you?" - I ALWAYS say yes too early, without thinking about edge cases/ unmentioned ambiguous details.

I would try to caution you to move away from a mindset of thinking more about how you perceived by the other party and more into a mindset of truth discovery. This won't make you less easy-going, but it will signal to the other party that you are curious and inquisitive.

I would try to think about:

1. How can I execute this project as smoothly as possible?
2. Is this a detail that can have an impact on the outcome? If it is, I need to get ahead of it to make sure it doesn't affect the launch timeline.

> (I usually do not ask clarifications on what I believe are "small details", and leave it to myself to figure out the "small details").

It's okay to say your thought process out loud and express an opinion given that you list reasons out for how you came up with that opinion. In this case, I would say out loud how you are thinking about the small details and how you can are expecting to implement it in your code and why you decided on doing it this way. Even by thinking out loud, you'll clarify a lot of your own reasoning in your mind.

One tip tip is to create a design doc ahead of time and ask the subject matter expert for comments. They should be able to flag anything that seems too vague, ambiguous, or lacks understanding.

> have recently done some live technical coding interviews at other non-target companies, but want to schedule a few more live mock technical interviews in the next few weeks before the initial technical screen interviews at target companies.

Were you able to gather any data points about how you could improve your interviewing skills when you interviewed at the non-target companies? I would recommend journaling out where your weaknesses and work on those. Otherwise, it might not be worthwhile to do more prep just to get reps because you could be getting diminishing returns.

You can also ask your engineer friends to help with the interview prep in exchange for dinner. 

Agree with everyone else. If you sign one of your offers at an early stage company, you'll be able to build more work experience and prepare for technical interviews at FAANG while you are working. It's not worth it to hold out for a higher paying offer because it might not be there.

We are actually introducing a new product called "Interview Insights" this month that will address this issue. You'll be able to find out more about the interview process at a specific company, mainly focused around interview questions that were actually asked by interviewers. You'll be able to search for a combo of company/level/team/location to find exact interview info for the role you are interviewing for.

> The app has gained a good amount of traction (12k+ visits) and I've learned a LOT that I want to share with others building side projects

Would love to share insights about how we built out our job board, too!

> I am doing decent job but at times I really am impacted with code review process. I sometimes have fear that I'll lose job if code quality is not up to the mark
>
> Any suggestions on how to overcome the feeling of guilt, fear and at the same time improve the code quality?
>
> I sometimes freeze when having such conversations thinking what would the person in front of me think about me if I reasoning is not correct.

Like Rahul said, I would try to reframe your current mindset into one where your actions are based on the higher level goal of doing good work quickly to push the company forward rather than one that's reactive that is more based on people's perception.

With the more proactive mindset, your actions are taken as a result of moving quickly, so there is bound to be feedback from others about how to improve. Remember to cut yourself some slack because you just started in your position. No one expects you to be perfect from the very beginning.

Remember that you had some hypothesis as to why you did something. Have conviction in your reasoning and explain it to the person who might judge you. If you thought about the problem's solution logically, how do you know that the person questioning you isn't the one that's wrong?

> I feel like I do not understand anything as I am overwhelmed with how the codebase works. Also how do I understand it in a way easy to relate to and remember what the components inside the codebase does and also learn the languages?

When I hear someone is overwhelmed, the picture I get is that they feel like there's just so many things they don't know, and they don't know where to start.

If this is how you are feeling, you want to just try as many things as possible because the outcomes will set you on the right direction. Imagine just going through as many feedback loops where you come up with a hypothesis and test your hypothesis. When you get an outcome that you didn't expect, you'll learn something about the code/framework and you'll be able to orient yourself in the right direction.

I came up in an age where there weren't LLMs that could help you with code. But, I imagine, you can use ChatGPT to shorten your feedback loops even more by feeding your hypothesis into ChatGPT and letting the conversation guide you int the right direction.

> Is it always recommended to switch companies in a couple of years?

Here are some reasons that people will switch companies:

1. Higher TC when switching companies
2. Lack of work/life balance
3. Lack of career growth

If you are pretty satisfied with the above, you probably don't need to think about it too much. You can test the strength of your resume by sending it out every year to see how receptive companies are to your resume.

I wouldn't try to over-optimize your decision, though. I've seen people who left a company after 7-8 months and people who were at a company for almost a decade have no trouble finding another job (although, this was before 2021, so it might be different now).

> My main weakness is that I don’t like reading documentation, lengthy tickets, or going through hundreds of Jira comments to find answers that have already been provided.

For very specific questions or technical details, I would try to build up a habit of spending 10 minutes to look for any related documentation (chat logs, wikis, tickets like you mentioned) that can either help answer your question or guide you in the right direction. (I'm guessing that you are asking about more lower level details if you are looking at those resources.)

It's really important that you do this because the paper trail was created intentionally to save people's time in the future. If you have done your due diligence and read all of the docs, when you ask people questions, you can lead by telling them you looked at X, Y, and Z docs but couldn't find them there. If someone answers your question, update the doc and let them know that you updated the docs because it'll give them a sense of relief that you are doing your part to help other new people that might have the same question. I am very appreciative when people lead a discussion by listing out the resources they looked at and explaining their thought process because it shows that they have thought very deeply about the issue.

It can be time-consuming to give 1:1 direction to a single person if it's taking time away from them working on something more impactful. There are opportunity costs for how each engineer spends their time, and they are more incentivized to use their time on work that will reflect well for them on their next performance review. These engineers are more experienced in their careers, so they could have families that they are responsible for, which makes them prioritize their time even more ruthlessly.

**But, there is a balance here, because you obviously don't want to spend the whole day looking for something that doesn't exist, so the key is to timebox your search.**

One useful exercise is to think ahead to how you want to present yourself in the next performance review. If you can work backwards, this will better align what actions and support you need to provide to show that you are operating at the next level. I would look at the criteria for a senior engineer and see if you can check off as many bullet points as possible for this mentorship opportunity. Make sure that your teammate's project isn't just set up to succeed but also provides business impact, business impact that wouldn't have been possible if not for you laying the foundation.

> The founder mentioned financial implications on EMs whose systems see outages. Thus, people started hiding outages. Managers asked folks to move alerts from P1 to P2/P3 so that they dont get flagged to the CTO and there are no financial implications. Postmortems happen but are limited only to issues which impact user journey and see social media escalations, thus are not hidden.

I would definitely flag something like this up the management chain. Of course, don't call out anyone, but it's a failure on the system because it incentivizes hiding outages and downplaying the impact that outages have. I wouldn't blame it on the individual managers because it's just the system that they are forced to play in.

I would look into adopting and evangelizing a [blameless post mortem culture](https://sre.google/sre-book/postmortem-culture/). If people are scared of causing incidents, velocity will slow down and engineers will try to hide any incidents, as you've seen. Incidents should be seen as an opportunity to build up resilience in your engineering systems and processes.

> Most of the DB upgrade activities / deployments happen late night. Thus, while the day starts at 10-11 AM. It continues till 3 to 4 AM in late night. This has caused my health to deteriorate severely. When mentioning that this is causing my health to deteriorate, he mentioned that this is baseline expectation from leads / staff engineers. I am still trying to come up with ways to get these deployments done in day as well like adding redundancy. I have started having occassional fever / headaches due to this.

I would definitely flag this to your manager and write up a preliminary doc about addressing this. If you are feeling this pain, there's probably a lot of other engineers that are feeling it, too. You'll be celebrated among your peers if you can solve this problem. Is there a reason that everyone has to stay up in the night? In the short term, is there an oncall schedule people can rotate monitoring the database activities go smoothly. In the long term, I agree with you about adding redundancy to ensure a database failure doesn't ever get surfaced to the user. It's good practice in general especially at the scale that the company is operating at now.

> I'm getting the feeling that we, as software engineers, are evaluated more on experimentation and user impact rather than amount of code written.

This rings true to me when I was working on a growth team (not at Meta). At the end of the day, you need to show impact, and impact isn't necessarily aligned with the quantity of code written. But, the more code that you write, the more experiments you can run, so there is a slight correlation.

> Does anyone have any advice on how to succeed in a role like this and what are some key qualities to work on to work my way from E4 to E5?

The experiments are usually either broader in scope or have a tremendous amount of impact. You can take your work to the next level by planning and leading multiple growth projects and delegating out the work to others to show leadership qualities.

I read a book called *Die With Zero*, which talks about spending time and resources to maximize experiences based on specific life stages. For example, certain opportunities, like going on adventures, are best pursued between ages 20–40 rather than when you are older and your body is less able to handle those adventures.

How does this relate to your decision? The scholarship seems like a once-in-a-lifetime opportunity tied to your current life stage. If it’s as prestigious as you say, I’d lean toward taking it because it's not a decision that you can make later in your life. Whereas, there will always be a company that you can work for.

Even in the worst-case scenario where the scholarship doesn’t directly lead to immediate success, the time commitment (likely 1–3 years?) is short enough that it won’t significantly hinder your career. You’d still have plenty of time to build career momentum afterward.

On the other hand, AI companies, while exciting, are harder to predict long-term. Many innovative products( like ChatGPT or GitHub Copilot) quickly became commodities as competitors reached parity. Similarly, the unicorn companies you mentioned might not retain their status in 5–10 years. However, I’m confident that after completing the scholarship, you’ll have access to other promising opportunities, including future unicorns, likely even bigger than those available today.

I hadn't heard of the Spotify Model before, so I'd love to get other people with more experience to chime in.

At larger companies, there are usually product, backend, infra, and platform teams. It seems that in the Spotify model, you have squads that could have elements of all of those teams.

I can see how it can be useful for moving quickly since you work in a "squad" and have the end to end autonomy to tackle problems at every layer in the stack, so you shouldn't ever be blocked by another team.

Conceptually, it makes sense, but I do see a few ways where it might break down.

1. Usually, the backend, infra, and platform teams are very opinionated. I could see a lot of conflicts between different squads where you either a hit a roadblock because no one can decide on a best practice or there aren't any roadblocks but there are just multiple opinions and ways of doing things causing the codebase to be very random.
2. A specialized platform team can think about the overall efficiency of all engineers that use their tools. The Spotify model sounds like it lacks this, so there isn't an incentive to keep improving tooling if it comes at the cost of pushing a project forward.

At a high level, there are a few ways for making a larger initiative go smoothly: 1. make sure all of your stakeholders are aligned before starting any work, 2. make sure there's a guiding principle or north star that all of your decisions are based on

1. **Getting alignment**

You'll want to "grease the wheels" by planting the seeds in your stakeholders' mind that coding standards at the company can be improved, and this can lead to increased developer productivity. At a practical level, this means just spending your time asking open ended questions to other developers about what they think about the code quality at the company. It can start very informally where you bring it up between meetings, at lunch, in the microkitchens, etc. This is a phase for collecting ideas but also just letting people know that there's going to be a initiative to improve code quality so they aren't taking by surprise.

I wouldn't even write a single doc yet until you've done the above. This is more of a user research step. This step is also useful for getting people excited about the upcoming work.

If you do notice there are patterns or trends around the feedback you are getting from users, I would start to write out docs for improving the initiative and open the doc for comments to the people that you spoke to. Include the feedback from the people that you talked to in the doc.

This should address the "war and peace" issue and really tease out what other people perceive low code quality to be.

1. **Having a guiding principle**

After you collect feedback from different stakeholders, you need to come up with a reason for why it's important to address all of this feedback.

- Is the initiative actually worth pursuing?
- What should the outcome be once the problem is solved?
- Can you quantify what the outcome looks like if the project is executed well?

An example of a guiding principle and action steps might be one of the following:

- Reduce the turnaround time it takes before a PR gets merged in
  - (example action: reduce the build time so users get quicker feedback about whether their PR is valid)
  - (example action: add a linter to reduce the number of repeated style conversations)
- Reduce the number of incidents that are caused in production from poor quality code
  - (example action: add a testing environment)
  - (example action: add more monitoring and observability tooling and set up alerts)

All of the actions in your plan should level up to the guiding principle that you think is the most important based on the feedback that you received from talking to other people.

I would focus on #3 and #4. it's just a nice practice to let people know that you are leaving so they don't get caught off guard. Another benefit is that they might be thinking about the same thing, so you might have the opportunity to work with them in the future.

As part of your offboarding process, I would sync with your manager to make sure all of your previous work has a new point of contact that can drive the project forward. Also, make sure you also sync up with all of the points of contact so they aren't lost after you've left the company. When you meet with them, I would walk through a wiki or add notes to a new wiki while you are giving them the rundown of your work.

Basically, brainstorm ways to make your transition as seamless as possible.

There's an old school book (written in 1936) called ["How To Win Friends And Influence People"](https://www.amazon.com/How-Win-Friends-Influence-People/dp/0671027034). Even though it's an older book, humans haven't evolved that much in the last 100 years so it's still very relevant. The gist is to be genuinely interested in people's lives which leads to you asking them a lot of questions about their live and understanding their motivations. Be open minded to different interests that other people have.

I would also add, just be genuinely helpful to people with no strings attached.

> However, I don't see the bull case for the company. Stock has not recovered from the post-COVID drop (down \~80% from peak), and it's increasingly unclear how we would rebound.

It might be worth the effort to spend 1-2 hours one day to think about whether there are temporary headwinds causing the drop or whether there's an existential crisis happening. Some questions to ask yourself:

- Is there some new technology (like AI) that would disrupt the business?
- Is there a competitor that's been seeing enormous growth that would take away from your company's market share?
- Or, is there a temporary issue in the market that's affecting the company, but it's something that can be solved or will not be a problem in a few years

I would take a measured approach to evaluate the above and try not to be too reactionary.

If you do feel like there's an existential crisis, you can treat your equity as cash and cash out at every opportunity to invest in companies with more optimistic outlooks. This way, you get the best of both worlds, you can continue to enjoy your role in your current company, but you can also benefit from the growth of other companies.

If it's a temporary headwind and you have faith that the company will rebound, it might be worth it to hold on to your equity. I've seen companies that were in ruts go 3x, 4x, 5x, but it's usually because they were not priced fairly.

I'm using ChatGPT and [Cursor](https://www.cursor.com/) right now. Overall, they work decently for generating code patterns that are common.

I have noticed that Cursor doesn't work as well if you are trying to generate code for certain libraries (Firebase in my case) or laying out UI through CSS Tailwind classes. It's not perfect, but when it gets it right, it can shave off minutes when it generates code that can handle different edge cases that you might have missed. This can really add up throughout the course of a day.

I'll use ChatGPT to bounce off higher level ideas about system design to see if I'm missing any details. It's been pretty solid in verifying my thought process and even suggesting things that I might not have thought of.

I would definitely use the language that you are most comfortable in. You want to avoid the situation where you have trouble with a technical question because you forgot syntax or forget what's available in the standard library.

For you, I would use Typescript, and I would make sure to use Typescript when you are solving Leetcode questions. You want to get to a place where you never have to look up anything specific to the language because that can eat up time. If you run out of time or can't solve a problem, it should be because of some conceptual misunderstanding, never a programming language issue. If you are running into language issues, make sure to note them down so you can avoid making repeated language issues.

Even though interviewers should look at the overall solution that you present, if you have a lot of syntax errors or you're too handwavey with your syntax, it will subconsciously, negatively affect the interviewer's judgement on your performance.

I agree with @amazonsde about trying to limit the context switching. If you are juggling two work streams in your head at the same time, can you really focus on one of them? In the past, I've tried to parallelize two different work streams because one had a long build time, and probably 50% of the time, I would be too focused on the other work stream and forget to check when the build was finished. And, if I did try to keep both in my head, it would prevent me from getting fully focused.

If you have split up the tasks for each work stream into tasks that take 1-3 hours each, you can finish a task first before switching to another work stream.

Are there any leadership opportunities available for the greenfield project that you are working on? It sounds like it's all hands on deck to ship the new project. If the project can be split into smaller units, then you can effectively commandeer one of the units to get experience leading a project.

I agree with Rahul about doing a retrospective to brainstorm what happened and how much of what happened was actually in your control. There have to be some lessons or takeaways that can help you in the future.

On the bright side, your tenure at Spotify and Netflix is reasonable. I've seen a lot of engineers bounce after 1.5-2 years at multiple companies, and it doesn't seem like it's affected them, at least from the outside.

> I sometimes worry the years I spent at these companies are worthless, maybe I could have learned more if I had not been laid off.

> I certainly understand I cannot undo my lay-offs,

> Feeling sometime hopeless and sort of scared

I can assure you that you are in a good place for finding future opportunities! You should be able to get interviews at a lot of different top tier tech companies because of your experience.

> When I look at the types of feedback I get on my own code, it's a mixed bag - some people leave comments on how we should handle exceptions, other ask about why we use certain libraries instead of others. There's a whole range of comment types that focus on a variety of different things from different people.

I would say that those are fair questions.

The one about library choice and have long lasting impacts as the library gets more and more ingrained in the code base. For example, choosing a graphing library or a table library could have huge implications in the future esp. if you discover incompatibility/performance issues a few months later and have to migrate all of the existing functionality over to another library.

For exception handling, you do want a consistent way of handling errors, but there should be a standard way of doing this in your codebase. If there's confusion over this, it might be worth it to take time to find out why there's contention about it because as the team grows, other people will handle it in different ways/there will be contention over the best way to handle it.

> What would you recommend I read, watch or learn to do this better so I can help my team? How do you generally look at code? Are there areas or parts of it you focus on?

 I would take a different approach for code reviews for feature work and bug fixes.

For feature work, there's usually a product spec/technical spec associated with it, so I try to make sure the feature work aligns to the broader spec.

For bug fixes, I would try to figure out how the bug was introduced in the first place and whether the fix actually fixes the bug, doesn't cause any unintended side effects, and doesn't violate any existing patterns in the codebase. Sometimes there can be a quick fix for a bug, but it's not the right fix. For the quick fixes, make sure there's an issue filed for following it up with the proper fix.

Of course, in both cases, you want to make sure the code doesn't have any bugs, so you do have to make sure to go line by line and make sure there isn't anything that the author might have overlooked.

If you're seeing a lot of "style" issues with code, I would make sure to invest in a good linter to automate the process so it can automatically call out any style violations.

I read the following books \~10 years ago, and the lessons still stick with me to this day:

- [**Mindset** by Carol Dweck](https://www.audible.com/pd/Mindset-Audiobook/0593150422)
  - How your mindset can affect how you respond to new challenges, adversity, and failure
- [**Peak** by Anders Ericsson](https://www.audible.com/pd/Peak-Audiobook/B01F4A9EFW)
  - How to get better at a skill or activity by always being on the edge of your competency; you can't improve if your practice is too easy or if it's too hard
- [**Deep Work** by Cal Newport](https://www.audible.com/pd/Deep-Work-Audiobook/B0189PX1RQ)
  - How to develop a work environment with focused blocks of work to be more effective at producing results
  - Admittedly, the concepts in this book get harder to implement the more senior you get in a company because you end up getting involved in more and more meetings where it's just not feasible to carve out focus blocks anymore
  - I would love if another book came out that had strategies for maximizing your time given smaller focus time blocks

A common misconception about being a 10x coder is that it means you have to produce 10x the amount of code as your average software engineer. In reality, it's more about having 10 times the impact as your average software engineer. In this way, I think it actually helps you to be a conceptual thinker because you to see the bigger picture, identify the right problems to tackle, and come up with effective solutions. At higher levels of being an IC, you'll actually be doing less coding and more strategic thinking.

Both coding skills and organizing/planning/execution skills can be developed, so the real question is: what do you enjoy doing more?

If you favor organizing, planning, and helping others succeed, it might be worthwhile to invest more in the manager path. On the other hand, if you enjoy tackling technical challenges and refining your craft, staying on the IC path might be more fulfilling.

It does sound like you're heavily considering the manager path from your post. I think the stakes are low enough for you to take a stab at it. it's a two-day door, and I've seen a lot of managers go back to being an IC if they didn't enjoy it.

Congrats on your internship offers!!!

Now, you can shift your focus from system design and algorithms into building more real-world applications.

I recommend building full-stack applications (frontend &lt;-&gt; API) so you can get exposed to a lot of different technologies. Since you won’t know the specific tech stack you’ll be working with until your internships begin, there’s no need to specialize in a particular language or framework right now. Instead, focus on developing applications at a high level. You'll encounter a lot of the same higher level principles during your internship.

Also, during your internship, your main goal is to ship code with a high velocity. While you are building out your projects, I would try to journal/note down each time you hit a road block and try to figure out if it's with a particular engineering principle or concept, so you'll know how to handle it in the future.

Here are some suggestions to ensure you're learning effectively while using AI for code generation:

1. **Understand the code before using it:** Avoid copying and pasting generated code without fully understanding how it works and why it's being used.
2. **Critically evaluate the approach:** Always assess the code critically to determine if it's the best solution for your specific context.
3. **Clarify doubts through dialogue:** If you sense something might be off, ask: 'You suggested doing X, but I was considering Y. How do these approaches compare?' This can help deepen your understanding and refine your decision-making process.

I recommend collecting screenshots of your MVP from the Wayback Machine and showcasing them on a portfolio website or in a slide deck. By creating a portfolio or slides, you can control the narrative and highlight your contributions rather than leaving it up to the clients to interpret. In your portfolio or slides, focus on emphasizing the technical challenges you tackled and the solutions you implemented while building the MVP. This approach not only demonstrates your skills but also tells a compelling story of your work.

> How do you also not feel guilty rejecting the offer when you know you are not as serious about the position as the hiring end?

I would keep an open mind and think of it as an exploratory phase to find out what the engineering culture is like at different companies and whether they are working on something that might surprise you.

> However this was an eye opening experience to be part of such a poor performing team. I worked very hard to put everything together, but felt that folks around me kept dropping the ball; objectives misalignment, poor communication, no sense of urgency etc.

I would try to put together a retrospective doc for yourself for generating ideas of how to get ahead of a lot of the issues that you were facing.

- Did I have a timeline in place to map out critical milestones?
- Was the timeline reasonable, and did it account for PTO, holidays, buffer for other tasks?
- At each critical milestone, how did I ensure that the deliverables met the standards that were initially set out?
- Was there enough direction in the docs/tasks for the team to follow through smoothly?
- For communication issues, were there project syncs in place to ensure that people could voice any troubles or delays that might happen?
- Did the team feel like they had the ownership to feel like they were really contributing?

> but it's basically autocomplete on steroids

I recently switched from VSCode to Cursor within the last month. The autocomplete is my primary use case for Cursor, too. It's a huge time saver where I can save my mental resources for bigger problems.

In my personal projects, I use the chat (Cmd + L) to generate requests to external APIs. Like "Can you make a request to \[insert API here\] to fetch the current stock price of a ticker". It saves me the time of having to switch to my browser, look up the API, find the right endpoint, read the docs, and switch out all of the parameters. This one is also a big time saver because I know the result I want from a high level, but the minute details of looking up the API endpoint details can be frustrating especially since most API docs aren't the highest quality.

Sorry to hear that you had to deal with that. I would try to talk to your manager to take some time for yourself after the project ships, so you don't end up burning out.

The scenarios are very common because it's easy to underestimate the time it takes to get tasks done. When you are planning out a project timeline, it's easy to be optimistic about the time it will take to complete tasks. Also, it's easy to not factor in how your time will be spent doing things unrelated to the project, like fixing bugs from another project, attending meetings, onboarding or helping other people.

When you underestimate the amount of work to complete a project, it's common to cut scope and deprioritize certain parts of the project to get the main parts of the project shipped. Then, you can have a follow up plan to add those features later.

Just to preface, we build the Taro webapp using Next.js, but we don't use server actions. Not that it was intentional, it just ended up working out that way. It was experimental with the Next.js version that we were using. I haven't personally used server actions before, so it might be useful to get some input from someone else that has used them before, too.

> What would be the best course of action here, I found a library that can be used to run server action in parallel While I was reading somewhere that one should not use server actions for GET requests and only for mutations

Once again, I've only read about server actions. It sounds like they should only be used for mutating data. I am really hesitant about using libraries in a way that they weren't meant to be used.

If I was building a new webapp, I would probably still use a REST API (at least for an enterprise app) because it's tried and true:

- There's a whole standard for how to design REST endpoint urls.
- Most logging, monitoring, and observability services are built for REST APIs.
- Having a separate backend API enforces the concept of having separation of concerns.
- It's easier to open up your API to other consumers in the future (mobile app or third party developers)

> one should follow one pattern in a codebase so that it stays consistent. Would appreciate the help or any kind of advice here.

You can try to use the library to allow data fetching to keep everything consistent but just know that there are tradeoffs. It just seems very "code-smelly" to be using a hack to get server actions to work in a way that it wasn't meant to work. You might be able to get it to work now, but it's always hard to tell whether this will cascade into more hacks in the future. And, it makes it harder to migrate off of in the future.

I think if your app is going to remain lightweight for the future, you can go with the server action path. At least you'll know if you go down this path, it will be easier to migrate later if you need to. But, if you're expecting to build a platform for many clients in the future, it might be worth it to go the REST API route now.

Masterclasses

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.

[Taro Top 10] Succeeding As A Software Engineer Intern

Test

Another Comms Playlist

Comms Playlist

Another playlist

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