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.

> The pipeline was always failing because of another step that was removed recently. I think they got used to ignore the pipeline because of that.

I've seen this happen in the past: there is a testing infrastructure problem that causes the testing pipeline to produce flaky failures, and everyone is told to just ignore the problem to get their PRs in. The issue is that habits get formed during time, and it can be really hard to break the habits. As an engineer, you are mainly focused on merging your PR in, so you probably don't care about the testing infra issue.

The issue is, what's the point of having a testing pipeline if half of the people are ignoring it? I'm actually surprised that there hasn't been an issue yet from ignoring the testing pipeline. (If there have been bugs deployed to production, you can use that as evidence that there needs to be a mindset shift to treat the testing pipeline errors seriously).

The more people merge in their lint and test errors, the harder it will be to get the testing pipeline into a passing state again. So, you'll end up compounding more and more errors.

Ideally, you need to get everyone treating the testing pipeline seriously again. If your manager isn't going to help out, you can lead the initiative to fix the testing pipeline.

1. Make sure the initial issue where the removed step caused the failure has been fixed.
2. Make sure the all of the checks pass again.
3. Send out an announcement to all of the teams that the testing pipeline is working again and that everyone's PRs need to pass the testing pipeline to be merged in.
4. Don't allow people to merge in their PRs if they aren't passing the test (or have them pass through a special flag to do this, and make sure you get notified when this happens)

> Nine months into my job, I’m not a fan of my mentor. While competent, he’s rude, especially in technical discussions. When he disagrees with something, he aggressively asks "why would you do it that way?" instead of giving constructive feedback. This often turns discussions into confrontations rather than collaborative problem-solving. He’s helpful with business context, but he speeds through unfamiliar topics and reacts with scorn if I ask for clarification. He’s also prescriptive with how tasks should be done, even when I ask general questions, which adds to the complexity.

Ugh, sorry that you have to deal with this. I've been there, and it's not pleasant. Just make sure you don't let this affect other parts of your life otherwise, it's going to be a road to burning out.

The important part is that you are able to explain your thought process around your decisions very clearly where it's really hard for them to argue against you. This might take some time to develop since you won't be as experienced as your mentor. If you can explain your decisions from beginning to end, they won't have any snarky responses for you. Any time you are in a situation where you have to make a decision, I would go over all of the decisions you could make, all of their tradeoffs, and why you decided to choose one decision over the other.

> Moreover, I don’t find him useful as a mentor. While he's better with business context and attention to detail, I don't find his communication skills or career progression worth emulating. He's pretty much just a shitty extra layer of management.

Hmm, how long are the mentorship relationships supposed to last? Is there a way you can end the mentor relationship?

> Switching teams, which I’ve been considering for unrelated reasons about not thinking the team's work is a good fit. I've talked to my manager about this possibility and he supports me doing so next year if I still find the team a bad fit. This will get me away from the mentor, but I’d lose an amazing manager, and could have bad teammates on the next team.

It sucks, but this is good practice for how to deal with toxic co-workers. And unfortunately, this probably isn't the last time you'll have to deal with this. This is a way to stop interacting with the mentor, but you also need to make sure you aren't running away from your problems. If the switch is to progress in your career, then it does make sense.

You can also derisk yourself for the team switch by talking to your manager and your future teammates.

> it returns a specific structured error response that can be useful for frontend devs and also help debug better.

Having a standardized structure for error responses makes a lot of sense, otherwise, the codebase can get messy in the future where there are conflicting ways of returning error responses.

> So in short this software is going to be re-iterated again and again for improvement after we launch its first MVP ( targeted 2 months at max ).

Since you're launching the initial MVP, I would make sure the error response is very lightweight because you might need to flesh it out more in the future based on what kind of errors you get.

> what i understood its worth it as it would help me and my juniors debug better while in production and local development as well.

I would make sure you have a good monitoring/logging/observability stack for aggregating all of the errors, too.

> What do you do when you find what you're working on completely fails, and the open source project creators/maintainers have very little support on Discord/Slack?

Sorry for all of the frustration that you are feeling right now! I've been there, too. I also work on frontend, so I've been through the limbo of having to evaluate many open source solutions. It might be worth it to find the library that offers as close of a solution as you can get, fork it, and modify the code to fit your own needs.

> How do we know when to take a break (as in stop coding) after trying to debug for hours and days on end?

At some point, it is easier to modify or dig into the project codebase than to try force the library to do what you want. It sounds like you might be reaching that point. I don't know if the solution is to take a break, but rather, it might be to zoom out and think about how you would solve the problem from scratch if you were an author of the open source project. It sounds like you are hitting a point of diminishing returns with the library. That's usually a signal that it's time to revaluate the approach you're taking.

> But how do we consume a 10h long course effectively?

I would recommend consuming one topic at a time and working through Leetcode related questions at the same time. With courses, you want to make sure that you goal on "solving 30 related questions with a 90% success rate" rather than "watch all course videos".

