Not my experience at all: ALL levels, besides maybe junior which kind of doesn't really exist in Big Tech, require system design, so I can't really relate to this.
Algorithms are usually about specifics of what the company itself does, so expect graph traversals, networking, file system stuff etc, disguised as a puzzle depending on the company. Nobody will ask you about "generic algorithm questions" and actually the "topics" are quite narrow.
What I'd like to know and see written down is how you truly prepare for system design when you DON'T HAVE or CAN'T GET experience with large scale systems at your DAYJOB.
The chasm here is that when competition is other 20 engineers who just memorize things, even if their actual relevant skills are objectively worse than yours in practice, you'll never, ever get the job. It's a very tough game and I admit there is real skill in knowing how to game the system :) it is what it is.
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".
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.
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.
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.
>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.
Alternative: apply for an engineering manager position. The tech part is quite easy (none or very few easy leetcode stuff). After some time (can be e.g. a couple of months) you can transition to software engineering position (same level) without any extra tech interviews.
I have actually seen several colleagues jumping into EM roles (Engineering Manager) with just a year of experience being a manager, or even from just being a team lead (technical leader, not manager).
In companies that have the first level of management at the same seniority level as the Senior Engineer, it's very doable.
At Amazon you could become an EM1 by switching internally from SDE2 (L4 at Google/Meta).
Also, in other companies like Datadog, Cloudflare, the first level of EM (used to be called Team Lead) is parallel to Senior Engineers.
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'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.
Can you elaborate on what you mean by this? Do they focus more on your IC experience and reject with the excuse that you don't have a lot of years being a people manager? Or did you mean something else?
I don’t know what they focus on, I’ve had many assumptions to A/B test over many interviews
I have a lot of experience people managing though in successful projects and teams! I guess I never found the Cracking the Engineering Manager Interview book
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!
"Why would you ever put a tenured engineer, writing code for years, sometimes decades, through a 40-minute process writing code in a collaboration doc or a whiteboard…"
This keeps coming up, and I can only assume the author has not interviewed many candidates.
I've interviewed hundreds of candidates. 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.
A hiring manager naive enough to waive coding tests will almost certainly hire a low performer who will hold back their team.
>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!" :)
Maybe there should be a standardized test for software engineers like the LSAT or MCAT. there are just too many software students every year now to filter the top 200k or so out of 2 million using interviews. Who has the time or interest for that ? we need one to track progress in LLM’s anyway. humaneval is weak.
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 long can we keep relying on high school level tests that prefilter into computer majors for college. We need a post college test.
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.
According to https://survey.stackoverflow.co/2023/#section-developer-role... , about 58% of developers are web front-end, back-end, or full stack. That's probably an undercount since their survey includes non-practitioner roles such as management, students, and QA. All of those will be using more or less the same frameworks, libraries, and other software to target the same browsers, database engines, operating systems, etc. Doesn't seem like that much of a stretch to be able to write a test that evaluates proficiency in the common underlying concepts used across web software.
> What we do as software engineers isn't standardized. If you are doing things that have been done before, you are wasting your time.
At the same time, this type of thinking is what results in engineers wasting time and money re-inventing the wheel, on things that usually have no business value. Just look at how much time and money was wasted at Uber reinventing simple technology solutions.
you can absolutely create a standard test with predicting power on success as a software engineer. Real Law isn’t standardized either, neither is real medicine. They are partly art as well.
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?
There are a 140k premed first year college students. That number itself would be larger without the MCAT hanging at the end of the road, if med schools relied on haphazard interviews alone without the MCAT.
There are 5 million college students per year, a lot more of them would take a shot at law school and med school, if it wasn’t for MCAT and LSAT.
You can confirm these numbers, they are public, and gathered annually by various administrative bodies involved in the standardized tests and credentialling of the professional schools.
I don't doubt that there are 140k premed undergrads or x million college students.
I doubt that there is any reliable estimate of how many people would apply for med school or law school BUT FOR their having to take a standardized test.
All I am saying is there should be some scalable if crude method of quickly ranking new software engineers by aptitude as a pre filter for interviews as there is for doctors and lawyers. it’s just an opinion.
Final interview at Amazon for embedded position: all previous interviews were great. They threw out a niche optimization problem for web development which I couldn’t do in 30min. I fumbled big time. The interviewer had such a thick accent I found it impossible to communicate.
Moral: 1) don’t expect only questions relevant to the position.
2) practice communicating with people that have very thick Indian or Chinese accents. It will also help in general day to day life
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.
I'm ESL myself, and I sympathize because I also don't find it easy always to communicate with ESL people from yet other native languages. But as for the niche optimization problem, don't you think that the Amazon folks would say: this candidate was not able to think on their feet and think outside of the box, when given a non-standard problem? I think hiring teams over-estimate how far they can push the envelope on that in an interview, but I find it a bit one-sided to assume that the question was outside of the job they were hiring for or that it was a malicious question.
I’m sure they have a lot of rationalizations and just default inertia around various practices. Could the interviewer successfully answer a niche question proposed by the interviewee? If they can’t, should they forfeit their job to the person they’re interviewing?
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.
I would say that luck in FAANG interviews is much lower than the average tech company. At least in my experience. Don't get me wrong, there is luck involved, and it's a big part of the interview process.
But, at least, you have standardised pools of coding questions, standardised pools of system design questions, and a standardised feedback form.
The interviewer varies a lot though... And makes all the difference when you have an inexperienced one, or someone that doesn't care.
> The interviewer varies a lot though... And makes all the difference when you have an inexperienced one, or someone that doesn't care.
I believe this is likely the main point being made about luck - be unlucky enough to hit up an inexperienced interviewer and all the time spent preparing as in the linked OP is up in smoke.
Not sure if it counts as an average tech company, but in terms of non-FAANG I think startups and smaller companies can end up relying less on luck. There is more time and motivation to truly flesh out candidates, maybe giving non-interview coding tasks and such to balance out interviews. At a FAANG if there was an issue because of an inexperienced interviewer, again you need luck for a recruiter or committee to attempt a save among all the other applicants.
>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...
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.
I agree with this approach. I cannot memorize solutions at all. I can however learn a few techniques and try to pattern match a given problem into those techniques.
I do admire folks that can memorize more than a few tens of problems though. It's a skill on its own!
I think everybody who intends to interview for a software engineer at a major company should, at least, have memorized a small collection of algorithms and data structures. For example, linked list, hash table, DFS and BFS, simple sorting. That means being able to explain the data structure with pictures or words, explain the basics of computational complexity, and write down the basic implementation in your language of choice.
If you don't bang out the right answers to those off the top of your head, all the programming interviews are going to be painful.
I have never implemented a linked list, a hash table, or a sort in $DAYJOB. I did them in school of course. After that I used what my development framework and libraries provided.
Yes, but would you forgo a well paying job because the interviewers asked you questions that weren't things you did as a day job?
The employers need metrics, fairly standard ones, to filter out unqualified employees and these sorts of simple algorithms and data structures are the least bad ones.
Where I complain is when the interviewer explains "to solve this problem, you need to think of them as virtual ants that can pass through each other" (yes this was actually what my interviewer said for https://leetcode.com/problems/last-moment-before-all-ants-fa...).
I'm guessing some do, the kinds of employers who attract a lot of applicants who misrepresent their education and experience.
I have never been asked to write code in a job interview. I guess I've been fortunate to find employers who look at my resume and talk to me as a person not a metric.
You generally have to use them, not implement them. Though a linked list is so simple that I think anyone calling themselves a programmer should be able to do it without any particular preparation.
>For example, linked list, hash table, DFS and BFS, simple sorting.
These are a given. You should know these.
When I said I cannot memorize solutions, I refer to memorizing solutions to specific Leetcode problems. Doing that for 1-2 problems per main area is doable, but anything more than that is quite hard.
True although maybe doing the top N problems for the company is a shortcut there. No point in spending a lot of time on a type of problem they will never ask.
What I'd like to know and see written down is how you truly prepare for system design when you DON'T HAVE or CAN'T GET experience with large scale systems at your DAYJOB. The chasm here is that when competition is other 20 engineers who just memorize things, even if their actual relevant skills are objectively worse than yours in practice, you'll never, ever get the job. It's a very tough game and I admit there is real skill in knowing how to game the system :) it is what it is.
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".