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!

Software Engineer @ Taro, ex-Pinterest

Charlie Vuong

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.