When you start a new course, there's also a strong motivational energy to go through the material at the beginning, so I would try to leverage that as much as possible. The more time that passes where you procrastinate on the material, the more friction there will be to continue in the future.

> In my experience, if you spend time reading up on a subject, it is lost time if you don't apply it immediately.

I agree with this. I've done this with courses and books where I finish the material, and I leave it alone for a week, and I totally forget everything that I consumed. The real learning magic happens is when you run into a roadblock trying to apply what you learned.

If you can also paraphrase the material into something you understand, like coming up with your own acronyms or analogies, you'll also find that the material is easier to retain.

I would also add in checkpoints to review the material in one week, one month, three months, six months because it's easier for the content to degrade in your mind over time.

In my experience with migrating internal tools or upgrading processes, there can be a resistance to change from engineers because they can be used to the old way of doing things.

I'm going to assume the new way is faster, better in some way. They might not know how the new tool or process works, and they need to see that it's actually easier/faster and that's it's worth putting the effort in to learn the new way. From their POV, they are trying to implement some solution, and the last thing they want is some roadblock.

If you can create a very **short** documentation page showing the differences in the old vs. new way along with a video, that should make it easier for engineers to adopt the new way of doing things.

If your company has a rubric of what success looks like at each level, you can point your mentee to that. Then, you can draw a line between their current behaviors and the behaviors at the level where they want to be and see whether they are falling behind or exceeding the expectations.

If they are junior, the goal for them is mainly to become more independent where they go from require a lot of hand holding to almost no hand holding.

> My goal is to grow to staff eventually. Because staff-level engineers are required to have a deep understanding of the business and create scope based on business goals, having a good understanding of the industry seems to be a good skill to have.

I do believe that having expertise in the industry is secondary and can be learned on the job. When a company is recruiting, they are primarily focused on the engineering capabilities of the person first with the assumption that they can probably learn about the domain later.

So, you still have the capability to explore different domains to find out which domain you really enjoy working in.

Most people will use quick heuristics to "score" you because they go through so many candidates each day. Unfortunately, we don't live in an ideal world where people will comb through and try to evaluate what kind of projects you've worked on, so you'll have to meet them where they are.

> I feel like i don't want to take risks with startups anymore since that might hinder my hire-ability in the job market after the stints. But i like the speed of growth at startups.

There is a wide spectrum of startups out there that are well known enough where they command as much respect, like OpenAI. You could look for unicorn startups that are still growing fast but haven't yet been affected by big company culture.

> By going with the big company, i am securing my domain, my brand and my stability as a good hire in the market. However, i might not grow too much as an engineer.

If all things are equal, and you don't have a big company name on your resume, I would probably go with the big company because of the external validation you'll get. It will open the door for you to join other companies in the future because it's a solid signal that you can meet a certain bar. A lot of recruiters will look at the companies you've worked for in the past to look for a strong brand name.

If I had to argue the other way, I have talked to some very early stage startup founders that have some trepidation around hiring people from the laidback company because of potential velocity concerns or getting stuck in a slower mindset of doing things. But, I do feel like this is a minority of cases.

You could just work at the big tech company for 1.5-2 years and dip if it's not working out for you.

Professional relationships can be fostered organically when you have regular XFN syncs. Deeper relationships get built in the time before or after your meetings or when you are making conversations with people in person in the hallways/kitchens.

> I have a few friends in the company (albeit not close) who say they really like the company

If you can, I would try to get a well-rounded discussion going with each of them by having a coffee chat or lunch with them. After 30 minutes-1 hour, all of the generic feedback starts to taper off, and the real discussion starts. You can start to tease out the strengths and weaknesses of a company by very specific questions to them.

I do agree with @Alex that you want to talk to people that have been at the company for 2+ years because it's easy to get a skewed POV from someone who's only been at the company for less than 6 months.

I would try to maximize that initial energy you have to talk to as many people as you can to find out what the bottlenecks are in the system. Look for low hanging fruit with high impact.

You'll probably end up talking to people that have been in the company for a while that could be jaded about why a certain thing cannot be done or improved. I would try to question their assumptions to find out exactly how much they are saying is true. It can be easy to defer to someone else as the expert because they've been at the company for a while, but many times, they could have tunnel vision on the problem.

> Like a lot of people in tech/software, I've always thought of myself as an intelligent guy. More than that, I've derived a lot of my identity and self-worth from that.

I would be very careful about making intelligence a part of your identity because it's something that can't be changed.

It can backfire if you end up falling flat on a task that requires high cognitive abilities . You can end up having an existential crisis about whether you are as smart as you thought you were.

It can also backfire because you won't pursue endeavors that seem like they are out of your cognitive reach because you don't want the illusion of your intelligence to be shattered.

Instead of having your identity grounded in your intelligence, I recommend grounding it in your work ethic because that is something that you can change.

> The plus-side seems to consist of confirming that I'm smart if I get a good score (yay!) and perhaps even finding out I'm a secret genius (and way underperforming my potential, lol).

I would say that the underperforming would be more of a result of work ethic rather than intelligence.

Some good questions to ask are: what are the negative long-term consequences if the code gets in, and how easy is the decision to reverse?

