Oh shit, this one is really nice. I’ll add that one to the list.

I like that, but does the "to the moment the page refereshes" part mean it'd definitely not a SPA?

Good question - and one that tells me something. You're familiar with modern front-end development and that's something we can dig into. Why would you want to avoid full page refresh? When would I use a SPA versus more traditional SSR? What about serving something mostly static with progressive enhancement? What frameworks might you consider for developing such a SPA? Which have you worked with in the past? What did you like about them? Any you're looking to work with in the future? How do these frameworks work - i.e. are you someone that hacks on them and is concerned with shadow DOM and optimizing diffs and re-rendering and data binding...

That's why I really like this question - it's just such a cool jumping off point.

You ask those questions and we're not getting through the rest of the answer :P

This is very nice indeed. I should mock-interview someone using it.

It's not a good question. It's both famous, so people already know how to game it, and it's overwhelming. I do not want to have to give an entire lecture, which essentially 3+ different university courses condensed into one, on the spot to show off my street cred.

Overwhelming is one way to look at it. Another is that it’s an opportunity to demonstrate both breadth by hitting the keywords and also depth by diving into whichever part you know best.

Any candidate who made it to an interview should be able to rattle off a bunch of stuff. An excellent candidate will have more depth than the interviewer on some portions.

The interviewer’s first job is to decide whether the candidate has a baseline-acceptable level of knowledge (harsh but true, good fakers make it this far). This question is fine but not great for that for the reasons you mentioned. However, it is best to go in assuming they do.

So then the interviewer’s next job is to decide if they are going to be a good teammate. Google is rife with nerds trying to out-nerd each other, finding out how that goes in the interview is an explicit goal. A great interview on this question will end up in a moderately deep technical discussion of some aspect where both the candidate and interviewer are knowledgeable, much like a discussion you would want to have with your teammate at work. And that is why this is a decent question, in my opinion.

It was great until you mentioned it. Now it's just another Leetcode-like study guide memorization task and performance art.

if the interviewer is truly knowledgeable they can drill down into certain areas, or ask questions about the areas that weren't covered in the answer. i.e. if the answer was mainly browser DOM dynamics, ask about DNS and tcp/ip routing.

of course, the whole point of the question is nobody you're likely to interview can fully answer it. maybe someone like jim keller could but is someone like him really going to know about css stuff? maybe, maybe not.

If a candidate is able to memorize and explain all of that then they are a good candidate.

Possibly. Though maybe memorizing is where their skill development is focused (like with Leetcode). Yet they'll test better than a candidate who could tell you 50% of that, off-the-cuff, based on their understanding and insights from experience. The latter candidate is probably much stronger at the job than the memorize-the-test candidate.

A twist on the old “what happens when you type google.com into your address bar and press enter” question. If I were answering I’d talk about a couple areas I can adapt from the repo below, and save some time to also talk about API services and DBs to differentiate it from the usual answer. It is indeed a fun question!

https://github.com/alex/what-happens-when