This is an attempt at collaboratively building a tree to answer the famous question
"What happens when you type google.com into your browser's address box and press enter?"
Answering with a general overview, and then optionally going into more detail based on feedback from the person you're explaining it to is the best way to tackle this question. And this is also a pretty important life skill for an engineer : going into the weeds immediately is not great when you're communicating with people at a different skill level than yourself.
That's why this "answer" focus on building a tree. Instead of having a linear list of micro bullet points, which can easily overwhelm the reader, the goal is provide a way to explore the answer at your chosen depth depending on your needs.
The repo is meant to be browsed easily. The root is here.
I have been asked this questions in interviews, and I have asked it multiple times. I love it because you get to test technical knowledge and people skills at the same time. You get to know :
- what candidates know
- General understanding of the broad picture of the Internet and computers : have they done at least some looking into how the stack works enough to discuss it intelligently ? Mind the blind spots : does they rush through a specific part, not even mentioning other parts ?
- Which part they go into detail on is a pretty good indication where their strengths lie. Going deeper and deeper is an easy way to identify the edge of the technical knowledge of the interviewee : how sharp are there skills on the foundation of the Internet ?
- how they communicate it
- Ability to question the question, and adapt the level of description to the interviewer. Will they be confused about what level of detail should be supplied ?
- Can they summarize a technical issue in a comprehensible way for the audience ? Are they are capable of breaking down and explaining a complex piece of technology with several interacting parts ?
- and how they react when they don't know
- Personally, when I ask this question in interview, I make sure I reach at least one time a depth where the candidate has to say "I don't know how that part works". If someone knows what they don't know, they will know when to ask questions, but if they just make stuff up to try to make themselves sound more knowledgeable, I don't know if I could ever trust their knowledge or judgment because it could be based on them just covering up a lack of knowledge about something.
There is no "right" answer to the question, because there is no "right" level of detail. We can keep going infinitely more into detail, explaining each step in more and more detail. Also keep in mind that if I wanted a processor engineer, I'd be looking for a different answer than a web developer, or a networking guy, etc. Essentially anyone involved in the modern world of IT has to be able to answer something they're good at - and more importantly, admit the parts they don't understand.
Another thing that I really like about it is that the question provides the context to start a real conversation with the interviewee. When he stalls, it's easy to ask questions to go deeper, or ask questions to move to another branch, or invite him to make assumptions about how things work.
- original idea from https://github.com/alex/what-happens-when/blob/master/README.rst
- hn discussion on original repo : https://news.ycombinator.com/item?id=8902105
Make this answer even better, there are still lots of room for improvements ! Before submitting your pull request, make sure to read the contribution guidelines.