I do sympathize with both sides because there are situations where you need to write well structured and clean code, but there are also situations where you can be more lax in code quality. The more engineers that work on the code and the more users you have, usually, you'll need to show more discipline in your code quality. If there is no discipline, engineers will make up new patterns for solving the same problem, or you'll end up deploying a lot of buggy code.

If you are working on the first iteration of a new system, it does make a lot of sense to take the time to make sure that the code is readable, elegant, and modular because there will be other engineers that will mimic the pre-existing pattern. The code will usually start to degrade over time if the quality expectations aren't met.

There are probably some things that can be improved on both sides:

**For the reviewer:**

> the type that will ask every lesser ranking engineer for rewrites from every PR

I'm not sure how extreme of rewrites they are requesting, but if there is an existing pattern in the codebase for how something is done, it does make sense to keep that existing pattern throughout the entire codebase.

When an engineer first joins, it's not too uncommon for them to have to rewrite a lot of their PRs because they are unfamiliar with the patterns from the codebase. The request for rewrites usually starts to settle down after the author gains more experience with the codebase.

> takes a week to review small tickets

This isn't good because it blocks the product from moving forward. There should probably be an SLA on how quickly code needs to be reviewed. I've worked at a company where we'd track how many PRs would miss SLAs, and it was used to evaluate the performance of a team.

**For the code author:**

> the type that will ask every lesser ranking engineer for rewrites from every PR

I would try to write smaller PRs to get the reviewer to sign off on the code quality.

I would also set up a meeting with the engineer to let them know about your solution so they can sign off beforehand.

> I've been at my current company for about a year and a half, the team I was hired for hasn't worked together until the last two months. because of some organizational decisions all the engineers on that team have been lent to other teams during the period I'm describing. My team didn't have a manager until three months ago, and this manager hasn't been doing a good job either, he's onboarding feels slow and he's just started to get closer to the team.

Since you were already working with other teams, it doesn't seem like you've built enough reputation on your current team where it could help you during the next performance review cycle.

It also sounds like you are more confident in the other team's manager and you have a deeper relationship with them.

I would switch teams because it feels like an opportunity to work with people that are compatible with you.

You might need to grind for the next 6 months to catch up, but 6-12 months is plenty of time to make an impact on the new team. If you only had to wait 1-2 months before the next performance review cycle, then maybe, I would say to wait it out, but since the timeline is longer, I would probably switch teams.

> Since I am the lead Android engineer, the bugs/crashes are reported to me to fix. Solving these takes time because sometimes I am not the one who worked on it. This leads to my current tasks getting deprioritized.

I would say that It's good, even preferable, to reassign the bug to the person who worked on it because they'll probably have the most context on it, so they'll be able to fix it faster.

I would talk to your manager to find out what product your cloud team is going to be responsible for, and then I would ask for their recommendation for what content you can consume to get onboarded quicker.

If you end up buying books to learn more about the cloud offerings, but you might end up reading about a lot of unrelated products.

I would wait for your friend to get an offer first, and then let them refer you in. If your friend is able to get an offer, it will at least signal to the engineering team that their referral (you) meets a certain expectation. They'll use your friend as a proxy for interview performance.

> Alex/Rahul have already advised on talking 1:1 with team members + breaking stuff to see how things work. I would still love to see a live deep dive on few large codebases to learn how you would get familiar with the codebase asap.

My general advice is to try to fix a really small bug. You'll learn a lot about the build system, architecture, file structure, deployment that are unrelated to the actual code changes. In the process, you'll end up talking to different people that work on the codebase because you'll inevitably have a lot of questions that come up when you are fixing the bug.

> I have not been actively involved in this project and slowly my manager wants me to get involved.

Is it possible that they don't know that you are involved? It's also possible that they've been operating in single player mode for the last few days/weeks, so it's bypassed them that they should be inviting you to the meetings.

I would try to be direct and send them a message that you talked with your manager, and you're excited to work with them on implementing the project. Let them know that you are interested on getting up to speed with the project and are interested in joining the meetings going forward to learn more about the project.

> I have already told my lead to shadow me in some of the meetings so I am aware of the context. But he doesn't involve me.

Are these meetings different than the ones that the lead is leading?

> The reason I ask is these meetings help us to understand the architecture POV and get to know the system better.

You can also schedule a 1:1 meeting with your lead and talk about the delegation of the work so it's even clearer that you'll be helping out.

> How to do better as a tech lead and mentor multiple engineers at the same time to help them grow?

I would try to scale up what you were doing before with one eng to the whole team. There's great content on Taro about keeping a 1:1 doc to make sure that you and your mentees are held accountable for your action items. In every meeting, you should be thinking about the short-term deliverables and the long-term career goals for your mentee. The short-term deliverables are getting projects executed on time and getting them unblocked. The long-term planning is making sure they are working on projects at the next level. It can be easy to be short-sighted, and the next thing you know, 2 years have passed, and your mentee can still be operating at the same level because of poor project selection or decision making.

