I haven't seen that many write ups of interview process for more senior engineers, so here's mine. I haven't gone into detail on the particulars of any of the interview questions partly because I don't remember all of them, partly because there wasn't anything super novel being asked and also because it'd be pretty easy for some of these companies to figure out who I am, and there's no need to burn any bridges :D

I did a lot of interviews! These were all done remotely because of covid, which I actually prefered. It makes a big difference to not have to commute. Also is pretty great to be able to interview in sweatpants.

About me:
Experience: 9 YOE at 2 FAANG companies
Education: BS CS at non-US university, not well known
Location for all: San Francisco or Remote
Date: September 2020

My work experience has mostly been in infrastructure, so was applying for roles in that area. Some of the interviews had questions very focused towards that, so want to call this out - I don't expect that everyone would get these types of questions. I was also interviewing for staff level roles, so the balance between system design and coding was different to more starting level interviews. Mention this because no need killing yourself on system design if you're not going for a role that requires it.

I started with some interviews at startups so that I could practice and get over interview jitters. I was also in the process with Google, Lyft and Netflix, but cut them short because I was happy with my offers. I tried to have as many interviews lined up as possible so that I didn't have everything riding on just one of them. As with everything in life, practice really helps.

Because these interviews were all for staff or senior level roles, there was generally a fair bit of back and forth before the onsites, where I had the opportunity to talk to various managers to see if their team was a fit for companies where they hire you into a specific role.

The levels don't necessarily match up with each other based on name. I used this to compare: https://www.levels.fyi/?compare=Stripe,Pinterest,Airbnb,Square,Facebook&track=Software%20Engineer

Facebook [Offer]:
Position: E6 Software Engineer
Process:
I was previously at Facebook (but more than a year ago), so I did a shortened loop, but still a full onsite.
Manager Screen: Because this was for E6, did a call with a manager talking through past experience, etc. No coding screen.
Onsite: 2 systems design, 2 coding, 1 behavioral
The double design interview is because I was going for E6.
One question was around a geolocation system and the other around a turnbased gaming setup.
I can't remember the coding questions, but think one round was LC easy+medium, and the second was 2 easy questions.
Behavioural included a very quick coding problem and then was discussing my background and how I work with others.
Other:
The design questions are the most important for this level (according to the recruiter). In these, I tried to show end-to-end understanding and then dig in after the interviewer seemed okay with the overall flow.

Airbnb [Offer]:
Position: L6 Software Engineer
Process:
Manager: Spoke to two different managers about what their teams did, what they were looking for, etc.
No screens - they offered to let me go straight to onsite.
Onsite: 2 systems design, 1 coding, 1 behavioral
The systems design questions were fairly generic - one around caching and cache consistency, the other around distributing files.
Coding questional was practical - log parsing - less LC and more something small that you could actually be expected to do in real life. It was my last interview and I ran out of time.
Behavioral was with the manager and was more like a discussion than a straight interview. No coding.
Other:
I think it's unusual that I only had 1 coding round - not sure why.
I was going for a more SRE role, so the questions did lean more towards that. The team I would join interviewed me so it was a good opportunity to get to see who I would be working with. One guy interviewed me from Starbucks, which sucked because I really struggled to hear him.

Pinterest [Offer]:
Position: L6 Software Engineer
Process:
Manager Calls: Spoke to two different managers within their infrastructure org. Again, around team fit, and role expectations.
Coding Screen: Did 2 LC-ish questions. The second question built on the code from the first.
Onsite: 2 coding, 1 systems design, 1 domain specific, 2 behavioural
Coding questions were LC easy and mediums.
System design question was around designing some limited set of Pinterest features. The interviewer was quite interactive, felt much more like a conversation than a straight interview. I enjoyed it.
Domain specific was around the team I was joining. I don't actually have deep experience in this area, so it was more a loose discussion of how my previous experience could apply, how I've dealt with problems in the technical area before, etc.
1 behavioural was with the team manager, and the other was with their head of infrastructure. Both were more like chats.
Other:
The behavioural interviews seemed half getting to know me and half selling the team to me. I would guess that I had two of them because I was going for staff level.

