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!
Latest comments (51)
Thanks for sharing this important information with us.
also practice more Tough Interview Questions and Answers.
What is happening in the UK is roles are asking for an increased range of skills, which can never get used in the role. To cover that many technologies would result in nothing of quality getting delivered.
The truth is, people are greedy. They want their hires to have all these skills and then some.
I happen to have BI, server side and Web development - but draw the line at chasing more technologies just because employers claim to want them. So, I will learn svelte at some point, but avoid angular. I doubt I will learn power bi but, may learn sap hana. Doing so puts them on the back foot because you have skills they don't.
Why is this even an interview question for a DEVELOPER?To test your basic knowledge, and how you think if you don't know the specifics. I would say that for a frontend, at least knowing about
HTTPwould be the minimum. For a backend, making the link betweenDNS, thenHTTPthenHTTPSwill be considered correct. How you fill the rest will tell you on how you think.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..)That I would disagree. A programming language is just a tool in the stack. Everything you do as a developer is solving problems, by taking input and producing outputs. So "communication" is way more important than the language. Algorithms too. If you have your algorithm written in C++, then switching to Java and PHP is a few Google Search away. You could train yourself to know all the PHP API from A to Z, it would not make you a better programmer if you don't know what infrastructure will run your code and for what purposes.
For a web developer, HTML/CSS/JavaScript is a must.I was a web developer for 8 years, project manager for 3 and little I know about CSS. It was usually the digital graphist designer who transform their photoshop maquette into CSS code at least 3 times faster than any programmer I know.
But beyond those, I really don't see why a PHP developer would stuff their head with Networking or OS specific info.For instance, web developer often develops on Windows but their code is hosted in Linux. Linux has a case-sensitive file name scheme, but Windows doesn't (try to create a file named hi.txt and Hi.txt in the same folder). It can impact you PHP includes, but also if you try (you shouldn't) export your MySQL database from Windows to Linux.
Often, dev environments are different than production. I saw a bug where our clustering tool for MariaDB didn't work with MyISAM and one table hadn't popped up at peer review, half the data was displayed for each refresh.
For backend developer, knowing about proxy/reverse-proxy can help you dodge backend to backend API calls.
And with containerization, your solutions should be shifting towards their premises: a container should run a simple process doing one thing easily, independent, immutable, etc. That would have a great impact on your way to develop your solution.
That is just the tip of the iceberg.
Surely, knowing more is better, but I don't think it makes you better developer than someone who REALLY understands PHP.Yes, I believe it does, since when you will be confronted on a bug that does comes from your communication protocol, OS-stack, and stuff, knowing how it works will help you find it faster.
I cannot say how MAD I was when I was asked to do so and how HAPPYYYY I was when i did it!I was exactly like that when I started, I didn't like to depend on software other people had created. When it bugged, I would say to myself "How hard it would have been to make it like this instead???". But then I realized I couldn't do everything and open my mind to the world.
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 NetworkingI agree with the fact that you should work in a place you will like to work. Don't take a job that will ask you to do stuff you don't like. Don't forget that they are searching for someone as much as you are searching for a job. If the job doesn't fit your needs, just don't take it.
We are ADAPTABLE bunch, us the developers. We can do almost anything!That is also true: I always say that a developer that don't like change will have a hard time in his or her life.
On a final note, my most stressful interview (even though I got the job) was for a teacher position for Web Development at a college (I'm in Québec so it is called Cégep, it is just before University). Questions like
What do you do if you are proven wrong?, followed byGreat, but now everybody is talking and laughing and not listening to you. All of that in front of 5 interviewers.The Enter key pushes back against your finger with an equal and opposite force.
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.
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).
This is my second read, and the paragraph contains "what happens when you type google.com.. " still made me laugh. Good and honest article
I disagree. You should not only know your own language and frameworks but you should also know at least one or two languages from different paradigms. For example, in 2018, you should know at least a functional language, a reactive language / framework and a procedural language, hopefully with a parallel framework as well. This gives you more insight into the different possibilities when looking for solutions.
If I only have a hammer, everything looks like a nail ...
Similarly, you should not only be fluent in your domain but in several others, e.g. front-end, microservices, web services/SOA, relational database, non-relational database and yes, networking. You should probably add several common services such as SOLR/Elastic Serach, TensorFlow, ... as well.
There are many reasons why such 'full-stack' developers are more valuable, the start with app architecture, security, performance and extend through devops and deployment concerns.
Yes, it's harder but it's no different from a building contractor having to know about HVAC, electrical, plumbing, roofing, masonry, carpentry and even landscaping.
Since there is the notion that software developers also need to know the basics, I'd like to contrast this to a real-world equivalent.
Imagine I have a plumbing problem, and am looking for a decent plumber to take care of it. To get some idea of their knowledge and understanding, I ask them what water does when it goes into the pipe. Regardless of the academic background of the plumber, should their answer relate to the ideal gas law, should they be explaining Poiseuille’s law or would Bernoulli's principle suffice, or are they better of explaining the stochastic effects of thermodynamics as it relates to small polar molecules?
That's not to say that the basics are never helpful, but people tend to get more work done if they apply deferred execution to their learning: if I need to know about thermodynamics, I'll study up on it. Until then I can perfectly do my job by knowing that for these situations a brand X plastic pipe will do and for those situations a brand Y metal pipe will be necessary.
In fact, being able to apply deferred execution (to both learning and problem solving) is a vital skill, if you're to avoid being bogged down in yak stacks. This also very closely relates to being able to solve problems through abstraction, which is an actual basic skill for developers.
Whenever I have tough intrrviews I always remind myself that this is the easy part. The real tough part is the job itself. I can't even compare the complexity.