> I'm delivering projects with good velocity and quality, but from my past experience I found it pretty hard to apply same standard to others, how should I change my mindset to help team move fast and improve quality instead of just being a good IC myself?

You'll need to be okay with taking a hit in your project delivery time. What gets you to E5 isn't necessarily what gets you to E6. It's not just doing what you were doing before, but faster. You may even run the risk of burning out if you try to do this plus mentor multiple engineers.

You may need to take on more exploratory projects where you are doing more investigation rather than coding. The exploratory work lets you delegate and plant seeds for projects that your mentees can work on.

> I want to give new engineers (probably all E4s) chances to lead tech design. To what extent should I be helping with the designs? Should I delegate more and let them take full credit, or should I be handholding more?

I would make sure to set high expectations and assume that they can write good tech designs. Give them the ability to succeed by having a discussion about the project beforehand and give them examples of good pieces of tech specs. Then, let them take their best stab at it and make sure to leave comments for places where they didn't consider something or point out the edge cases that they missed.

> When I'm leading projects, how to make sure I get my part of credit while other mobile engineers also get their credits? Also related to this, how to better separate tasks on a project? I want to make sure they have chance to grow while I also get chance to grow.

When you are writing your performance reviews, giving status updates in standups, offering advice in public communication channels, you'll indirectly get credit if your manager is paying attention. Make sure to mention how you spent your time during your 1:1s with your manager. People will know.

For task separation, it might help to start at the very high level of what you want to accomplish, then start breaking the higher level goal into more and more granular chunks of deliverables until you get tasks that take 1-4 hours to complete.

Hmm, a standup in the morning (say 9am) and end of the day (say 4:30pm) is a little bit extreme because if you call your workday at 5pm, you basically only have 30 minutes of work that you can report on for the next day's morning standup.

It sounds like you'll always have something to say during the morning standup if you work early in the morning or later at night. I'm guessing that you are doing a lot of "unblocking" activity (meetings, writing, etc) between lunch and the end-of-day standup. It's okay to include a note about what you were working on during this time.

During your performance review cycle, your whole body of work during that period will be evaluated (or at least I hope!), not just whether you had something to say for your standups, so continue to focus on the long-term.

I'm sorry that you had a negative experience with that recruiter. I've also had some negative experiences with recruiters being very pushy and disrespectful, too:

- Calling every 15 minutes and leaving tons of voicemails
- Making exasperated sighs whenever I tried to extend the offer deadline
- Telling me I made a huge mistake when I told them I accepted another offer

This was at the beginning of my career, and I was less mature back then, so their actions would really affect my emotional state. After going through the process a few times, you do learn to dissociate your emotions from their behavior.

> She insisted i meet with my potential boss at the office and do so only if i am 100% sure of accepting the offer.

I probably wouldn't meet up with them unless I was trying to sell myself to them more, increase my total comp, or trying to extend the offer deadline further. Otherwise, it just commits you more into their company. Otherwise, psychologically, you feel like you have a deeper investment into that company since you've met with them in person.

> Its been a week since then and i think i should have played this a bit more smartly. I should have said yes and continued to interview. Am i right in thinking this way ? Is there any other way to approach this sort of a situation ?

Make sure to avoid long, drawn-out phone calls where you are playing into their game. They have the upper hand on you because they probably make these calls multiple times every day for many years, so they are able to get so many reps and practice, and they probably have a playbook to sell every kind of person.

Try not to take anything they say personally and if you feel the pressure, just tell them that you are busy and have to run, but you'll consider what they said. Try not to say too much and leave things open ended. The issue is that no matter what you say, they've heard it hundreds of times, so they'll always be able to have a rebuttal for you.

The most important thing you can do is to have another offer because it will completely change the dynamics of the conversation. If you have the first offer, try to delay the offer deadline as much as possible so it lines up with when you get another offer so you can play them against each other.

> I'm thinking of picking questions from the frequently asked Meta/LinkedIn problems list on leetcode and preparing for the Interviews solely based on this.

This is a solid approach. I would start with breadth to make sure you are covering all of your bases. In the past, I've used Grokking The Coding Interview because it categorizes different technical questions into patterns. It can be easier to solve coding questions if you can compartmentalize the type of question into one of the patterns.

I would recommend grinding hard during your 6 weeks, having goals in mind for how many questions you want to solve. Also, I would keep a journal to reflect on your solutions to see what you missed or what kind of question gives you trouble the most.

> It helps building intuition with DP, Graphs and Divide N Conquer problems. On paper I can solve those questions but may fumble with the implementation.

I would make sure that you run your code. With pseudocode, it's possible that you could have a misunderstanding of programming language syntax, and you don't want to discover that during the interview.

I would also make sure to time yourself when you are going through a question.

I'm not sure if Meta makes you code on the computer, but I would try to mimic your interviewing environment as much as possible. If you are coding on a computer for the technical interview, make sure you code on a online IDE. If you are coding on a whiteboard for the technical interview, make sure you can use dry erase markers to write out your solution on a whiteboard.

