> The system design ones were somehow even more outrageous given that system design is often the deciding factor between a mid/senior level and a staff/principal level engineer. Yet watching the IGotAnOffer video series successively reveals just how formulaic and predictable the response and banter is designed to be.
Oh my god, yes. Every architectural interview I’ve had in the last five years has been a rehashing of the same concepts, pulled straight out of Designing Data Intensive Applications. Anyone who has read that book once or twice can easily pass. Half the interviewers even use the Twitter example presented in the book, with a few arbitrary extra requirements tacked on.
I think the root of the problem is actually an org design problem.
Big companies want consistency in their process and their hires. There's a lot of benefits if you can create a Google type hiring pipeline you're just constantly interviewing candidates and you worry about where they go once they've passed the interview, like:
- Since all candidates at the same level are passing essentially the same interview you can move people from team to team easier. You reduce the risk of a team with lower standards causing you problems when their engineers are moved to other places in the company. You know that most of your hires have a certain consistency in their skills. This makes things like reorgs a lot easier.
- Your recruiters and hiring managers save time because in most cases they don't need to meet to set up unique hiring pipelines per team. You just have one big hiring pipeline and teams with open spots only step in at the last minute.
- You reduce the risk of being sued for bias or discrimination. If interviewers are just pulling from a bank of questions that are somewhat equal it's hard for a candidate to make a case that they were singled out and given a tougher question because of their identity.
The problem with that is that consistency breeds predictability. The only way to get a big pool of interview questions that are about the same difficulty is by repeating the same patterns between questions. Once candidates know those patterns, candidates can just focus their studying on that and the interview just boils down to pattern matching.
I think it would help if companies approached system design interviews less as an opportunity for the candidate to show off all of the fancy performance optimizations they know and more as an opportunity to demonstrate that they can actually design and lead implementation of a system.
That is to say, real world system design is more about understanding that most systems don't need most of the stuff in Designing Data Intensive Applications and avoiding premature optimization.
There's very little room for deviation as well because it is so formulaic. Present a novel and interesting system? It may not be realistically solvable in a 30-60 minute session to a satisfying degree because the candidate doesn't have familiarity.
From the candidate side, you can take a risk and make it more interesting by presenting more novel solutions, but the interviewer might be looking for very specific response patterns; "signaling" of a sort. So both sides just stick to a narrow range of scenarios and responses.
Once you've done one or two, it's hard to see how you couldn't do every other one after it.
Oh my god, yes. Every architectural interview I’ve had in the last five years has been a rehashing of the same concepts, pulled straight out of Designing Data Intensive Applications. Anyone who has read that book once or twice can easily pass. Half the interviewers even use the Twitter example presented in the book, with a few arbitrary extra requirements tacked on.