"A charming story which explains how something as apparently simple as a pencil is in fact the product of a very complex economic process based upon the division of labor, international trade, and comparative advantage."
I ask this question from time to time and look for different responses depending on the type of candidate. When I ask an engineer, I am looking to see if they can grasp the problem space and ask clarifying questions about what I'm looking for. When I'm interviewing for an engineering manager I am looking to see if they can grasp the problem space and ask clarifying questions about what I'm looking for. Since I tend to work on technical products, when I interview a product manager I tend to look for...
So much of the engineering mindset jumps to solutions instead of clarifying problems. I'm guilty of this constantly.
The trouble with doing this in an artificial situation like an interview is that you're leaving the candidate to guess your purpose.
If they correctly guess that what you mean is "please engage in a simulation of a planning conversation, based on this arbitrary prompt", they'll do well.
But if they guess that you mean "please use this arbitrary prompt as an opportunity to demonstrate the depth of your technical knowledge", they'll do poorly (they're unlikely to ask clarifying questions, because that would look the same as stalling to disguise the shallowness of their knowledge).
Happened to me recently. I had no idea what the person wanted.
Turns out this was the core problem for me.
I actually care about customer acquisition and marketing strategies. Product positioning is important to me and it deeply effects how the product is designed. The aspects are a conversation, not a dictation and battle between departments.
Business and marketing is how you wrap and present your technical achievements to communicate their value to the public. If this isn't part of the gestalt, then we're just a scattered swarm. Anyway, yeah, passion.
A company that thinks there should be 10 people and 500 miles between these things and who actually builds the thing isn't right for me. (Apple for instance)
This is how companies come out with spastic messes that only sell because of the existing momentum of the brand.
I would be eternally frustrated that not only me, but everyone else is in these stovepipes.
So that flaw, I realized IS the purpose. They aren't testing knowledge as much as boundaries.
It's Designed so they don't accidentally hire otherwise technically competent people who want to bombthrow their administrative apparatuses
Believe it or not, the last couple interviews I did, I just came out and asked for, and got, this level of clarification as to what they wanted here. Some companies solve their problems differently, value different characteristics, and so run their interviews differently, and in my (admittedly limited) experience, it's not a faux pas to ask.
A few employers ago, giving a "best guess" rather than admitting you don't know the answer to a question was an instant no-hire. They wanted to be sure that you were sure when you put an idea out there without qualification, and so it was with the day-to-day SRE-ish work where short outages caused by speculative changes that weren't fully understood were wildly expensive events.
At my most recent one, I was actually encouraged to speculate if I didn't know the answer to a tech question, or was asked why I answered what I did if the answer was wrong; they were more interested in my thought process than the end result, even if the end result wasn't technically correct.
> A few employers ago, giving a "best guess" rather than admitting you don't know the answer to a question was an instant no-hire.
and this:
> At my most recent one, I was actually encouraged to speculate if I didn't know the answer to a tech question
aren't incongruous to me. In my interviews, I lay out two explicit expectations for the candidate upfront:
1. Please don't bullshit an answer. Confidently incorrect is considered a red flag.
2. The interview is designed to find the ceiling on your certainty and knowledge, and to see how you deal with ambiguity thereafter.
I encourage candidates to guess; I just want them to make it very explicit when they're guessing, and demonstrate self-awareness in doing so.
As ever, a lot of interview problems on both sides of the table are resolved with more communication. It is good to set explicit expectations for candidates throughout the process, and to revisit particular expectations in the first two to three minutes of an interview.
Most companies do have pathologically bad interview practices. The usual thing it to cargo cult off of other companies interview practices or be based off of some idea that has been seen before.
> (they're unlikely to ask clarifying questions, because that would look the same as stalling to disguise the shallowness of their knowledge)
This feels backwards to me. If you have comprehensive knowledge, you almost have to narrow down the question!
Or just talk continually until you've exhausted every single detail of every single aspect. The latter is rarely going to be what you want to do.
There's a level of "this is also a test of your communications skills" in every interview question, and it's a valuable thing to look for. So if you don't treat it as a 2-way street... you probably should.
They might, for example, decide to demonstrate one aspect of their communication skills without asking clarifying questions by showing that they can, on the fly, produce a high-level summary of what happens when you load a URL followed by orderly expansions of each of the steps involved in increasing levels of detail.
I've been listening to people expound their theories of interviewing for decades now, and very often they have some pet idea which involves asking the candidate for something and then trying to deduce information indirectly from how they interpret the request.
I think these theories are pretty much all bad ideas, because what the candidate is actually doing is trying to guess what the interviewer wants to hear.
A lot of what you're describing is better solved by training interviewers on a standardized process, and having both the recruiter and interviewer set explicit expectations around communication. It's true there are good and bad interview questions, but candidates should be encouraged to ask clarifying questions. To alleviate a candidate's fears about doing so, this encouragement should be made explicit throughout the hiring process.
If you're guilty of something constantly that generates poor results in interviews, why on Earth are you using it as part of your interview screen? I agree: this is a pessimizing question. What's the point of a process that sets candidates up to fail? You can do the opposite thing: set a high bar, and then have a process that does everything it can to set candidates up to succeed.
Certainly. I like to have the candidate ask follow ups like, are you interested in the networking aspects? the brower's behaviors? the way the website handles the request? all of these above?
If I phrased the question slightly differently, engineers would have a very different reaction.
Q: Can you write a test for me that demonstrates I can load a URL successfully?
That could drive the engineer down a different mode of thought.
Business stakeholders won't ask for a requirement to implement a test, and the engineer needs to translate the business request into an engineering solution.
From what I've seen, different levels of experience in engineer will have different responses and illustrate for me where they are in the engineering journey. A young engineer, perhaps a new college grad or intern, will tend to react to this with a very open mind and lean on their recent academic background, showing excitement with the question and identifying the challenges in it. They usually do pretty well.
The mid career programmer often stumbles. They want to show the expertise so latch on to the part of the problem they are most familiar with do show technical prowess. They can often lose the forest for the trees.
The senior engineer, will want to know why you're asking and what you're trying to accomplish. Perhaps I'm looking to optimize one part of the problem, perhaps make a step more resilient, more extensible, etc. They will want to know why this question is important for the problems at hand, and hopefully they'll ask about that directly!
This is great. It's critical to bucket engineers into levels with a checklist like this. Are they eager to explore every corner of the problem, from networking to the browser backend. But not in too great detail - not focusing on one topic too much. But you also don't want them talking too much - a great engineer asks questions as much as provides answers.
For example, what does "load" mean? Type it into a browser url bar and press enter? Or just what happens when you press enter (excluding the typing)? Via curl? Or does load refer to just a single HTTP request?
> So much of the engineering mindset jumps to solutions instead of clarifying problems. I'm guilty of this constantly.
This is because it's easier to rely on knowledge, but it takes extra work to develop understanding.
It's also a culture issue. A close friend of mine works for a web dev agency. Numerous times she's told me how they're discouraged from asking questions. They're told they are experts and experts have _all_ the answers.
Nearly as often I hear stories about something going sideways because knowledge isn't enough, they're short on the necessary understanding.
Despite the pattern, the leadership doesn't change the culture.
Also in the interview - you expect the interviewee to answer what you are expecting them to answer - instead of acknowledging/accepting their point of view. Are these expectations playing any role in your observations?
Reminds me of when Richard Feynman analysed the question of “how do magnets work?”. There are so many levels to it, coupled with assumed knowledge, that the question itself is shown to be improperly bounded.
I don't find the video fascinating, quite the opposite actually. Richard Feynman could have just explained the electrical force and left out the rest. When someone asks, `why does x work`, its a sign that they are curious and ready to explore and learn. Its an opportunity to teach and educate.
The whole video (to his credit, Richard did explain the concept well) focuses on how little the questioner know. It is a little belittling. If someone talked like that to me I'd have gone home and accepted the fact that I just would never understand electromagnetism and moved on.
A better approach instead of actually capitalizing on this curiosity and teaching the questioner, giving them just a bit more than the normally accepted answer so the curiosity lives on.
I think in this example Feynman was using the question to illustrate the levels of complexity in answering a scientific question. If you watch his actual lectures, Feynman does break the concepts down in order to teach them.
Also, documentaries and popular science books tend to dumb down and over simplify theories to such an extent, such as by removing all mathematics, that they just become either wrong, inaccurate, or misleading. I think it was Einstein which said make things as simple as possible, but not simpler.
I find I run into similar discussions whenever a beginner programmer decides they want to capture input from the arrow keys.
They've worked through the bog standard Python tutorials using input() to capture from stdin, so it should be trivial to design a simple game that uses the arrow keys right? And suddenly this gulf of complexity opens up of event polling, keycodes, integrating third party modules, and they're left wondering why moving one key over on the keyboard is so hard.
You use a game library for this and then it becomes as simple as pushing a key handler onto the event loop and usually the keycodes are already processed for you as well. I don't get the false dilemma people are creating that somehow this is complicated or that people who use the easy way are less knowledgable than others. If you make a game engine from scratch by yourself it's going to be a logical disaster, whether you've learned c++ or python.
Yeah, it's surprisingly simple. It took little time with a game library to get the key polling to work. I was experimenting with chorded keyboard ideas back then.
Having never really had a needed to do this I'm a little confused -- isn't this just a matter of putting the tty into cbreak or raw mode and then just reading keys from stdin? Like keycodes are annoying but "special keys have this weird text representation, here's a table" doesn't seem like a huge gap to cross.
> putting the tty into cbreak or raw mode and then just reading keys from stdin
You're saying this like most beginners even have an idea what a tty is.
An anecdote: When I wrote my first C++ program that reads an input (using `cin`, hello-world style), I immediately wondered how to read single keys including arrow keys. The book I was following had nothing about this. I don't remember the exact details but a bit of Internet search got me to `conio.h` (I was using Dev-C++ on Windows) which did work. But getting it to work was so confusing to me at the time. And I didn't even get to understand what it's actually doing under the hood.
I imagine it would be a bit easier in Python given the right libraries, but the dependency management probably adds to the complexity for a beginner.
For games, I usually want to handle at the level of keydown and keyup rather than keystrokes.
What’s the keystroke for right-arrow, spacebar, left-shift, and W all being held down?
(Think of an Asteroids arcade game where w is thrust, spacebar is fire, left-shift is shields, and right arrow is rotate. Those are up/down, not strokes, that the player is giving you.)
For games you also have to decipher what a keystroke should do physics wise which isn’t always simple, ie acceleration and deceleration, including what happens when multiple arrows are held down. You now are polling multiple events concurrently and processing them outside of that loop. And so on and so on.
Interesting, but couldn't you ask this of any existing technology with years of development and realize you don't know how we arrived at a function we take for granted?
What happens when you press the accelerator on your car?
Indeed. I have realized 2 things: First, technical specialization is increasingly more fine-grained; second, assumptions that anything outside of the specialization will magically just work. To extend your example, 30 years ago you could easily find someone who understood the whole chain...from the pedal all the way to the rubber on the road. Today? the pedal itself likely has a microcontroller in it... designed by a pedal expert, who knows what the various I/O requirements are and has little or no concern with what the car actually does. Probably leads to better pedal designs, but you need an army of people to tell you why the car might not move.
"Thing Explainer" and "What If" are my current coffee table books actually, hahaha, so spot on with the recommendation. I want a second copy of Thing Explainer because my friends have flipped through it so much.
> What happens when you press the accelerator on your car?
No single automotive engineer can answer that question to the level of detail that the original post wants to approach. A car is a collection of separately engineered mechanical devices meeting some power/torque/thermal requirements, electronic units which, to a mechanical engineer are essentially black boxes with inputs and outputs. Abstraction is in every field of engineering and it helps people reason about a complex system in terms of abstract interconnected parts, not in terms of bits, bytes, cogs or bearings.
In a similar vein, a web developer, a browser developer, a kernel developer, a network driver developer each use different levels of abstraction and paradigms in order to achieve their thing.
There is another way of asking this question: "Someone types the URL of your application in their browser and doesn't get the application page. How do you figure out what went wrong?"
I was given this as an interview question once, it was fun. I was told to go into “as much breadth and depth as possible” but I did get stopped a couple times when I started talking about things like debouncing.
I've asked this question a number of times in interviews. Sadly, not one person has ever talked about debouncing. I think I would've instantly hired the person, if they talked about debouncing :P
To clarify, I would ask this question as a wrap up, a sort of final probe of depth test. If they don't go into much detail, no big deal. If they were good in the rest of the interview, they'd still get hired. If they were good elsewhere but also went into depth on this question, then it really boosts their likeliness of getting hired. I find that people who are curious about how things work, especially when it is outside of their main domain, are usually people interesting to work with.
The Art of Electronics has a good section on debouncing switches. There are various analog and digital ways of doing it, from R-C smoothing to latches to debounce ICs to microcontrollers.
If you want a thoroughly obsolete look at debouncing, I got a debouncing module from an IBM 705 computer (1954). This module was built from 8 vacuum tubes and a pile of resistors and other components. I powered it up with an inconvenient set of voltages (+140V, -60V, -130V) and actually got it to work: http://www.righto.com/2018/01/ibm-mainframe-tube-module-part...
Interesting that he skipped the part about parsing the URL and generating the HTTP (httpMethod, path, headers), assuming that is the protocol. It seems relatively simple but unless one is careful there are some gotchas. Perhaps that is why this particular part of the process ends up in so many "web security" write-ups; many people, including the author, just do not think it is significant. He also asssumes that the client is a "browser".
I was once curious about this sort of thing. I hate that I didn't know how a computer worked from the ground up, it made them feel like magic when I knew they were just clever machines. I wasn't satisfied with learning about circuits so I went even lower and asked how transistors work. I spent a long time in a deep rabbit hole learning chemistry so I could understand why capacitors keep charge and etc. That's when I realise to learn every layer of a computer to a level of expert proficiency is a lifetime's work, not something you can expect one person to be able to do off the top of their head.
This is why we work together, we are not swiss army knives.
I appreciate author's quest for bottom-up understanding of all the things we depend on daily. The quote "We are standing on shoulders of giants" really shines here, and we all do a great service to them by trying to understand.
A nice why-and-why journey. Yet as an interviewing approach this seems to lack an initial premise, the need.
For example.
* I want to know what does a URL represent. Is it a porn site? Am I gonna be hacked/tracked?
* I need to check if this domain name is not/taken.
* I want to know if URL can contain spaces, or emojis.
* I want to know if I get a reasonably fast response.
* My phone tells me the site access is Forbidden.
Basically, a reasonable answer needs to be also a "Why?". This sets up a logical context for drilling down with an intention to locate something, not just for the drilling down sake.
Your browser tries to guess if what you have typed is is a url or a search query. If you’re using chrome then there is a chance that your request will hit a root domain name server so that the browser can check if you are connected to a scammy Internet service provider or some other ad serving intermediary. https://arstechnica.com/gadgets/2020/08/a-chrome-feature-is-...
There seems to be a need for resources about browser internals. This is something we could potentially pursue on web.dev. However, it's a big field. Can you all help me by:
* Providing examples of existing resources that explain browser internals which has made you a better developer
* Listing situations in which you needed to go deeper into how browser internals work and didn't find good resources
Another interesting thought exercise would be "can you accomplish X with as few layers/infrastructure/historical context/complexity as possible?"
Knowing what you need to accomplish, can you design a system from the ground up that sheds some of the traditionally expected layers and idioms and see what you can come up with.
I really like this question. What I get out of it is where the candidate focuses on, and where they gloss over. I find it useful to prefix the question with a statement about there being no "right" answer, and "go in as much detail as you want or know".
Since I'm not hiring for hardware, when they get into minute details about keyboard and USB, I smile and gently interrupt to move to the browser making the request. Come to think of it, I may rephrase the question to "What happens when you click on a link?" since that covers browser events, CORS and all that fun; and does away with the keyboard.
If you don't want to hear about USB details, beware, clicking often involves USB mice.
More importantly, telling someone there is no right answer, and go into as much detail as they want, and then cutting them off when they do is a bad interview experience. At least guide them on where you want to focus. Or let them take you on an adventure through USB. The point of this as an interview question is to demonstrate broad knowledge as well as some detailed knowledge --- it doesn't particularly matter which knowledge.
If someone can figure out USB, they can figure out TCP, etc. You're looking for people who can figure things out. It's all distributed state management.
Maybe a little different if you're hiring a contractor than a staff member.
A bit dated as well. It's assuming I'm using a physical keyboard. Today I might be using my phone. Might be using voice recognition. It might be my fridge hitting a URL using IoT to order me some more beer.
This is why I love this question as a phone-screener for onsite interviews and stuff.
Sounds so easy, but there is so much depth in so many areas that people can drill into. If someone starts talking convincingly about the OS handling keyboard interrupts or about HTTPS certificate revocation during the TLS handshake explanation etc, you know they are probably worth bringing in for a face to face.
Someone bluffing will usually fail this really hard - "The browser connects to example.com and downloads the page." or something. Uh-huh. Maybe they talk about DNS ... Maybe they talk about a TCP connection ... Maybe they talk about retrieving the HTML and parsing it ... but even then, if they get that far that will be better than a lot of bluffers. If they have simply revised anticipating this question and can answer everything then congrats - they've just educated themselves in a lot of the core fundamentals :)
As an interviewer this question can easily take up a whole 30 min phone screener as good candidates get deeper and deeper.
> Sounds so easy, but there is so much depth in so many areas that people can drill into. If someone starts talking convincingly about the OS handling keyboard interrupts or checking for HTTPS certificate revocation during the TLS handshake etc, you know they are probably worth bringing in for a face to face.
If I ask you "what happens when you load a URL" and you start talking about the operating system's handling of keyboard events, I might get the impression you're hopelessly prone to bizarre and useless digressions.
I usually say something like "What happens if I type 'example.com' in my browser's address bar and hit enter?"
If someone goes wildly off-track and starts talking about the design of the mechanical switches in the keyboard or I am specifically interested in one area vs another then you can easily tailor it "Ok cool - lets skip ahead to the network aspects" or "lets say I've found the server and downloaded the HTML - now what?" etc.
That said, I often like to let people just talk in interviews unless I am really specifically trying to drill into one area and get specific evidence of specific skills. I might jump in with a "Ah - interesting. Tell me more about DNS" or whatever, but usually I find that the good candidates will have a lot to say, and the less-good candidates either say hardly anything, bullshit, or talk a lot but are not good communicators (confusing explanations/hand-waving/etc) ... or a combination of those things :)
I wouldn't consider it bizarre if a candidate has deep knowledge about something different than what I expected when I started. I'd consider that pretty normal actually, since most people don't work on the same thing.
I wouldn't consider it useless either, unless I'm hiring an engineer for a narrow focus on something (e.g. I want someone that knows BGP), but I've never done that.
> I've found that the ability to learn is fungible.
The ability answer a question effectively instead of exhaustively is important too, though, right?
Personally, I'd be more impressed by the candidate who answers this by first asking "is there a particular aspect or perspective of this task you're most interested in?", especially if they can highlight the broad aspects involved, and offer to drill down on any in particular.
I’ve more commonly heard the question phrased as “after you’ve typed a URL into the browser bar, tell me everything that happens when you press Enter”, which makes talking about key handling issues more reasonably in-scope.
What kind of programmer knows how the electrical engineering of a keyboard works and why should that be a deciding factor in getting a job in some crumby internet company that has no business working on hardware layer tech? Even as someone who has an understanding of these things, why would I entertain you with something as menial as how the browser does html parsing? If you want to know if I know what that is, just ask me what that is. Don't treat your candidates like lab rats.
> This is why I love this question as a phone-screener for onsite interviews and stuff.
Same here and I'm confused as to why this comment has been downvoted. It's a perfectly good question for level setting. You get an idea of how much the person knows about various aspects of the system without having to ask pointed questions that they may not know. Instead, they get to show you what they are knowledgeable about.
"A charming story which explains how something as apparently simple as a pencil is in fact the product of a very complex economic process based upon the division of labor, international trade, and comparative advantage."
https://oll.libertyfund.org/titles/read-i-pencil-my-family-t...