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

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

Software Engineer @ Taro, Pinterest

Charlie Vuong

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Software Engineer @ Taro, ex-Pinterest

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

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

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

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

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

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

Congrats on landing an interview!

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

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

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

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

Good luck with the whole interview process!

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

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

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

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

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

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

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

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

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

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

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

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

Senior Software Engineer [L5]

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

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

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

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

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

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

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

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

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

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

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

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

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

Onboarding

Testing

Playlist name

Playlist name 2

Playlist name 3

Playlist name 4

Playlist name 5

Another playlist

Really long playlist name really long

One more playlist

This is a new playlist

Networking

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

Big Tech Playlist

Comms Playlist

Another Comms Playlist

Test

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