Square (CashApp) [Offer]:
Position: Level 7 Software Engineer
Process:
Coding Screen: Practical question around parsing data - not LC style.
Leadership Screen: Interview with 1 manager and 1 engineer - behavioural questions around leadership roles I'd held in the past.
Onsite: 1 coding, 2 systems eng pairing, 1 Sys Design/Architecture, 1 Previous Experience (Behavioural), 1 Sell
Coding question was pretty practical - no LC style coding.
Systems eng pairing was around debugging and running some Kubernetes/Docker setup. I had to ssh into an EC2 instance, share my screen and then work through the questions with the interviewer. I didn't have previous Docker/Kubernetes production experience, which they knew, so it was more around seeing thinking processes in debugging, designing systems, etc.
Sys design was fairly standard.
Previous experience really dug into previous projects of mine, what worked, what didn't, with a focus on the people side of things.
And finally, the sell was a chance for me to talk to a senior leader (and have them sell me on the company).
Other:
This was a pretty unusual interview overall. All the interviews had two interviewers in them, one who was shadowing and the other leading it. As I mentioned, I didn't have much experience with the tech used in the systems pairing, but this wasn't an issue as I'd used similar things before and I got the feeling they were interested in my thinking, not whether I remembered specific docker commands, etc. The behavioural was the most indepth one of all the interviews I did - they really got into things and seemed to be looking for very specific attributes. Overall I really enjoyed the interview process (as much as one can enjoy and interview). I hadn't been super sold on Square before, but the interview made me re-evaluate them as an option that I considered seriously.

Stripe [Offer]:
Position: L5 Software Engineer
Process:
System Design Screen: Asked to design an e2e metrics/observability system.
Onsite: 1 coding, 1 technical presentation, 1 manager chat, 1 sys design, 1 leadership/behavioural
Coding question was around string manipulation - LC medium
I was asked to prepare a 20min presentation on a previous project I'd done. We then discussed the work, I answered any questions, etc.
System design was fairly standard.
I spoke to both my potential manager and the head of the org. The org head asked pretty probing questions around previous teams, how I worked with people, handled difficulties, etc.
Other:
Like the Square interview, this was very unusual compared to the normal idea of interviews. It was a lot more around sys design and explaining my thinking than the others. The presentation took a lot of time to prepare (20min is not very long to describe a year long project+all the context to understand it), but it really allowed me to highlight my skills. I don't think it's accidental that this was my best offer - they really allowed me to show them what I was best at.

ByteDance [Offer]:
Position: 3-1 SRE
Process:
2 coding, 1 design, 1 behavioural.
Coding was all LC. 1 easy + 1 medium for each round. For the first of the coding interviews, when I finished early they asked me to describe what happens when you curl a https site.
Sys design was very focused on infosec.
Behavioural went over previous experience.
Other:
They did their onsite over 4 separate hour long interviews spread over a few weeks. All the US ban talk was happening at this time - I didn't get a good idea of what the team or work would be like.

Others:
Did a single coding phonescreen with Lyft (LC medium), take-home exercise for Netflix + coding screen (this one was strange - LC medium, but he wanted it done in a very specific way), was pushed straight through to onsite for Google because I had a short timeline. I dropped out of the interview processes for all these because I had offers I was happy with.

Preparation:

• I did every question in Cracking the Coding Interview and went over the answers until I was sure I understood. This provided a really structured way of learning, because the book is broken into different topics. All the the CTCI questions are on LC, but it really helped to have them structured so that it was clear what I was working on while I ramped up. I then supplemented with LC questions. In my opinion, the coding interviews really come down to pattern recognition. You do enough practice so that when you get a question you haven't heard before you can pattern match it to similar questions, and therefore a technique to solve them. I spent about 2 months on coding prep - couple of hours every day.
• For system design, there are a lot of wikis and tutorials out there. I found it really helpful to break things down into storage + compute + communication and then see how those were different for various test problems. Another thing I found really important was finding a way to structure my answer so that the interviewer could follow along - especially since I couldn't use a white board. When I started out I would kind of jump all over the problem space. Practiced being more methodical about how I answered the question to make sure I gave a highlevel overview before diving deep into any component. I also went over some distributed system basics like distributed hashing and how different databases do replication, etc. The biggest help here, though, if I'm honest, was my prior experience - not just systems I'd worked on, but also things other people worked on that I heard about, technical blogs I read and so on. You're not expected to come up with this all from scratch - a lot of smart people have designed a lot of smart things, and by having an idea of what is going on outside my specific area, I was able to borrow those ideas in my interviews.
  I should also say, that as a newgrad, don't worry about this - you're expected to be bad at this :)
• I jotted down some answers to typical behavioural questions, so that I had given them some thought beforehand and wasn't just spitballing in the moment.

Finally, practicing the process of interviewing really helps! If there's one suggestion you take away from this, let it be this one! It's really scary beng evaluated by strangers, so having some experience of this, before the big day, really helps. In my case I was able to do some screens with companies that I wasn't super interested in, but in the past I've gotten friends to interview me. The LC mock interviews were also helpful.