> can I realistically land a job, or am I living in an illusion that I can do anything without understanding the challenges of the real world?

It's hard to say because everyone's circumstances are different. But, I don't recommend ruminating too hard about the market, instead, run experiments so you can find out exactly what's within your control.

I'm not too familiar with OPT, but it sounds like you'll have the ability to work in the United States on a visa?

I'm going to assume that you don't have anything lined up if you are studying for DSA.

I would spend some time applying to different companies to see exactly how far you can get in the hiring pipeline. Because, if you're not able to get to the technical interview stage, then, it's hard to suggest to you to study for DSA. Instead, you might need to work more on polishing your resume and working on side projects. But, I would prioritize working at some company before falling back to that.

Hmm, I'm not sure you could say the tech market is at a low. I guess it depends on what tech companies you are looking at. But, if you look at the stock prices of the large cap companies like Nvidia, Apple, Netflix, Amazon and zoom out 5 years, you'll see that these companies are either at record highs or near record highs. Although, maybe it's different for small/mid cap tech companies? I haven't checked lately.

For a newbie, I'd recommend either investing in the S&P500 or a total market fund. The average annual return is around 10% a year.

If you are going to park your investments into the market for a long period of time, I wouldn't worry about the market being at a high right now because the market is going to continue to reach new highs.

One exercise that might be worth doing is:

- Figure out how much equity % you will own by calculating your (num shares / shares outstanding).
- Find out the current valuation of the company
- Subtract out much money the company has raised from their current valuation
  - (investors will get paid out first)
- Create a line graph of your (equity % \* company valuation) at different company valuations
- Repeat this process with the other equity value they are offering you
- Overlay the two line graphs on each other.
- Find out what the company valuation would have to be in order to exceed the extra salary that you are getting
- What is the probability that the company valuation would meet that number?

If you don't want to do all that math, you can also act as if the equity is worthless, because that is the worst case scenario. Would you be okay with the base salary that you are getting? Okay meaning you are able to pay your bills. Maybe not ball out, but you'd be able to pay for all of your expenses and still have buffer leftover for discretionary spending (vacations, etc) and investing.

> The dilemma I have is that I speak to these in office folks who work on the legacy system that’s honestly spaghetti and I can’t help but think I should want to work there cuz it will teach me fundamental skills. And I need to not get hung up on the fact that it is legacy and old technology.

There are two opportunities that I'm seeing for working with legacy tech: 1. you can still make business impact there or 2. you can iteratively clean up the messy system. Regardless of the tech that's being used, when you are working for a company, your ultimate goal is to drive the business forward, and the technology might not matter if you're building a product on top of it and it doesn't affect your users. If the code is messy, you can put guardrails in place to ensure the code doesn't get any more messy, and then take steps to make the code cleaner.

I've seen people not want to work with a certain product because the design was not great, so they backed away. Then, someone joins, evaluates the system, improves it, and ends up getting promoted to staff level.

If I do have to make the case for using new technology, it can help with recruiting and improving engineer morale. A lot of candidates might see a company using outdated technology and immediately shy away because building experience with the outdated technology may not transfer immediately to their next career move. In conversations that I've been apart of with recruiters and hiring managers, we will ask for specific technologies or frameworks because we know that the person will have an immediate impact once they join.

From a high-level, if you know you are going to switch roles, I would start with the end in mind and try to work backwards. I would look at different job listings for the companies and roles that are interesting to you. From there, you can get a sense of what kind of experience they are looking for. When all of the job descriptions are pointing to the same experience, I would try to focus on strengthening that experience in your day-to-day for your consulting role.

I would also look at the Glassdoor interview data for those companies to see exactly what kind of questions they are asking, because you could be asked DSA and system design questions. Knowing this now is better because you'll know what to study. 

You'll be able to be prepared for the worst case by doing this.

As far as leveling up to be in more senior roles, I wouldn't focus strictly on technical knowledge. As you complete and lead projects, you'll develop that technical knowledge because it's required to carry the project to completion. I would focus more on the high-level end goals for each project, like what are we trying to accomplish with this project, what do we want to optimize for, and how to lead other people into completing the project.

I do think there's an in-between solution where you don't have to write spaghetti code, but the code can be written in a way where it's easy to scale it up in the future.

Tasks as simple as naming variables in a clear way, abstracting out lines of repeated code into their own functions, abstracting logical chunks of code into descriptive named functions, separating out files logically can make code maintenance a lot more manageable. It shouldn't take that much longer.

What is the process around your work? Is it code that's handed off to the client, or do they not ever see the code? Even if they don't see the code, do you ever make revisions to it? Even if no one else sees the code, it's easier to iterate on code that's clean.

I wouldn't refuse the projects, but I would have some bar of code quality for yourself while you are doing development.

> I'm curious if there are any opportunities that you've got due to staying in the Bay Area that you wouldn't have gotten otherwise.

Most of the opportunities are from co-workers who are looking for people to start companies with or co-workers who ended up starting their own company looking to hire. There is a rich startup ecosystem in the Bay Area where companies are being founded each day.

