The URL question is a really good one though. You should absolutely understand every step of that process if you're working on web applications. The database one is weird. You don't need to know how to create a good database system yourself in order to effectively use one, I think. Neither do you need to know how to make a web browser to know how HTTP requests work.
Every step? Keyboard interrupts and the browser going from DOM to OS drawing APIs included? ;)
Many of these questions are very vaguely scoped which gives the confident and familiar plenty of room to show how clever they are, but also makes it more intimidating for those who haven't seen them before.
Or, to put it another way, the linked site looks like a great way to make yourself look like you have a junior-to-mid-level understanding of a lot of different areas. But the process it's optimizing for starts to break down the more senior a developer you either (a) are or (b) are trying to hire.
If it's a job to work on a haptic feedback system, they may very well want to plumb your understanding of when interrupts fire, without prompting for canned answers.
If you're interviewing for a front end position, you can make a nod to interrupts and continue on with BGP, ARP, DNS, TCP, IP, routers, etc. If you want to show your knowledge of security you could mention heartbleed, poodle, or even say why this isn't vulnerable to shellshock. An overview will take a minute, and the interviewer will follow up with more targeted questions if needed. It's a chance for the candidate to shine.
I think it's worth being aware that the more open-ended you make the question, the more you might freeze a less-practiced-at-interviewing candidate on not knowing where to start.
I'm always ready when asking something very open ended to follow up after 15 seconds or so to say "let's talk about [area X] first." For URLs, maybe this is "let's talk about what the actual network request, if you sniffed the traffic, looks like."
You deal with BGP and ARP as often in frontend as you do with hardware interrupts.
Heartbleed and co. may or may not be your concern depending how much that frontend is into devops.
Heartbleed should be understood by frontend devs. In 2017 there is a minimum set of knowledge that frontend devs really need to have. That includes pki, client and server certificates, routing, network caching, and a whole host of other topics. Layers of the stack interoperate, and lack of knowledge of the stack leads to security vulnerabilities.
Good first follow up question would be "I am typing this URL on the mechanical keyboard, bluetooth keyboard or touchscreen?" I think the whole time for the interview could be used to discuss what happens inside the keyboard without even reaching the OS :)
You should absolutely understand every step of that process if you're working on web applications.
"Every step?" Not at all true, in my experience.
What you need is a reasonable sense for the breadth and depth of the topic -- which quickly reveals itself to be far broader and deeper than what most engineers (including many very capable people I know) can hope to "absolutely understand every step of". And the ability to drill down (and go down rabbit holes) when needed. Combined with the experience of actually having gone down more than a few (and having from relatively unscathed, eventually).
In fact, if anything, your observation isn't just overstated - it actually misses the point of what makes some of the most effective people as effective as they are: their ability to manage complexity, and in particular, their ability to (reasonably) "connect the dots" in a complex system despite not "absolutely" knowing, at every level of detail, how every component in that system works.
Mind you, for the right value of "reasonably". It's when knowing when their level of understanding, while imperfect, is still good enough to solve the problem at hand - and when it isn't - is that makes these people so effective.
While that's mostly true, to use a db efficiently you need to have a bit of an idea of what it does inside.
I don't see that question as being any different really. They're both just ways of guiding a conversation around the area we work in to gauge what candidates know / are interested in.
Personally, I've poked around in Postgres a bit because I find it interesting. And having deeper knowledge means that when you're about about to add a new not null column with a default value to a massive table you can stop and reason through how you're about to shoot yourself in the face :-)
To use a db efficiently you need to have a bit of an idea of what it does inside.
You need to have a bit of an idea, sure.
But in order to give any kind of a meaningful answer to the question, you need to have not just a "bit of" an idea, but in act, a deeply solid and intuitive idea. Either that or -- crib the answer from websites like these, know that it's one of the top 30 questions you're likely to be asked.
Which, very sadly, is exactly what the modern interview process (greatly) incentives people to do, these days.
Don't get me wrong - it's not a question I'd ask myself, but I think you'd get some interesting answers. I'm fairly sure with that starting question I'd be able to have a conversation that gave me a pretty good idea about how well someone knew databases.
Do they talk about tables? What about indexes? How about sql? Do they ask enquire about the requirements / data model?
> Do they talk about tables? What about indexes? How about sql?
Interesting, because as soon as I got over the "why the hell do you want to create a new DBMS?" question, my first thought was about filesystems. I haven't digged into any DBMS to look at, but all those you point look so easy when compared to atomic data writing...
If someone started with 'How would you write a database?', I would just talk about simple csv reader n writer with no other promises and be done with it. Everything else is a feature.
"Meaningful" in an interview question does not have to be "correct". These questions can be used to evaluate the thought process, rather than for "ha! Wrong answer!".
Questions are not inherently bad. It's how the interviewer interprets the answer, and whether it's used as a gateway to a discussion or a one way q&a session.
> The database one is weird. You don't need to know how to create a good database system yourself in order to effectively use one, I think.
If your default answer is "Just use PostgreSQL until something screams at us that we shouldn't" then you are correct, you don't need to know about database systems.
Yet, these will be the same people screaming to use <flavoroftheweekQL> instead just using PostgreSQL.
