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!
Top comments (51)
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 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.
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 :/
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.
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...
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 😜
The difference, is that you don’t ask a plumber to build a swing for 20 people (hey, why not? He knows his tubes !?!), or even an “electrician” to build a MHD flying saucer (after all, it’s just wires with current and tension).
But in the case of a software developper, you will ask him to build anything, impacting from the smallest data item (a few bits in a processor) to the whole world! Now people complain that bitcoin miners contribute to the climate change!
So yes, a software developper has the moral obligaton to know more than just a programming langage (I would hire somebody giving a good answer the that interview questions, even if he knew no programming language (as long as he can still do the fizzbuzz program in pseudo code)).
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.
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 agree with you, Nick. If you wanna check how an applicant thinks, you are on the right track. Testing an applicant's ability to solve problems or their ability to design a complex architecture that corresponds to your business demands is 100% justified.
What I am talking about is to standardize the interview process for software developers, so developers know what is expected from them to know.
Today, we have chaos. Each company has its own standard: in one company, they ask memory base questions which you need to answer in few seconds, in another company, they give you a 4 hour task before you say hello to them, in another company, they ask you about simple things and if you fail to answer one of them questions, they end up considering you "below the demanded level" although you have 10+ experience in many other companies.
(I can always ask you a SIMPLE question to which the answer you might have forgot..)
One more thing about your last point (paragraph), I learned all what I know on the job. I was accepted as an intern, then I got promoted all the way to senior in about 4-5 years. You would agree as well that a GOOD developer is one that "learns on demand". We are humans after all, we are not memory machines. I bet you forgot lots of things that you have learned just 1 year ago. We forget the code that we write, don't we? We forget code because we write lots of code, and we forget knowledge because we already know too much of it.
Someone, someday, will figure it out. They will figure out how to shape up a fair job interview for both the company and the applicant. All I want is to contribute to that.
I'm with you on that. I forget stuff all the time. Sometimes I feel like I am developing Alzheimer's with the amount of stuff I can't recall. However, one thing I've noticed is that my fundamentals are still very strong. I don't do well on interviews if I go in cold without brushing up on stuff. And, it sucks to have to learn everything all over starting from my first CS course - (I've been coding professionally for 20 years now!).
I have preferred project based interviews as they are more realistic. However, those are a bit tricky as you may not be able to gauge everything. On few of my recent startups, I paid candidates to work on a problem that was relevant to the business. I liked that approach as both sides were gaining something and nobody was taken advantage of. Also, if it turned out relatively well, I was able to use their code.
I don't think Software Engineering can be compared to other professions. What we do is pretty unique and things change daily in our field which is important to be on top of if you want to stay competitive. The scope of work for most of the other professions is fairly limited, so I think the interviews can be standardized there. In the 90's and 00's, certification was a big thing, but I think that has sort of phased out.
You are right that we should be learning-on-demand, but one can do that only if they have strong fundamentals. Traditionally, this was evaluated through your transcripts and GPA, but that is not a good metric. So, how else can we evaluate a candidate in 30-60 minutes?
Anyway, I like the discussion on this thread. Thanks for starting it.
I also prefer home based tasks/projects, but they don't usually pay around here..
Fundamentals are a must know, I agree totally, the rest should be "need to know".
I've been doing this for 5 years and I already feel like I got a bad case of the Alzheimer's , I cannot imagine what would happen after 20 years!!!
I hope you'll keep on posting on Youtube, I just started following you there. Very interesting stuff, especially that I just started focusing on React.
Thanks! Let me know if there's a particular topic you'd like to learn about.
Once a company had me work on a distributed cloud storage (like dropbox) that encrypted files into 96 chunks which were stored across the web on 96 different machines with redundancies. The idea was that you give some space on your machine to get some space on the cloud (aka other people's machines). They said to do my best work and take as long as I want - it took me 3 weeks to deliver something that was production ready. They loved the project and called me in only to say that oh we don't have that role anymore, instead they made an offer for an SDET role. I'm glad that place went out of business recently!
I've worked with people who've been in the industry for over 40-50 years and they're definitely a huge inspiration, so I think there's hope for us. :D
Well, I am fairly new at React, so just about anything is interesting to me.
One little thing I would ask for is that in your React video, we could hear you type kind of loudly. If you can push away your microphone from your keyboard, I think the viewers would really appreciate it :)
Thanks for the feedback. I will need to figure this out. I had increased the gain on my mic since last time I got feedback that my voice was a bit low. The keyboard on my macbook is also a bit loud with the force feedback. I might need to consider typing in chunks and turning off the sound and introduce background music (but that'll work only in large chunks, not every 10 seconds :D).
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.
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.