> How important is the location where you stay and work at important for career growth?
>
> But what about engineers working in big tech?

I don't think it matters as much for big tech. But, I do know people who have intentionally moved to the Bay Area because that's where their team or leadership is located. They wanted to get more in person time with them to help with career growth. From that perspective, it makes sense.

I do think that if you are trying to accelerate your career growth, it does make sense to get as many opportunities as possible to physically interact with the people who will be involved with your work. It doesn't guarantee anything, but having more opportunities means more spontaneous conversations, which means more chances to showcase yourself.

If you can do that in any of the other tech metro areas, you don't necessarily have to move to the Bay Area.

It helps that you have 10 years of experience of working in the industry because recruiters and hiring managers can fall back on that experience when evaluating you against other candidates. I've been on the recruiting loops for candidates who started their own company, and they've been treated the same as other candidates.

Once you get into the loop, it'll mainly be about your performance on the technical interviews.

A lot of our system design choices were made to maximize product development velocity because we are a small team with limited cash.

> What technologies are used for frontend and backend?

We use Next.js for our frontend and our API layer. We use Firebase and Google Cloud services on the backend.

> What is the backend architecture used? What are the databases used?

We use a RESTful API architecture + Firebase SDK for reading and writing data. Our API is used for shared business logic between the webapp and mobile apps or exposed to third party services for webhook logic.

We use Firebase for our database.

> How are the videos streamed, payments handled, user logins handled?

Videos are streamed through Firebase.

Payments are handled through Stripe

User authentication is handled through Firebase Authentication.

> How does Taro scale with users and give a smooth experience?

Since we use Next.js, we try to build and cache pages as much as possible.

> How is the platform optimized from the perspective of cloud costs?

From the previous answer, making use of Next.js SSG and ISR everywhere we can helps with minimizing the number of calls to our database. There are more optimizations that we could be doing, but, Firebase is still pretty cheap even when unoptimized. Our time and resources are better spent iterating on the product than trying to optimize the infrastructure.

> When the number of users on Taro increases by an order of magnitude, what are the changes to the architecture you would consider doing?

We might even consider using the same architecture for the webapp because the Next.js caching is working out enough for us enough where increasing by 10x doesn't necessarily mean that our costs will increase by 10x. Cloud platforms are so nice for ensuring stability and reliability at a reasonable cost where it makes more sense to focus on developing a better product.

> Is the website built from scratch? Or are there any libraries and frameworks available to make it easier?

We stand on the shoulders of giants. There are so many great open source frameworks and libraries that we use, like Next.js and Vercel that automates the build and deployment process for us.

> Taro seems like a well-built platform with smooth user experience and a lot of features. I'm surprised that all of this built by just one engineer (Charlie). What's the secret sauce? What are the tradeoffs made to still make things work with less resources?

I really appreciate those kind words! I think a lot of it comes down to being very intentional about whether we can leverage existing tools instead of building them ourselves, the "build vs. buy" argument. There are so many great services out there offering their products at very reasonable prices. We do try to go with the "buy" side as much as possible because you can essentially pay $xx-$xxx to do what it might take many months or years to do with many more engineers.

As far as feature development, we are very careful in doing a lot of user research before we start to build anything. We are also very intentional about making sure the scope is reasonable by only building the features that are requested by users.

> What is the decision-making process that went into making all these decisions?

The key decision-making process is realizing that we are a startup with limited resources, and our goal at this stage is to reach product-market fit as quickly as possible. Every decision we make is based on that premise. This means that there are a lot of optimization or scale decisions that we can't get to or that we need to offload. While these sorts of challenges can be technically challenging and fulfilling, it usually means it's better for us to offload the work to different services that will get you something working immediately.

If you want to learn more, feel free to reach out to me on Slack. Would love to go in-depth about anything you find interesting!

ChatGPT can be pretty good at evaluating a first pass of your system design. It can give you a good first step about how to approach a problem as well as coming up with paths to go down for your specific use case. Of course, you need to be able to think about the solution as it relates to your company's architecture.

I actually would think that the bridging between security and backend is a role where a company wouldn't want to outsource completely because the tail risk is so high if anything does go wrong. The work where you do have to patch up very custom solutions based on your company's architecture can be more difficult to hand wave away to AI. I do think that AI is more of an amplifier and a tool rather than being able to completely replace an engineer.

Based on your current role, do you find yourself being more interested in security or backend work? If so, it could be worth it to invest more time into one of those areas.

> Also, some of my peers inherently understand things for which I had to take Taro membership and be in the community /QnA to get and it bothers me that I don't have the intuition in lot of such things that seems obvious to them.

This is totally okay. I do believe that curiosity can get you in the same position as someone with natural intuition. It may take longer, but curiosity will keep you in the game and learning. Maybe there's a lack of intuition, now, but it sounds like you are resourceful and curious enough to make up for the lack of intuition.

Also, it's not a worthwhile exercise to compare yourself to your peers. It's possible that they could have had a wildly different background than you where they developed that intuition that seemed like it was natural. They might have been involved in activities that are adjacent to what they are working on now that made it easier for them to develop that intuition.

