I have had a few interviews where the question is asked,

"How does the browser receive data from a web server?"

I feel I can very deeply answer this question, but I feel that in the process of answering this, I am either too long in my answer or lose the interviewer's attention.

What is really expected really as an answer?

I mean I don't like such a potentially deep question. I answered this lightly , because I could tell that the question could lead to a rabbit hole and potentially long answer.

  • This isn't a security question that you've posted, and the interview question isn't a security question either. The question of "how deeply to answer technical questions" is a question better asked on Workplace.SE as this is an intervew skill, but check to see if it's been answered there already.
    – schroeder
    Commented Oct 24, 2022 at 13:45
  • I thought about this, but I wasn't certain that workplace SE would have answered this better. That place tends to be more of ethics and practices of a business rather than answering a technical question.
    – LUser
    Commented Oct 24, 2022 at 15:12
  • 17
    You can always ask them how much detail they want. Interviews are (or at least should be) a conversation, not a Q&A oral exam. Commented Oct 24, 2022 at 19:01
  • 1
    you better ask the interviewer which part of the browser he is interested in and then reply. LIke @jaredSmith said ask before you reply with an answer
    – chendu
    Commented Oct 26, 2022 at 4:46

4 Answers 4


How about:

The web browser parses the URL to extract the protocol, host name, and potentially other information. Browser performs a DNS lookup to get an IP address associated with host name. Browser makes a TCP connection to the target IP address, usually on port 443. If the protocol is HTTPS as usual, browser initiates a TLS connection. A set of cryptographic algorithms is agreed. The server presents its certificate and the parties perform a key exchange to verify its identity and agree a master key. Browser then makes an HTTP request over the TLS channel.

Seems about the right length for an interview question, gives you the opportunity to drop in key words to show knowledge and connect them accurately to show understanding.

This is intended as a guide to what a good answer could look like, rather than something to memorise. Try to think about the underlying principles that make this work.

  • Also shows you're at least reasonably up-to-date, since even ten years ago, it would not have been reasonable to describe HTTPS on port 443 as the "usual" configuration, since there were just as many sites out there using HTTP on port 80. Commented Oct 25, 2022 at 12:56
  • 9
    A good answer to this question isn't a paragraph the person can memorize, it's a set of heuristics about how to know how many sentences long your answer should be, what detail level it's at, how to know if the interviewer wants a longer or shorter answer, how to structure it so you can stop after 4 sentences instead of having to do 20 sentences to get to the "good bit", and so on. Commented Oct 25, 2022 at 13:05
  • 2
    @KateGregory - Yes, you're quite right. This was more intended as a guide to what a good answer could look like, rather than something to memorise. I'll edit to make this clear.
    – paj28
    Commented Oct 25, 2022 at 14:00
  • Nice answer :). I do feel Andrew's comment is a bit revealing though; summarizing well is a skill, but there may well be nuances the interviewer is trying to pick up on.. something that convinces them (sometime subconsciously) that you're "expert", rather than "merely" knowledgable. Commented Oct 25, 2022 at 15:45
  • @KateGregory - I just reread this. You should provide an alternate answer that follows what you suggest, rather than moaning that my answer isn't in your style.
    – paj28
    Commented Oct 31, 2022 at 20:21

You start with "The short answer is ..." (The browser sends an http or https request to the server, and the server sends a reply if it is able to. That's it). And then you ask "Would you like more details, like URLs, VPN, how https works, and so on?"


You start off very broad, and you ask questions about what they'd like additional detail on.


When an interviewer asks what is potentially a very broad question, then (as other answers mention) it should really be about having an ongoing conversation to find out how much detail they want, as well as making sensible inferences about what technical level the interviewer is at and what kind of detail might be most relevant to your role.

For example, an embedded developer might be expected to know the algorithms for TCP/IP handshaking, whereas I'd guess a network engineer is probably expected to talk more about routing. A web developer meanwhile might be expected to talk more about higher-level protocols, such as HTTP requests and responses. I'm none of these things, so I'm only guessing what goes for common sense topics in these fields.

Either way, start off with a short sketch that touches on several aspects, and (if you're capable of going into considerably more detail) then just ask them if they want you to add more detail, and just rinse and repeat until told to stop (or until you can announce that either the explanation is complete, or that you're at the limit of your own understanding).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .