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.

Eng @ Taro

Charlie Vuong

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

I will say that it depends on your ultimate goal:

- Do you need to recall the info at a later time where you don't have access to resources? (example: a technical interview or an exam)
- Do you need to complete a task without knowing the foundation underneath? (example: completing a project)

If you want to learn something deeply, you'll need to struggle through the material. It's not enough to passively go through the material. But, you also don't want to spend an entire week struggling on a problem because you won't learn quick enough. A solution is to timebox the struggle time to 15-30 minutes. Or, you can make sure that you come up with 3 solutions, then look up the best solution.

For your own personal projects, if the goal is to ship something, make use of all your resources: use AI tools or ask people about the problem.

Since you are so early in your career, it will probably be worth it for you to do the interview to get more interviewing experience.

Also, do you know if they have an option to reimburse you for travel? It might be worth it for you to get to the location the night before and stay at a hotel near their office, so you don't have to stress out about the commute the next day. If they didn't initially extend that option, it doesn't hurt to ask.

> I wish there are people who can mentor and review my resume etc. The problem is "How can I even approach them in the first place?"

Hi, there are a lot of resources on Taro where you can get help with your resume.

- Taro Networking (<https://www.jointaro.com/networking/>)
- The #job-seachers-accountability-group Slack channel
- Check out Taro Events for resume review sessions (<https://www.jointaro.com/events/>)
- Check out Alex's course on how to write a good resume (<https://www.jointaro.com/course/get-more-interviews-write-a-stellar-resume-as-a-software-engineer/>)

> I don't know how to start a conversation or how they will react. I am worried that I might take their personal time.

I would try to lean on the side of starting the conversations and focusing on how the conversation could go right rather than how the conversation can go wrong. It's true, not everyone will respond positively, but you only need to find a few people who are able to help you out. 

If it's possible, would you be able to post the different project options? We can go through the exercise of going through the pros and cons of each.

To make sure you are growing in your career, I would look at these signals:

1. Is the technical complexity higher than any of your previous projects?
2. Is the people scope higher than any of your previous projects? By people scope, does the project require working with more teams or more engineers?
3. Which project has the most business impact? These projects will probably have the most visibility from leadership.

> I'm also a bit worried about doing things behind my managers back as I'm worried it'll look really bad.

The key will be framing how your code contributions can help your team and any other teams. Since you are an SRE, one of your goals is to improve the stability of your products. If you get get your manager and the manager of the other team to agree that your suggested code changes will help with the stability of your product, you can create a win-win-win situation.

As a first step, you can add more logging into the code to improve observability, especially if there have been recent incidents related to that code. You can set up a meeting with someone who works more directly with the code to get a walkthrough of where the relevant code is, what are some pressing issues with the code, and how the code gets deployed.

You'll be able to build relationships with the team that is more development heavy. This'll make it easier to potentially switch to that team in the future.

> The place I'm working at is super slow -- it took me 1 whole week just to get access to the code in my own team and it took 2-3 weeks to get access to all the other tools.

This is something that is hard to fix especially if it's ingrained in the company culture. That team really needs to have an SLA process in place to make it easier to grant tool access to employees. That is a really high turnaround time because a lot of progress could have been made in those few weeks.

If you want to stay at the company,

I would bring it up with your manager during your next 1:1 and start making a plan with them about how to get into the higher range for your position. The conversation will usually involve how you can operate at a level where you are exceeding expectations for your current position.

One issue is that this is not guaranteed, so you could potentially waste a year operating at a higher level, but not reap any rewards.

If you are okay with leaving the company,

I would interview externally because it will give you a good sense of your value outside of your current company. You can compare your current compensation to your offers and find out if you are being undervalued. This is probably a good exercise to do in general if you are truly trying to maximize compensation.

I would look at total compensation for senior engineer positions at big tech companies (FB, Google, etc.) in the US on <https://levels.fyi/> to get a sense of your market value.

> Do you think I can find a remote company that pays well based on their market if I stay in my country?

Most of the time companies will pay you depending on where you live. I'm not sure where AU lies in that equation, but usually the highest remote pay bands are for employees that live in the San Francisco Bay Area, Seattle, or New York.

If you are trying to maximize compensation, it might make sense to find a company that will help you relocate to one of the above metro areas. Most of the larger tech companies have RTO, so you will most likely have to relocate if you do want to join a company that pays on the higher end.

> I used to enjoy doing the work I did but as of late it feels repetitive, and even though there is so much scope to learn, I get overwhelmed by the sheer amount of it and let it go

I would work with your manager to delegate repetitive tasks away to teammates who don't have as much experience with that task. To grow, you want to be working on tasks that are on the edge of your ability. This is how you continue to develop new skills over a long period of time.

You can have two people work on the same skill for ten years. If one continually pushes their skill development each day by trying more and more challenging things, they'll be a lot better compared to someone who goes through the same rote routine and motions every day.

When you mention there's a lot of scope to learn, I would try to break down the material into bite sized chunks that you can work on. When I hear "too much scope to learn", I would be careful that you aren't trying to just consume information rather than producing something valuable. You actually don't need that much information to start. Bias on producing a deliverable rather than reading. You'll learn a lot more this way.

> create more impact to be a senior engineer

I would try to reflect on what behaviors and projects you've had or worked on within the past year. Then, I would come up with the profile of a senior engineer. From this, you can work backwards to see what behaviors and projects you need to work on for the next year to reach senior engineer.

You can try to brainstorm any workflows or processes that you do each day to see if you can incorporate AI to automate the process.

- If you like to cook, you can build a tool that scrapes recipes across different sites, passes the page through an LLM to remove all of the unnecessary steps. Maybe you can build something where you can take all of the recipes you want to make in a week, and the LLM can give you a shopping list.

You could make the argument that it might be too early to introduce a strict documentation process since the company is so early and having a strict documentation process could slow your team down.

I would start with an onboarding doc to make it easy for new engineers to get started immediately in the codebase and incrementally add documentation as needed. If there's a pattern of different people asking the same questions, it's a good signal that documentation needs to be added about that topic.

If an engineer asks you a question, and it takes a 30 minute meeting to answer the question, and 3 engineers ask you the same question, it's a worthwhile investment to spend the time to write up documentation to answer the question.

Interviewing is a skill, which means it's something that you can improve at. After each interview, I would reflect on what went well and what could have gone better, then set action items for yourself on how to improve the things that could have gone better. That list might include:

- Tightening up your personal narrative
- Learning more about the company
- Working on a certain DSA topic

This will make the interview process seem like less of a black box that you have little control over.

> I am good at Systems design. It comes very naturally to me when compared to DSA in that I exhibit systems-level holistic thinking.

I would say that this higher level thinking is more important as you progress in your career. The reason is that your scope broadens to multiple teams, so you need to know how all of the teams and services interact with each other to get your desired outcome.

Unless you are actively interviewing, you shouldn't need to worry about your DSA skills too much. But, if you are interviewing right now, I would try to adopt a growth mindset around your ability to improve your DSA skills because they can definitely be improved if you put the work in.

You'll find a longer career path for frontend engineers at companies where the frontend product contributes significantly to the overall company revenue. You'll have more scope because there will be more teams working on the frontend product, which means the depth chart will be deeper.

1. Even if the project isn't technically complex, if the outcome of the project can improve KPIs, that might be the more important thing.
2. You can add technical complexity to the project by greasing the wheels and making sure that the project is executed smoothly. This might involve adding internal tooling, analytics, or helping out with the coding to help debug issues or make it easier for teams to accomplish their goals.

> My question is, is there any value in me receiving emails for all those other people in my department who's code I don't care about (at least for now)? Should I try and either unsubscribe from or auto-archive their emails so I don't have to delete/archive those emails every time I access my inbox?

They'll ping you if they really want you to look at their review. I don't think there will be much value if you look at every incoming PR. But, if there is some core code that other people are touching, it might be worth it to add yourself or your team as a blocker for those changes.

It may be worth it to try to apply for jobs with your current work experience to see how it goes. I can't speak for how recruiters judge resumes, but I stopped looking at the candidate's education after they worked in the industry for a few years. (That being said, by the time the resume got into my hands, it already got through the recruiter's filtering process).

I would try to play up your work experience as much as possible in your resume. Remember that your work experience can take up multiple blocks in your resume. Your degree might take up one line, and it's usually placed lower down in your resume.

From what I've seen, there's more career progression with software engineering because there are more impactful decisions that have to be made as you progress up the engineering ladder. There's a larger group of people that you have impact on, so there are more career levels in the engineering ladder. I imagine because there are more levels and scope, there is probably a higher ceiling for pay, too.

If you have passion for both domains, focusing on software engineering may be the more flexible option because you can dive into the nitty gritty implementation and write about it with more clarity and precision. You can parlay your engineering experience into writing for your company's technical blog, improving the internal documentation, or writing for your own Substack.

Hopefully, there's a technical writer lurking the the discussions that can give you another perspective!

Using GenAI to supercharge documentation is a common use case.

You can audit all of the internal tools inside of your company to see whether they can be improved with GenAI.

Definitely, if you can start implementing staff level behaviors as soon as possible, it will make your time at senior go by more smoothly.

I would try to avoid eating processed food as much as possible. You can also get a food allergy test to see which foods don't work well with your body and avoid those foods.

Here are a few tactical tips to make sure your API design is bulletproof:

- Make sure you cover alternative approaches, tradeoffs, and why you ultimately decided on your design
- Request comments from people on your team and other teams, preferably more senior engineers
- If there are any unresolved comments or a lot of back and forth, I would try to resolve these issues in a meeting to make sure you get that sign off.

There is a point where you should feel like you've exhausted every little edge case and answered every comment. At that point, you'll only get diminishing returns, and it's not worth it to spend more time on your design. You've done everything you can at this point.

I would recommend treating the readout like a workshop where leadership isn't judging you, but they are trying to get clarification. They usually want to make sure that other teams are aware of the work, other teams agree to the work, other teams know how the work will impact their own timelines, and that the timelines are reasonable. You can try to put yourself into their shoes to proactively answer any questions that may be asked.

I would try to reframe your perspective about looking dumb or whether people will look down on you. I would try to see this as an experience where you are all working together to make sure everything is buttoned up as much as possible so the execution will be as clean as possible, which will minimize any roadblocks from happening in the future. Hopefully, leadership is trying to help you, and they want you to succeed because when you succeed, they succeed, too, and you all win.

As an intern, it's fine to sound uncertain on what you want to work on because you haven't been exposed to enough domains to have a strong opinion. But, I would at least let the company know which part of the stack you want to work on so they can help guide you better. If you are going to be interning for 3 months, you don't want to get stuck on a project that you don't want to work on, so you should be transparent about what direction you are leaning towards.

Since you don't know what teams exist in the org, it may be worth it to ask the company about which teams are accepting interns and a quick blurb about the team and projects they've worked on before. You could even ask to schedule a meeting with someone on the team to see if the work aligns with your interests.

For missing a meeting, it's fine to say "I am so sorry I missed the meeting. I completely lost track of time." If you can add comments on the meeting doc for larger group meetings or take the initiative to reschedule a smaller, 1:1 meeting, that will signal that you are truly invested in the topic.

The important thing is that you learn from the mistake after apologizing. If you keep making the same mistake over and over, all previous apologies will start to sound disingenuous. It will sound like you are making excuses, and you won't sound trustworthy. Can you come up with an action item for yourself to prevent yourself from missing another meeting? That might look like setting an alarm on your phone 10 minutes before a meeting.

> What specific skills should I focus on mastering to increase my impact?

There are two pillars where you can increase your impact: project scope, people scope, and business impact. Project scope is how technically complex a project is to execute. People scope is how many engineers, PMs, etc. are involved in the successful execution of the project, and business impact is whether the project is moving the right metrics forward that will advance the business forward.

> How can I get involved in or initiate projects that are high-visibility and directly impactful?

You can look for engineering pain points (inefficient processes, wasted time, wasted money) or product opportunities (streamlining processes for users, making it easier for users to achieve their goals). From these initial ideas, you can start talking to other engineers/PMs to gauge whether these are indeed large issues. This will also help you to grease the wheels and get them thinking about the problems. It helps if you can do some data analysis to back up your hypotheses.

> What strategies work best to ensure your contributions are noticed by leadership?

If you can give regular updates in communication channels (Slack, email, recurring docs), your project will be top of mind.

> How do you cultivate a leadership mindset as an IC, even without a formal leadership role?

It helps to be involved in the complete, end-to-end execution of a project. Make sure all of the requirements for a project are ticked off, projects are tracking to a timeline, constantly unblocking people, and resolving open questions.

> Should I be reading up on more theory before I start doing more of the roadmap? Maybe go through Neetcode's courses.

I wouldn't go through the theory first, unless the problem is completely unfamiliar to you. There are a few reasons why. it can be very easy to procrastinate because you get a false sense of accomplishment by just reading theory. Before you read the theory, I would try to struggle with a problem first. So, when you do read the theory, there will be more "aha" moments because you've found a more effective way to solve a problem compared to solutions that you thought of before.

> Does it simply take solving more problems to build up the intuition?

To understand problems at a deeper level, it helps to connect different problems you've seen before with each other. It can be easy to fall into a trap of just memorizing solutions. I would try to go one step further to break down solutions into smaller chunks or patterns and connect the smaller chunks with smaller chunks you've seen in other solutions.

> Should I try harder on my own before checking the solution video?

Yes, it might be worth it to operationalize what it means to try harder. You don't want to just stare at the problem for 20 extra minutes and hope that a solution suddenly appears out of the ether. I would try to write out, in pseudocode, 5 potential solutions that you could use to solve the problem. It doesn't have to be exact, but you want to have written down something. After you look at the actual solution, you can retrospect back on why each of your 5 potential solutions did/didn't work.

> How did you build the intuition to solving new problems?

A lot of it is pattern matching. There are common components that make up a lot of solutions. If you can bucket a problem into a pattern, it can make a problem a lot more manageable. But, I will say that there are problems that are just completely out of left field. Sometimes you just get a tough draw. The best you can do is to communicate to the interviewer how you think about the problem, potential solutions, and why you think a potential solution is the best way to solve a certain problem.

I have seen recruiters ask technical questions before, but it's usually with more trivia based questions, and the questions are usually "you either got it right or you got it wrong". There's usually less back and forth because the recruiters are going off of a script of questions.

I imagine companies do this as a quick filter (short time, low stakes) before bringing in more technical people for longer interviews.

Sorry for the frustration that you are feeling. There's a lot of luck at play when interviewing at companies: your focus might be shot because of a bad night of sleep, the interviewers could be dealing with an incident and be in a bad mood, or the company just decides that they are going to eliminate head count for the role.

You did everything right that was under your control, and that's all you can really ask for. These interviews hurt because there's not really a takeaway from them that you can apply to the next interview.

> My manager initially told me we'd probably meet once a month

Can you suggest meeting with your manager every two weeks instead and set clear time expectations about the full-time conversion? The goal will be to make sure you are both aligned on what work needs to be done to get the full-time offer. A month timeframe can make it difficult to course correct early. If you can send updates in a regular cadence through email, chat, or a 1:1 doc, you'll make it a lot easier for your manager to evaluate you when it's time for them to consider you for a full-time position.

Your manager will probably solicit feedback about you from your peers if they don't have a lot of insight into your work. This advice isn't going to be that helpful because it's so obvious, but I'll say it: make sure you are proactive in your work, get things done, and communicate with your peers with regular updates.

> However I'm concerned my RSU grant will still be the same

It might be worth asking the HR department whether your company adjusts initial RSU grants if an employee transfers locations.

It's possible that this is too much of a micro-optimization to reset the RSU grant. If you are happy with your team and the company right now, your energy might be better spent doing well at work. But, if you are thinking about transferring, it's probably best to do it as soon as possible, esp. if you aren't tied to Canada and want to plan to live in the Bay Area in the future.

Sorry to hear that your manager pushed back on you merging your code in smaller chunks. One issue with merging in your larger diff last, is that the burden lies on you to make sure all of your new code works with the code that was merged in since you started working on your code. When you can merge in your code in a piecemeal way, the burden is shared among your teammates. You are in the right that your manager should have let you merge in code a little at a time.

I'll say that everyone in software engineering goes through a rite of passage where they have to wrestle with version control, so you aren't alone :). The two most common issues I see are: accidentally resetting a work in progress branch and dealing with a ton of merge conflicts. It can seem like the world is collapsing in on you when these things happen, but both are recoverable, and you'll get through them.

> When it came to merging my code, I made errors in resolving merge conflicts, which resulted in errors. I tried ‘undoing’ the commits by reverting changes (when I should’ve done a reset), which caused the commit history to become longer and more complex, making the situation worse. After rolling back commits, somehow even the old code wasn’t working.

One way to avoid too many issues with version control is to keep the history as simple as possible. When I want to merge in my branch, I will squash all of my commits into a single commit. Then, I will fetch all of the latest changes from the remote repo. Then, I'll rebase my one commit on top of all of the latest changes.

You mentioned that you had to roll back multiple commits. I think squashing all of your commits together into one commit would have helped a lot in this case. If there was an issue, you know that your commit would have led to it, so you would have only had to revert your commit.

> Our company doesn’t have any formal CI/CD protocols. When we ‘push to production’ that would mean testing code on our local computers, then going onto our single production machine, clone our changes, test on the production machine, then merge to main. The dev team was incredibly small, but this process started failing when more people worked on the codebase.

Since you're an intern, the CI/CD process is mostly out of your hands because the scope is too large for the short internship time frame. But, it does sound like an interesting opportunity if you were to return with a full-time offer.

> How should I handle this situation? I definitely feel like I should apologize but how can I make up?

This is a pretty common scenario, so I wouldn't worry too much about it. I would just make sure that you are diligent with making sure that everyone else's changes still work after you are able to resolve the merge conflicts and get your changes on the main branch.

You can try to think of the tests as protecting you and your teammates when one of you refactors the code a few years down and a lot of the context behind the code has been forgotten. The test case, if it fails, would have caught something that would save you all from an incident in production.

From that angle, can you think about the cases where if the class gets refactored, as long as the tests pass, the core functionality of the class will still be intact?

If you are writing unit tests for a class, you can create unit tests for every public method.

I like your thinking about having both positive and negative test cases, but try to avoid redundancy in your test cases.

> Can you help? I'm not happy with my current situation. I used to be a curious person, staying up all night coding and learning new things. However, for the past two years, I've been merely going through the motions at work. I want to regain my curiosity and sense of empowerment, so that when I go to bed each night, I feel excited about what I can achieve the next day.

I empathize with your friend. I'm sure they've developed a feeling of helplessness and a loss of agency right now, which is probably leading to some depressive symptoms.

How do they feel about the company overall? In their mind, is it worth it to try to salvage their situation by switching projects or switching teams? It will help with the immediate issue of dealing with uninspiring work. But, they may find that there's just another set of uninspiring work.

The issue here is that it will delay a promotion because they'll be on a new team and have to prove themselves again. So, at that point, if promotion (and a feeling of upward trajectory) is the issue, your friend may as well leave the company and join a company at a senior position.

Have they tried to voice their promotion woes with their manager? Your friend probably has a lot of built up resentment from the cancelled meetings and delayed promos. It's worth it to at least let their manager know even if they feel like they are out of the door, so your friend can let off some of their frustration and the manager can improve their management skills. Your friend can send a quick message to the manager like, "hey, is there any way you can find time for a meeting at the end of the day? I've been feeling frustrated lately and wanted to chat.".

Even if their manager says that they'll help them out with a promotion, nothing is guaranteed, and it might just be worth it to join another company instead of waiting for the next promotion cycle for only a "chance."

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.