> ***isn't the only way to know if something is fun for me is to explore different fields and spend some time to learn the craft and see if its fun across the field's highs and lows?***

I think it is worth it to try out different parts of software engineering to see if it's worth it. One way is building rapport with different teams and managers. Since you are in DevOps, you probably have warm connections with different teams. You can ask your manager to see if it's possible for you to do 50% work on other teams or if you can even switch teams.

> Which would generally get a better score in a live coding interview? Fully implemented and hard to follow, or easy to follow but not finished?

I would challenge yourself to not set the expectation for yourself to be one of those two choices. Instead, the gold standard is to have both easy to follow and working code. Remember, you are going to be judged among other candidates, so the goal is to set the bar very high for yourself. But, if you had to pick one, you have to solve the problem at the end of the day. A lot of interview rubrics will give the candidate a weak no if they aren't able to solve the problem completely. There's no leeway unfortunately. I've seen candidates pull out heroics where they end up solving the problem in the last 5 minutes in a haphazard way, but since they solve it, you have to give a weak yes.

> Is there negative signal from frequently debugging over proof-reading code, and if so is there some threshold?

There is some negative signal because it makes the interview think about whether the candidate knows what they are doing at a higher level, or if they are just guessing and hoping that they are able to get the output. The issue is that, in a production environment, this kind of thinking can lead to a lot of errors because it shows the candidate can have tunnel vision where they aren't thinking of the full picture of what they are doing. I think it's not a great approach to come up with an initial solution and sort of hand wave the edge cases away until you run into them, then solve them because it can greatly alter what the best solution is.

> If you're someone who has interviewed others, do you think there is a way for a candidate to be more disorganized but still clear. For example, if someones goes over the high level approach and says "I am now going to code out the rough happy path, it will take me a few minutes as iron out the syntax and refactor as I go", then I plug away, and afterwards, do a quick walkthrough of the completed code?

I would reverse the order and do a walkthrough of your approach first. A lot of times, interviewers will prompt you with edge cases, and it's a lot easier to think about how the edge cases fit in with a more complete solution rather than band aiding fixes for the edge cases later on.

> I often use a random variable (could be the correct one or wrong one) as a placeholder while I type out the logic for some snippets and then update the variable to be the correct one after

I do recommend getting out of this habit for interviewing because a part of most interviewing criteria is code quality. It's a simple enough mindset shift where it's worth it to take the extra 1-2 seconds to come up with a clear variable name as you are preparing for your live coding interviews. You can even practice this as you are coding in your day to day work.

I agree with Jonathan about scheduling at the end of the time range. A team will usually schedule out interviews with different candidates, and even if there's a strong performance, they'll usually wait until all of the scheduled interviews have happened before making a decision. It's really rare to see a team interview a candidate, then decline the rest of the interviews because they have found their perfect candidate.

If you aren't prepared right now, it can only help you to schedule as far out in that time range as possible.

> The primary reason why I really want to join this startup is to catch that hypergrowth wave, similar to what Seed did during his time at Klaviyo. However, something that worries me is that by the time I join this startup (in Jun, Jul or Aug 2025), the hypergrowth period will have ended, which kinda defeats the purpose of why I'd want to join in the first place.

Do you have evidence that growth will slow down next year? One useful exercise is to try to come up reasons for why the startup could continue its growth as well as reasons for why the startup might slow down its growth. Then, for each of the reasons, come up with probabilities for each reason. A lot of the reasons that you come up with could be made up, but it can help to guide the questions that you ask.

1. What verticals are they thinking of expanding to, and why did they decide to target these verticals? (you could look at comparable startups that also target these verticals to estimate how big the market is, and use it to estimate the potential valuation)
2. Where is their revenue coming from? How do they charge their customers? A good sign is if their current customers pay more based on usage or based on head count because it means the startup will scale as their customers scale.

There's probably a reason why you want to join a hypergrowth company: learning quickly in a fast moving environment, being able to quickly advance your career as fast as the company grows, or capturing the growth of your equity value. I would try to figure out what is the most appealing from the above reasons to ask questions about whether that opportunity will still exist when you join a year from now.

> If the promotion happened very recently, will we be at the risk of getting down-leveled?

I've mainly seen technical interview performance used to inform what level an engineer should join a company at. The difference between a mid level and senior engineer is how well they do at the system design portion of the technical interview.

It's possible that it could be used to downlevel you at companies that are known to be more stingy when it comes to setting the initial level of an engineer.

The best way to sidestep all of this is to get as many offers as possible so you have more leverage on coming in at a certain level.

It doesn't hurt to ask the recruiter about the structure of the interview: how many interviews will you have and what kind of questions will each person be asking. I would ask what tools you will have access to during the interview.

For the frontend portion, definitely brush up on the React docs, look up some common React mistakes, and look up some Javascript common mistakes.

You should be able to build a full React webapp end to end in a web IDE. I would make sure you are comfortable with doing this by opening up a web IDE and being able to create a simple React webapp, like a todo project.

