Why do developers have the toughest interviews in the world?

I've been asked similar questions and I think they have some merit and are actually useful if asked for the right reasons. Here are some thoughts:

• If somebody expects you to give a perfect answer without leaving any details out, they're bananas and you're not getting the job (and you should be glad you're not going to work with them).
• If you're interviewing for a backend position, you're expected to have some rudimentary knowledge about how the internet works.
• If you're interviewing for a frontend position, you're supposed to have some idea about how your code is going to be sent to the user's machines and what is going to happen to it once it gets there (talk about loading times and such).
• It's a good question to see how the candidate talks about a topic that is complex, can't be explained in depth in a few minutes, and that they probably don't fully understand. Do they make stuff up? Do they admit what they don't know? Can they communicate a very complex process in an understandable way? What level of detail do they choose to focus on? Can they make their message fit the audience if you ask them to explain it for their grandma?

To draw a parallelism with another profession, if you're in the business of making windows, you probably don't need to be an expert in metal foundry and glass blowing, but you should know that materials expand with heat and make sure that your windows can still be opened during summer (hint, not all of them appear to know that).

In summary, many interviews suck, and an interviewer can make this question suck, but I don't think that the problem lies in the question itself.

I loved @antonfrattaroli 's post, but that same question was the first one I was ever asked in a technical interview for a job I didn't get and I still feel pretty salty about it. I didn't have a good answer but I would have still been great for the job. Basically how I feel about several failed technical interviews early on.

But /etc/hosts has nothing to do with DNS. Yes, they are both related to host name resolving, but so is NetBIOS.

Why should I know that I first ask the known root DNS about which server knows about .tld, then use the returned NS records to contact the next DNS server about a name server for example.tld so that I can ask that server what www.example.tld is, only to get told it is a CNAME so I have to do the same thing until I finally get a hold on an A record.
They are looking for a back-end developer working on standard business logic. Not for a network engineer or a developer writing a DNS client or server.

Oh wait... we did not even reach the DNS part yet, we are first going to through the OS's name resolving. Maybe messed up the resolv.conf or nsswitch.conf. We're also supposed to be system admins.

So how about that multi threaded weighted graph exploration algorithm...

We work in an unregulated industry where information is only proven by other "experts" in the fields (usually a team member or consultant).

Electricians, plumbers, architects -- all have to get licensed by the local government to operate their business. Why? Because as a society we understand that the quality of their job impacts the wellbeing of real people. If a house isn't built properly, someone can get hurt.

But when it comes to creating applications for people, particularly ones that engage with a certain level of a user's privacy or information, developers aren't required by law to get certified by their local government (or even a larger governing body for developers).

This lack of standard for licensing causes fissures in the professional development community. Who do I trust with my application code? The guy who says he took a bootcamp, or the one who says he's an expert in React. It all has to be proven, either by a fellow expert observing the professional produce the code in person, or by probing the professional with known issues concerning the topic.

It's similar in the art world, where everyone has different backgrounds and methodologies for accomplishing tasks. Someone may know how to use Photoshop or Illustrator, but may not have experience actually physically printing their work -- which would be somewhat necessary for a position like "Head of Printing".

Obviously some developers take this to an extreme when they require seemingly unnecessary knowledge for the position. There's a line between what I need to know, and what an elitist things I should know. Or really, it lets me know how truly broad the job description is -- and that as a Senior React Engineer, I'll probably be doing devops too 😜

It can't all be observable distributed event-sourced machine learning NoSQL blockchains all the time. There're boring parts, or rather there are parts you personally may not be interested in, but most of the domain knowledge and practical considerations you mentioned are rather important to the modern practice of software development.

You seem to have a particular antipathy for networking; it's about my least favorite area as well, but I work on systems that communicate across networks -- as do you the instant a database or REST API is involved -- so an understanding of the basic principles and a familiarity with common patterns, tasks, and trouble spots is immensely useful in my capacity as a developer. This is how I can venture the slightest bit outside my comfort zone without becoming stuck immediately. At a certain skill level we're supposed to know the fundamentals of this stuff, or to have the grounding to be able to research and come up to speed quickly, because without that broader foundational knowledge we are worse at applying that skill.

And as for tooling: understanding your operating system, shell commands, scripting languages, and even hardware makes you a more effective operator of a computing machine! Not everyone has the time or inclination to really dig in but there is incontestable practical value to it!

Sometimes interviewers ask questions to probe your breadth of knowledge. If I asked this question of an entry level candidate, they would rank up a notch if they were able to make a serviceable answer. But being unable to answer would not disqualify them, since entry level is not required to already know this.

Breadth of understanding is very valuable... if you don't consider how your software affects others (users, IT, budgets, etc), you are not going to make very good software. Entry level devs are given a narrow scope and allowed to be somewhat ignorant of these things in the beginning. But they should not stay that way.

But beyond those, I really don't see why a
PHP developer would stuff their head with
Networking or OS specific info. 

Because the knowledge is relevant and critical. It's OK not to have learned these things. It's not OK to refuse to learn things vital to the job. Without core knowledge of the software environment, how the data is delivered and rendered from server to client, an internet software developer is unequipped to make good design decisions -- blindly unaware of what problems are being introduced or why.

I hate this process and agree with your sentiment. However, it is necessary.

It gives you an opportunity to drill into someone's mind and uncover their capabilities. Anything and everything can be put on a resume. You could have watched a video tutorial on a topic and know enough about it to bullshit your way through it, but that doesn't mean you can actually apply it effectively.

When hiring an engineer, I want to test that engineer's breadth and depth of knowledge. Everything on their resume is fair game. In addition, most jobs are not constrained to just coding simple stuff. You run into unforeseen issues. I want to know that the engineer is not going to simply rely on StackOverflow or google their way through it and copy/paste stuff.

Without that level of knowledge, you won't be hired by Google or Microsoft or Facebook. These companies have a business to run. They need self-starters who can work autonomously and come up with novel solutions. That doesn't happen if your breadth of knowledge is narrow.

If you're good at PHP, you can build a good website, but you won't be able to build a large-scale distributed system that can support 12,000 requests per second. However, your knowledge about networks, hardware and various components in the pipeline will allow you to build such a system effectively.

I'm a little bit infamous for playing devil's advocate on this topic around here, but I think it's worth pointing out: a developer whose work touches seven topics had better know enough about those seven topics to not be a liability. Most of the worst blunders in computer history were because some developer didn't understand their client.

That is not to say that we should be experts, but there is a balance. Software that works over the network needs a developer with a working knowledge of networking. Air Traffic Control software must be written by someone who knows how ATC works. Software for scientific-calibre light microscopy requires the developer to be comfortable with the concepts and terms in light microscopy. Accounting software should be written by developers who have a working understanding of accounting. And the list goes on.

One might say, "Baloney! That's the client's job!" But if we're honest, because we're the programming experts, it's our job to know what the client needs in the software when they don't. We need to inform their choices, and they ours. If that's missing, terrible software results.

Now, stepping back from that, is there a problem with HR departments expecting developers to know everything about everything? Yup. Can that improve? Yup.

Yet, between the two standpoints, we also have to consider: how certain are we that those questions were the deciding factor in our not getting particular jobs? HR rarely tells us candidates anything. It could well be that we were the second or third choice on the list, but some other guy had valuable related experience that we didn't.

I don't know that the question is asking what you think it's asking. It's a complex and deep subject, and certainly not many people, if anyone, can answer it exactly. Knowing just a little bit, though, can you REASON how it works? If you don't know anything about it, could you develop a rudimentary algorithm that would accomplish the goal? It's a critical thinking question. Knowing a language isn't development. Development is taking complex problems and breaking them down into smaller and simpler problems with help of a language. This is a great question to see if you can do that, especially if you don't actually know how it really works. If you can't use your native speaking language to express a complex idea, why would I think you could do it in a programming language?

Software doesn't exist in a vacuum. It runs on an operating system, that sits on hardware, that utilizes a network and each piece of the puzzle inserts variables that will impact the software you wrote.

The classic interview question "what happens when you type google.com in your browser?" I think is a fantastic question, and everybody should be able to answer it at some level.

Without understanding where and how your software runs then the only answer to "It's not working in prod" will be "well... it works on my machine".

There are a lot of strange questions posed during developer interviews.
They usually fall into one of the following categories:
-Exploring how the candidate parses/tackles a problem
-Determining depth and breadth of the candidates peripheral knowledge

So when we were last hiring for a developer, I posed questions about sorting and memory use, as well as a ridiculous question about performing an algorithm in assembly. We don't use assembly, and the language we use handles memory allocation in the background. The purpose of those questions wasn't to see if they knew assembly, or if they can crank out sorting algorithms. The assembly question lets me see what they do when they're confronted with a problem that "looks scary". The sorting question lets me see if they know enough about computing and memory allocation to make wise choices when designing their own methods for handling our data.

Any professional should know how their tools work. A race car driver might not be able to bore out his own engine, but he should know about gear ratios and compression. A hunter should have a rudimentary understanding of rifling. As programmers, it behooves us to understand how computers work, the fundamentals of networking (since few computers are used sans networking these days), the fundamentals of how an OS works, and if you're a web dev, since the users' entire experience occurs in a browser -- how information is exchanged between the client (browser) and the server.

Actually it’s a fundamental question I’ve been asked this question and i also ask it a lot in interviews.

The key concept is to uncover your curiosity and passion, not to give a perfect answer. It’s also not meant to be a make or break question. I see it more as a conversation starter.

That said I’m bothered by companies who still ask for a personality test to determine “culture fit”. I’ve built great tech teams and culture without weird tests.

Tech recruiting is hard but it takes an empathetic nd knowledgable tech lead to identify great talent.

"What happens when you type 'google.com' into a browser and press Enter?"

The Enter key pushes back against your finger with an equal and opposite force.