How to pass the interview for software engineering roles in Big Tech

It's an impacted field.

Read architecture books and learn system design from existing success stories and read through their thought process.

Contribute to a large system open source.

There isn't really anything you can otherwise do.

Try to make large systems on your own projects.

I totally agree that at higher levels System Design is required. That's why I have a whole section about System Design in the article. See https://www.lambrospetrou.com/articles/big-tech-software-int...

I describe all the resources I read outside my day job's material. There are a lot of useful engineering blogs you can use, and with 1-2 books you can go very very far in learning the principles.

Once you have the theory, then you just need to practice on brainstorming designs for any kind of app you want. Then, you can verify that with the real implementation, you can pretty much find information about any big-scale famous system online. Or you can do mock interviews with others, but I am not a fan of these personally.

In my experience, reading, and then trying to come up with designs on your own for well-known products will make you ace these interviews after a few months.

Also, during the interview there is no nearly enough time to verify that you have done in the past all the things you will mention. So, if you understand what you are saying, and your design makes sense, you will pass the interview, even if you haven't practiced these things in your day job.

Very few people have real distributed systems experience. Maybe 1% of people who pass system design interviews have ever actually implemented or even worked on such a system.

The nitty gritty of implementing a distributed system is orders of magnitude harder than the high level view of a sys design interview.

What it means is you can just prep for system design like algo. The expectations are not that high. Learn the patterns and common technologies and how they are applied. It almost always comes down to databases and message queues, and the different versions of those. DDIA is the reference book for these interviews.

What you do you mean by junior not existing in Big Tech?

All the Big Tech companies I know regularly hire interns and new grads.

>PS: I know exceptions are everywhere but I'm sure that the quality of the ones who get in vs rejected will be basically the same. It's just a process optimized to minimize false positives, so, only the median will get in, really good ones will be rejected and only maybe a very small fraction of the ones who make it through will be "The real deal".

This has not been my experience. I think the quality of the average engineer I've worked with at FAANG has been higher than elsewhere. For all it's problems, the system seems to at least kind of work.

Actually preparing for system designs is a game these days. I went from dreading them to being really confident with them. My day job had minimal interesting or challenging problems. I am also pretty analytical and quantitative in general (for example I think of system designs as applications of queuing theory) - so questions like "what is the firsts request that will fail and how" actually have theoretical grounding without needing exposure in a day job. Happy to share more. I don't won't to come across as an arrogant prick. I could share how embarrassing I failed at system designs but I could caution against thinking system designs are any magical. Happy to share my path (not easy but IL guarantee it is fun if you like numbers and a pen and paper). Also btw I am talking about preparation for system design interviews. There is still a huge diff between doing well in a 45 min interview and still take years (and tons of mistakes) to build a solid distributed system.

That's an interesting approach, and indeed I have seen it happen. In some companies though, the interviews are very similar and include coding as well even for managers, so might not be a silver bullet.

I do think though that if you are OK being a manager for at least a year, it's a very viable path!

No company is hiring an engineering manager who doesn't have 5+ years of management experience. It's not a role you can just apply for as an IC.

I really doubt you can do that at AWS.

I've tried that, people don't see me as a manager, for them.

Its a different "culture fit" metric than IC. I prefer IC, I've just also done what you're suggesting.

I've ran companies before too, been technical founder a couple times, have done plenty of side projects with remote agencies as well, which turned into companies. I've been "lead" in IC, or been promoted to Engineering Manager. When I'm on the job market and trying engineer manager, I've had comprehensive answers for everything, people don't see me as the manager. I've tried a more social approach as well and a variety of iterations. Nope. They don't see me.

There are fewer management positions than IC roles so this seems like it’s making things harder.

I can't imagine how you would accomplish this. I mean, I'm sure there are companies that hire MBAs to directly manager engineers, but not at any of the companies I've worked. Everywhere I've worked the only way to be an engineering manager is to have 5+ years of experience as an engineer.

I am the author :)

>I can only assume the author has not interviewed many candidates.

I did more than 100 interviews so far.

>I've lost count of how many tenured engineers I've interviewed who could not write basic code or explain basic programming concepts. Things that a practicing programmer would encounter every week.

Where did I say that I agree with this statement. This is what other engineers claim, and as you pointed out being said many times.

I am totally against this claim as well. I do think that those tenured engineers should be interviewed for basic coding skills too. Just last month I had a staff+ engineer not being able to write a DFS...

That part in the article is ironic, hence why I said that I didn't want to make it a discussion about the fact that we have these coding interviews, and to "Get over it!" :)

What we do as software engineers isn't standardized. If you are doing things that have been done before, you are wasting your time.

I think it's a valid suggestion, but where are you getting this from:

> MCAT filters the med school application pool down from 80k to 23k. LSAT filters from 120k down to 40k. Without them, there would be millions of applicants every year.

How could one reliably estimate the number of people deterred from pursuing medical or law school due to the respective standardized tests?

Yeah I thought many times about a standardised interview process. There are pros and cons in such system though. Would the exam be broad or go deep, would it test all kind of coding problems or would there be categories? In a way Big Tech's interview process is this standardised test, but once you go a tier lower, the interview process is a wild west. Much easier questions, and much more conversational interview which introduces a lot more bias and subjectiveness.

In every company I have been, this has been proposed in some form, and the argument is always that the current coding questions approach is a reliable way to filter out a lot of the unwanted candidates, at the cost of also rejecting some very capable engineers. It's an accepted trade-off.

Well, it’s a good thing Amazon’s hiring process managed to filter out someone who could do the job they were hiring for, but not the job they weren’t hiring for. That’s some top notch hiring practices right there.

>2) practice communicating with people that have very thick Indian or Chinese accents. It will also help in general day to day life

Absolutely :) I have that item explicitly in my article, since it happened to me as well being on both sides of the interview process.

It's very unfortunate when communication is problematic accent-wise. And it makes judging difficult as well since you are not focusing on the technical merits alone anymore.

>1) don’t expect only questions relevant to the position.

For this, you might have been unlucky with an inexperienced interviewer...

The actual moral of the story is that FAANG interviews have a lot to do with luck.

A lot of interviewers grill you on stuff that they know a lot about, because how do you interview somebody on stuff you don't know anything about? So, what winds up happening is that you have to keep interviewing until you wind up with a set of interviewers that has a lot of knowledge overlap with yours.

"Embedded" is such a vast, vast field now, it's risky to assume anything isn't included

After working in big tech for a while I'm so used to hearing Indian and Chinese accents that it doesn't faze me. Practice seems like a good idea though maybe easier said than done.

Hoping to see familiar problems isn't the best strategy; it can be stressful. A better idea is to focus on mastering common problem patterns like two-pointer, sliding window, DFS, BFS, and others. With about 20 of these patterns under your belt, you'll be well-prepared for most challenges.