I'm glad to hear that the Taro Job Board is working out for you!

For context, I don't have a lot of background about the green card lottery vs. visa odds. At the end of the day, the green card lottery system is a lottery system, so the outcome is out of your control.  At least, you are in charge of your own destiny when you join a company that offers visa sponsorships since you can study and prepare for their interviews. Is it possible to enter the green card lottery while you are applying for jobs that offer a visa sponsorship?

> but is it a good idea to substitute these efforts by applying to all those jobs as well?

I would do this because you can experiment and iterate on your applications to increase your chance of success.

Also, we are always open to feedback about the Taro Job Board, so feel free to reach out to me in Slack if there's any way that you feel we can make it better.

> Additionally, should I also start to look externally? I'm quite confident in my Leetcode/interview skills, have a Tier-1 school on my resume, and work at a FAANG tier company currently, but I understand the market is bad. Would it be possible to get an L4 level role externally now or in the next six months?

I think it's worth interviewing externally because a lot of the promotion process is out of your control.

Given that that you went to a tier-1 school, are working at a FAANG-adjacent company, and have a few years in the industry, you are in a good position to get interviews.

You should have two parallel tracks going: 1. trying to improve your chances as much as possible to get promoted at your current company, while 2. interviewing externally just in case everything falls through.

You want to hedge against the case where you are waiting \~6 months for the January promotion cycle results to come back (it sounds like the cycle starts in January, but it might take some time after that before you get results?).  The issue there is that there's a chance that the results don't come back with what you expected, and you've wasted time that you could have been interviewing.

Even though the market is bad, it doesn't hurt for you to try to look for opportunities externally because you'll at least get information for what you need to work on. The chance for success is &gt;0% if you go through the interview process, but it's 0% if you don't try.

> I trust and really like my current manager, but I want to communicate these concerns in a professional way. How should I do this?

I would let your manager know that you want to leave no doubt in the committee's mind that you deserve a promotion and that you want to work with them regularly to ensure this. Your manager mentioned that they have concerns about your current packet. Can you go over with them projects that you can work on that would seal your promotion? I would also go over all of the promotion criteria and make sure there's a strong case that you are operating at the next level currently.

> For instance, I always review my own PRs myself before sending to reviewers, and clean up plenty of issues I notice myself. But then my reviewer will point out some kind of bug, or something I forgot to do, and in retrospect it will be immediately obvious to me. Alex often mentions the importance of being able to get most of your PRs accepted in one attempt, but for anything &gt; 30 lines this simply feels like a pipe dream because I am so terrible at noticing things until it's too late.

A lot of this comes down to experience. Reading the above, I'm hearing that there are two categories of issues in your PRs, bugs and forgetting to do something.

For the bugs, you could have syntax bugs or functional bugs. The syntax bugs should be avoidable with linters or a code formatter. For functional bugs, it helps to try to brainstorm all of the ways that your solution might not work before you ever start writing a single line of code. Why do this before you start writing the code? Because finding an edge case might drastically alter your solution.

For the issue where you forget to do something, it helps to have a checklist that you go through when completing a specific task. Bonus: if you can help to automate these procedures, you'll be a hero among your team, and since it impacts many engineers, it can help with career progression. Having to change a config in production to verify your shipped feature sounds a little bit iffy. I don't have all of the details, but it makes me wonder whether there's any way to improve that process.

> I realized mistake I made (ran a command to change a bunch of files in the wrong directory) but only after the fact, and it cost me embarrassment and extra work.

After I complete a task, I go through the list of "things that could go wrong" that I made before I started coding up the task. And, I make sure that my solution addresses all of those issues.

> I don't know though how I would know about code quality from the interview process. I can imagine maybe asking multiple engineers from the company what they think during the interview process.

Generally, the code quality at your FAANG companies and unicorn startups (or on the path to unicorn status) will have higher code quality because they pay more which attracts a higher caliber of software engineer. They need to have the higher code standards to move faster and reduce incidents. There will usually be platform teams who are responsible for ensuring the code quality is high.

> A flexible vacation policy that is actually flexible as I've usually taken about 5 weeks off a year, commitment to remote work, flexibility to set time off during workdays.

There are a lot of startups that have unlimited PTO and remote work and still pay well. One exercise might be to look at the top paying startups in [levels.fyi](http://levels.fyi), and work backwards to see which companies have unlimited PTO and remote work.

You should check out open Netflix roles (<https://www.jointaro.com/jobs/netflix/>) because there are some teams that operate as completely remote teams.

> But I think that's secondary to the factor regarding code quality.

If code quality is a big priority, you could try to pitch some code quality projects in your current role. This could help give you a leg up for applying and interviewing at other companies. It sounds like you don't necessarily want to be the one responsible for code quality, but if code quality is so important to you, maybe it's worth considering stepping into a platform role to help out.

Coding velocity will probably start to equalize across all software engineers because of the rise of AI tools. There are critical analysis skills that are harder to replace, like weighing tradeoffs and picking the best path forward given your constraints and goals.

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.