Interviewee: Long answer with novice RDBMS choices.
Interviewer(implicitly): I will judge you based on how you can "Problem Solve" many-many conundrum.
Interviewee: Use Cache, scaling, edge nodes, kafka because....
....
HIRED
....
Interviewee spends first 6 months writing a test framework to automatically run tests of deployment of an internal tool that runs python ingestion pipeline. Next 6 months figuring out how to help user add type hints to IDE for pipelines to help catch errors faster and how to roll it out to 100+ ICs in the company. Sadly fails.
Never ever writes a line of code to make "twitter", learns a ton on how to work with people.
Not sure what the point is here, but ... in my experience as the hiring manager I haven't seen huge success in testing a candidate whether they can do the exact thing they will be doing in the first 6 months (in software engineering).
I had better results in asking questions that bias towards a certain set of behavior traits (yes, this has other long-term problems) and not certain skills.
I understand that some candidates don't like it, because they are obviously good at something and want to be asked questions in that field. But ... I already know you are good at it because you said it on the CV, so i'm not wasting time with that (yes, if you are a good liar it takes us longer to find out).
And the culture is also promoting gameable interviews that tell one absolutely nothing to the interviewee about a candidate except that he has managed to parrot an answer from a online guide or DDIA.
I am sure a skilled interviewee can find the difference between a guy who knows his System design from one that does not. But its paradoxical to have a guide prepare someone on so many topics of which only 1% is what one person has done in their life.
I still ask to design Twitter, but make it clear that it's about the process, and follow ups are driven by where the candidate leads to.
The material from OP won't prepare you for systems design interview (witch is also your point?). Only experience will, so we measure experience and leadership.
Juniors can apply to systems design openings and will be interviewed, but they end up as generic SWEs if hired. If one thinks one can work on distributed systems coming out of university you will have a hard time interviewing or not like it.
Interviewee: Long answer with novice RDBMS choices.
Interviewer(implicitly): I will judge you based on how you can "Problem Solve" many-many conundrum.
Interviewee: Use Cache, scaling, edge nodes, kafka because....
....
HIRED
....
Interviewee spends first 6 months writing a test framework to automatically run tests of deployment of an internal tool that runs python ingestion pipeline. Next 6 months figuring out how to help user add type hints to IDE for pipelines to help catch errors faster and how to roll it out to 100+ ICs in the company. Sadly fails.
Never ever writes a line of code to make "twitter", learns a ton on how to work with people.
....
Interviews again: "How do you design twitter"?