Reading this article inspired me to raise some questions to the developers community.
In case you don't want to read the post, the writer, Anton Frattaroli (https://dev.to/antonfrattaroli) says that he was asked a question in a job interview, and the question was: "What happens when you type 'google.com' into a browser and press Enter?".
Why is this even an interview question for a DEVELOPER?
Why a basketball player is NOT required to also know how to play football or tennis?
Why a Math teacher is not also required to teach Physics or Chemistry?
Why a house painter cannot paint cars or paintings as well?
Why a dentist cannot operate on your heart?
...
WHY is it when it comes to DEVELOPERS, we are supposed to know NETWORKING, OS shell/bash/commands, other languages, the WEB, the INTERNET, COMPUTER HARDWARE etc..?
I believe, as developers, we are required to know our language (PHP, Java, Python..) very well. We also should be required to know couple of frameworks and technologies accompanied with that language, such as Laravel(framework), MySQL(database). And we should know some "global" tools such as an IDE/Editor (PHPStorm, Sublime), versioning tool (git, SVN) and so on. For a web developer, HTML/CSS/JavaScript is a must. But beyond those, I really don't see why a PHP developer would stuff their head with Networking or OS specific info.
Surely, knowing more is better, but I don't think it makes you better developer than someone who REALLY understands PHP.
The thing is, as developers, we usually get to know things, about networking, OS, the WEB and so on JUST to get the development process ahead. I remember installing PHP and MySQL on a Redhat server just so I can write some applications later on. I cannot say how MAD I was when I was asked to do so and how HAPPYYYY I was when i did it! I enjoyed learning a new thing. We all do as developers. Which is why, I think, people who are not developers EXPECT from us to know everything!
We need to set boundaries. Ask us about what we love to do, what we learned and did for thousands of hours. Don't ask us about the few hours we spent reading an article about Networking, or the few hours I spent installing PHP on a server. We are ADAPTABLE bunch, us the developers. We can do almost anything! But let us do what we are BEST at it!
In case I missed something, feel free to add your thoughts!
Oldest comments (51)
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.
It all depends on perspective. Your reference group for difficult job interviews is presumably big tech firms like Amazon, Google, FB, etc and probably some well funded startups. And surely they are putting everyone through the ringer because these firms have become a status symbol type of job. Think of something like college admission into the Ivy League: they do this because they can.
Dig deeper into the tech landscape and I wager you'll find exactly the opposite. Most hiring managers for large, non-tech corporations, non-profits, government, etc don't even know how to construct the job descriptions. I've seen jobs asking for 8-10 years of React experience ;) If you're savvy, you're likely the most technically capable person in the room for these interviews.
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.
I was asked something similar years ago. He said "I open a website in my browser, turn around and talk to my wife, and when I turn back the page has changed, what could have happened?"
I thought he was looking for something specific, so I started guessing, and it started making me angry, and I'm usually pretty grounded. It ended with me saying "I don't know what you're fishing for, I've given you like 8 possibilities already."
But he was a really good interviewer - unfortunately I was too inexperienced to appreciate it.
My experience was part of what, in hindsight, was still a really bad interview. The person who asked me that question was a manager basically reading off a sheet of questions and the next step was with a dev who's only real concern was whether I'd "annoy" them once I got the job.
I'm sitting here just shaking my head at the memory.
I once offended an HR manager, by asking them "are you gonna ask me about the principles of OOP?", and apparently he was, because he was shocked and told me why shouldn't he, and I said "You invited me to a Senior PHP Developer position, surely I would know the OOP principles by now!".
Well, I didn't mean to offend them, and might have come as arrogant to them for saying what I said... Oh well...
The browser was an unpatched IE 6 with a litany of vulnerabilities including one that allowed ActiveX controls full system access with admin rights. There happened to be an embedded ActiveX control in the page you opened that downloaded an exe and launched it. The exe then went through the file system looking for adult content on the machine, generated an html page containing all of that content, and launched the page in the default browser: IE 6.
Lol, I did not think of that one.
Same here.
Few weeks ago I tried to get vetted at a freelancer platform and they did two interviews and a test project to check if I could really programm, haha. This was the first interview process in my life that asked valid questions for soft skills and technical skills and had a test project that made sense to me.
Most interviews were either done by people who didn't know what to ask OR how the answers should look like, they just hired me based on a gut feel I guess.
And a few were some strange processes that asked basic computer science stuff and required me to implement strange projects that had nothing to do with the job. I always failed and I'm still salty about them :/
But
/etc/hostshas 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 returnedNSrecords to contact the next DNS server about a name server forexample.tldso that I can ask that server whatwww.example.tldis, only to get told it is aCNAMEso I have to do the same thing until I finally get a hold on anArecord.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.confornsswitch.conf. We're also supposed to be system admins.So how about that multi threaded weighted graph exploration algorithm...
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:
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.
Yes, this absolutely. It's a measurement of behavior and thought process (as much as these things can be measured) not how many details and facts you were lucky enough to have already learned.
I guess our job titles haven't matured the same way as our profession has. I mean we have lots of job titles besides "developer", like "programmer", "architect", "(site reliability) engineer", "devops expert", " ninja", you name it. But every company seems to have their own profile and requirements for these titles. There's definitely a lack of standardisation, which leads to frustration based on different assumptions.
In the end the title "developer" is what most of us are fine with - the generalists as well as the specialists.
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".
You know, I was watching a video(youtube.com/watch?v=Wx3WlQLFa3w&t=...) about Security the other day, and one thing that really caught my attention was the speaker saying:
"thinking you can create a secure platform to host your application when you are not a security expert is like thinking you can represent yourself in court when you are not a lawyer."
Security should be one of the biggest concerns for any developer, but yet we are all "wannabe security experts" as developers.
OS? Do we even dare to claim that we understand how the OS handle things?
Network? Who is a CISCO certified engineer? I know few, but they aren't developers.
WE might know a thing or two or three. Some of us are more hardcore, they really dive into one of those topics. But you guys cannot hold it against other developers who don't know how the DNS works or so on, because you didn't know as well at some point, you only learned about it when you NEEDED to, and you probably forgot about it by now. And there is a TON of things you don't know about OS or Networks or or or... Maybe, there's a ton of things you don't even know about that one language that you think you already mastered.
Developers want to believe they know everything. Let's face it, we don't have the brainpower to memorize it all. You learn a new thing today, you forget something you learned 100 days ago. Knowledge comes and goes, your essence as a problem solver evolves with time. That's the real you. That's your identity as a human and as a developer.
But we haven't event started at the beginning yet.
It is unclear if an USB keyboard was used or a PS/2 keyboard. Because they are fundamentally different. In case of a PS/2 keyboard we are creating interrupts to which the computer must react right away. The USB keyboard is polled of pressed keys every ... etc. etc.
Is this really relevant? It isn't. This is the whole point of robencom's question. It is not really normal to expect developers to know everything related to computers. Where does it end.
Just knowing the language is not enough. It is not even that important. Knowing the principles on which the language is build is more important. Languages change. Choice of language can change. The principles do not change that much.
I'm glad you got the point, Michiel.
As you said, the principles, the FOUNDATION of Development really doesn't change much, it is the same for any language really.
Interviews should test the ESSENCE of a developer, their ability to use their brains to solve problems. Interviews shouldn't consist of trivial or random questions about our field.
While I understand and do believe it's important to understand some things about computer science in general, to think that someone pretty much can't be a good developer if they don't know those things, then you're flat out depriving yourself of some really good developers. Some of the best developers I know couldn't explain that stuff to you yet I know they can make a damn good app that runs fluid and has a lot of optimizations. But because they don't know all the low level stuff of DNS they should not be hired? Who ever thought of this for developers is part of the big issue developers face right now in interviews.
I will admit I do ask "open ended" questions sometimes just to see how you think. No right or wrong answer. It also doesn't make or break an interview. I'm just interested in seeing how they "think" how they might go about thinking of a solution.
But in general, if I'm not interviewing for a job that is super network or low level code intensive, then asking me low level computer questions is flat out a waste of time. Cool they know how a DNS server works. But can they actually solve that issue of needing another React Expert? Answering that question doesn't tell you any of that.
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!