Takeaways

• So. Much. Talking. On the phone. And over zoom. So many recruiters. Every recruiter wants to talk to you multiple times and this can really add up - I tried to move as much of this as possible to email because otherwise I would spend hours every week just chatting to recruiters. I did my best to just not do phonecalls with sourcers - you're gonna have to speak to a recruiter as well from the same company, who will go over the same information. Some of this I could get out of, some of it I couldn't, based on the company.
• You can't cram learn the system design stuff. If you're planning to interview for a senior position and don't have a lot of exposure in your role to a variety of large scale, distributed systems then read eng blogs, etc. In many ways I got these offers based on this sys design knowledge - not the stuff I had done, but the things that I had seen others do and could then apply to the novel questions I was given.
• Practice. So much practice. I failed some of my earlier interviews because of nerves. But because they weren't companies I was super excited to work for, it didn't matter as much. Nerves are a real thing! They make your brain mush.
• Tap your whole network - and then tap their networks. The only interview I got because a recruiter reached out to me first was with ByteDance - all the others I found someone who knew someone who knew someone who worked at one of the companies. This was a lot easier since I now live in the Bay Area, but I did the same when I got my first job out here (and was still in my home country). I'm not good at promoting myself, and so this required stepping out of my comfort zone and asking people to recommend me. Not everyone said yes, but enough people did. This played a massive role in me not feeling a ton of pressure for each interview - if I failed this one, it was okay, I had a backup.
• Negotiate! Everyone says this, but really. One of the best ways to negotiate is by having competing offers ;)
• I asked about inclusion and diversity at each company - maybe it doesn't matter a ton to you, but I find it very telling to watch a manager talk about this. Even more so for some of the more senior leaders. You get an idea of how they respond to difficult questions (because no tech company is doing a good job on this), and how much responsibility they take for the culture on their team.

And then, for any hiring managers that might read this:

• The best interview experiences I had were at Square and Stripe because they had the interviews that best evaluated my actual abilities. I'm sure it's a lot more effort for them to do it this way, but I really do hope that this is the direction future interviews will go - means you get evaluated over a lot more than just whether you can do a LC medium in 45min.

Edit: As requested, preparation suggestions specific to senior eng:
Given that the defining feature of being senior is experience in a particular area, it's likely that not everything I did will be applicable, so take what works and ignore the rest :) Some of it is also probably pretty obvious, but including in case.
The point I made above about time spent on the phone applies triply here. With staff positions, the recruiter will generally assume you also want to talk to potential managers (or the director of the org you're looking at). It's not just about getting th job, but also about finding a role which matches your background. So, there will be a ton of calls before you even get to the interview stage. The nicest bit about interviewing at this level is that they will be trying to sell the company to you, so really do ask the questions you need to to figure out whether you'll be able to be successful in the role.

People stuff:

• Have an answer for what you're looking for in your next role - everyone asks this.
• Have a solid leadership story with as much scope as possible. Generally they're hiring you based on what you've done, not your future potential. This bit is super important - be sure of your narrative, and able to clearly define what you did vs others (whether this be code/design/project management/etc). Ideally have it be something where you came up with the idea, did a significant amount of the project management and where multiple teams were involved. It doesn't have to be something that you owned completely, but it does need to be something where you took significant ambiguity and set direction. For example, in my case, I lead the software side of a broader hardware project. I defined the success metrics, feature set, operational changes, deployment work, etc etc. I didn't design the hardware, or decide on the original goal (which is tough at a FAANG company since they're huge), but I took the goal and then figured out was needed from the teams in my area.
  • Within this, it's really important to show self reflection and insight - what did you struggle with, what do you wish you had done differently, what was the most challenging part, give an example of conflict and how it was resolved, etc.
  • Don't undersell, but equaly, don't oversell. I struggle with self promotion, so it took some practice to start talking about what I did, vs what we, as the team did. The flipside of this is to not overreach. My interviewers, especially the senior management ones, really dug into the specifics. They'll also do a reference check after the fact, so best to not completely make things up :)
  • It is impossible to have gotten everything right - be able to talk about your failures, but, make sure you do so with insight so that you can show growth.
  • Don't talk badly about your coworkers - there is a diplomatic way to frame even the worst transgressions.
  • Because I don't have like 20 years of experience, I don't have a ton of projects that I led at the staff scope, so I would often borrow bits and pieces from other work of mine to answer questions - for example, "provide an example of a time you disagreed about technical direction and how it was resolved" -> this doesn't have to be on a huge project. I was trying to show some range in what I worked on, so would pull answers to things like this from other projects I worked on outside of only the ones I completely led.
• Have stories around mentorship and growing other engineers. This can be one on one, or org wide initiatives. Org wide would be things like programs to improve interview quality, tech talks, mentorship programs, diversity work. Things that demonstrate setting "culture".
• Be able to quanitify the scale of your work - "this tool was used by 75% of engineers", "This handled 50Tb/s of traffic", etc.
• I would say try to demonstrate either technical depth, or breadth. If you have only worked in one area, try find ways to demonstrate how you have exceptional depth in it. If you've worked in a number, use your answers to talk about your work across multiple areas.
• Have some prepared questions for them around org setup, culture, etc.
• You can really guide a lot of these behavioural interviews - show interviewers your best attributes.
• Be friendly!! They have to want to work with you.

Tech stuff:

• You've got to nail system design. You're expected to be able to code, but you're adding value at the system design layer.
• Be able to show technical depth in your area
• Be able to talk about disaster recovery, designing for failure, graceful degredation, etc.
• Know how to write clean code, how to design tests (infra: unit, integration, load, performance, etc; product is likely stuff like a/b testing and so on - I'm very clearly not a product engineer :D )
• Have examples where you led the meta-initaitives in a broader program to reduce risk. These are all the additional process changes that need to happen to get a big change out. So, with my background in infrastructure, this was all the operational parts of releasing something new (deployment, testing, monitoring, alarming, oncall, provisioning, capacity estimates, division of responsibility, etc). All the technical processes to manage people and risk.
• When doing the system design interviews, be able to give the whole system overview before diving in to any specific component. I also got questions here around things like deployment and monitoring (what metrics would you use to check deployment health, how would you pace the deployment, etc), but this may be due to my background.
• Might just be infrastructure: Have some idea around what determines the money stuff, and how to calculate expenses. For example, in infrastructure, this is all around capacity costs. Things like back of the envelope numbers, or, how you would go about deriving them ("in order to be able to correctly estimate capacity needs for our rps, I would run load tests on a single host at 80% utilisation" etc etc etc). I hadn't personally had to do this in my previous roles (which is generally the case at big companies), but I could talk about how I would - this shows awareness of the underlying systems and how they map to capex.
• For FAANG and many others, its expected that you are still doing technical work as a staff eng - so being able to talk about the parts of the system that you directly worked on is a plus.

Edit 2:
System design resources I used:
I really liked this write up: https://github.com/donnemartin/system-design-primer
It has a ton of resources providing an overview and I then used it to jump off into specific areas I wanted to know more about. I'm sure there are also some really great video tutorials, but I'm not a fan of learning via video, so unfortunately no suggestions there :)

It's really easy to be completely overwhelmed in this area, so honestly, I would start with some sort of guide like the one above and then move through it. Pretty much every concept described in the github page above has had some company opensource their solution, normally with a nicely written blog post that explains the rationale and the chosen solution. Try go for breadth before you go for depth.

Something else to be aware of, is that its okay to be stronger in some areas than others. For example, I can talk endlessly about certain areas, but for example, while I know the HTTP verbs, I couldn't tell you the last time I inspected a POST request, because I haven't worked on a webserver in years - and this shows in my sys design interviews - I quickly skip on to the services side of things. Most interviewers will follow where you lead them (as long as it makes sense).

In terms of specific sources, since I was at Facebook, I kept up with a lot of the internal work there which often ended up on the eng blog. I also kept an eye on big new product releases from AWS, since they almost always match a problem AWS had to solve internally. There is often some description of what problem was being solved, and why.
Looking at what companies do wrt disaster recovery is also pretty interesting - looking at how things could fail tells you a lot about how to design for resiliency. Netflix and its chaos monkeys are a great start. Facebook, Google, etc all have robust DR/chaos engineering programs that they blog about.
Something else I can suggest is figuring out why various things become popular, what problem they solve, and how. For example, why docker? What does kubernetes provide? What would you use kafka for? Memcache? Once you understand a bit about some technology, you start to see all the places where it could be used as a solution.

Finally, if you do decide to follow a company specific blog, I would suggest going with a midsize company rather than something like Google. Google is solving problems only Google has. And its solving so many problems that there are tons and tons of topics covered. Smaller companies are solving problems many companies have, and are likely hitting problems you'd need to know in a systems interview (for example, how to improve your loadbalancing vs, say, laying undersea cables like Google or Facebook).

But again, it's really easy to get overwhelmed. Pick a guide, there are tons, and then stick to it as a start. Hope this helps!