I've done these sorts of questions before and the point (more me at least) was two-fold:
1. Do they understand the basic machinery of a web application (assuming the job is about building web applications)?
2. Can they take a vague problem ("the page is loading slow") they might get from an actual non-technical user and drill down to identify what precisely the issue is? Is it DNS? Is it a proxy server/load balancer? Is their latency at the DB layer? How would you tell the difference between all of these?
I find it hard to believe that somebody with no knowledge of "low level compiler and OS stuff" that did know the basics of caching (generalized) and had strong problem solving skills (which all developers regardless of specialization should have) would have a hard time puzzling something approximating a correct diagnosis.
I think that you are not giving your average "web developer" enough credit.
You don't need to know enough to understand and implement all the details from server to network to browser, you just need to know enough to remove the <script> tags related to ad networks and tracking to see huge load time and ux improvements.
It's not really the web developers who are the issue; they just implement what the people above them in the org chart wants. You could argue that the web developers should push back on it more than they do, but I don't buy that they're not knowledgeable enough to fix it.
That's not to say that there aren't actual technical issues; the recent trend of throwing front-end frameworks on content-heavy pages, making the users' low-powered phones parse and run hundreds of megabytes of JS before the page can be interacted with, is an example.
When faced with building a simple web page, Team 1 spends a couple of days producing a single static html page and builds on it as necessary.
Team 2 spends 6 months showing upper management architecture diagrams and flashy mockups. They blow a million dollars on cloud hosting their load balanced web servers. They've got Kafka, ElasticSearch, triple redundant SQL servers, and a 12 person team to run it all. But when asked to present the actual page they announce that nobody on the team knows HTML and they just kind of assumed somebody else would do that part.
Non-technical managers cannot tell the difference between the two teams.
If you are in the business of developing and running web applications there's a lot overlap between dev and ops in terms of knowledge. If you have to troubleshoot something you need to know HTTP Headers, CORS and related topics.
Who is in charge when the latest update of Chrome breaks your clients' websites? Wearing both hats certainly helped us fixing stuff easier by inserting headers through HAProxy although our regular job is programming.
What about performance optimization? Can that slow SQL query be fixed through tuning the MySQL server or maybe just rewrite the code?
Call me an ahole, but I really think that web dev does not require nearly as much deep knowledge of computers as an engineer working on lower levels of the stack. Each web app usually solves the same tired problems again: interface with a db, present data, cache stuff, handle user accounts etc.. There is some meaty stuff - perhaps caching and serious performance optimization, but most of a web app is either front-end CSS stuff, or interfacing with a DB to fetch data.
Yes, there is definitely work to be done in making a web-app, and i don't think its easy at all to get a website to be really fast or get the styling right across 100s of devices, but its not always technically challenging work IMO. I am NOT saying that web devs are worse, but yes, I am saying that the job generally requires less deep technical knowledge, and perhaps more of other skills i know nothing about :p This is the rationale for why I choose not to go into webdev, because i love solving meaty problems. I would love to hear your perspective and be proven wrong though.
I think in addition to the measures he says, if you're hiring for a web position, it's good to make sure they understand how the stuff they're using functions. If they don't have a good grasp of how http works / url parameters / that kind of thing, then they can have some nice looking code which seems to work, but has faulty assumptions that can be security and bug nightmares down the road.
Of course, you could always take smart people and train them - but seriously, who does that anymore?
I find web developers in general more knowledgeable. Sure they are not working in low level programming, but those that are working in low level programming often don't know what DNS, FTP or SQL is.
Remember that those who work in low level programming had nothing to do with writing the language or building the compilers. They just got a degree and started working.
I used to think like that. But then, doing web development myself on the side I've realized no, they don't. Languages and frameworks these days pretty well abstract the underlying technology. Developers end up writing some pretty amazing stuff. It's up to the sysadmin to weigh in on what changes are necessary to make it work well enough to succeed. A seasoned developer will know more, because they've been through the wringer a few times. The new guys, not so much.
Remember, your developer spends their time making it work on a dev box, or even their own laptop. Performance testing and such is an art that if they had time to learn it... well I guess they'd be a sysadmin.
Web programmers who follow your advice usually sound like idiots who don't know much about what they're doing. Lots of them like to reimplement wheels like HTTP caching, HTTP authentication and content negotiation, even error codes (!). I have grown tired of stupid shit web "programmers" without knowledge of HTTP are capable of generating. Especially when paid by an hour.
If your day job involves a particular field of maths or physics then I'd argue you're definitely supposed to have an understanding of the fundamentals. You can't build a bridge if you don't know how torque works or how environmental factors interact with the forces at play.
You don't need to know all of the frontend stuff if you're doing backend work, you don't need to know all the backend stuff if you're doing frontend work, and you don't need to know either if you're doing kernel development
In turn, you can leave details like memory management, execution modes, endianness and concurrent locking out if you're writing code for the browser. Browsers can do a lot, but the most challenging parts of programming have already been taken care of the moment your HTML gets loaded.
There are fields within programming (often overlapping) and if you work in your field, you should probably understand the fundamentals of that field.
It's fine for a web dev to know "between 1ms and 2s the response of a DNS query appears" without having to know how DNS works. You don't have to know _everything_. But, unless you're developing HTML files on people's desktops, as a web dev you do need to know how HTTP works. It's not magic, the base protocol is actually quite simple as it was once text based for human readability.
If you can fight your way through Javascript or Typescript with its absurd quirks and problems, you can understand HTTP if you try. Most of web dev is memorising the billion different options that browsers allow you to tweak these days, from CSS to HTML components, to get the design you want. Learning 50 or so other options and a few very basic protocols is hardly difficult in comparison.
Yes, a great interview question. And it's quite surprising how many devs do not know those things and still manage to build successful web applications, if not necessarily the most performant/secure/maintainable.
A web developer needs to understand the entire chain of technology, from his text editor or IDE all the way to the browser. You don't need to be able to build a server from scratch (although you probably should be able to), but you need to understand how the pieces fit together (WSGI, mod_php, PHP_FPM, CGI, for example) and that includes which pieces of that chain can cache, might cache, will cache, and how they cache.
The front-end developer needs to be more concerned with browser-related issues, but doesn't need to know anything about the server stack (typically). The back-end developer likewise doesn't need to concern him/herself with browser issues, but needs a solid grasp of everything behind the browser.
A web developer has feet in both worlds and needs to understand much more than the front-end and back-end developers.
As an analogy, a gynecologist might be a front-end developer. He has a basic understanding of the entire human body, but specialized in this one area and everything related to it. People like to hang around him, hoping something will rub off.
A neurosurgeon might be more of a back-end developer (not what you thought, eh?). He's concerned with the code running things and how it will react with everything else. He can be hard to talk to, but always interesting.
The dermatologist is your UX guy. Presentation is his game, and nothing else (but he still understands the pieces that interact with his domain). His home is always awesomely decorated, but not always functional or obvious (the three shells on the toilet).
A general surgeon is the web developer. Solid understanding of everything, great at finding and solving problems, but knows when to leave something to the specialists. He lives in the home you wish you had, and his pool table always has great action.
I got carried away with that, but the tl;dr is: the web developer needs to understand the entire chain of his/her domain. There is no piece too small that you don't need to know something about it - like how it works, or how to fix common problems with it. From editor to browser, you need to understand how it all fits together.
"If you are running a website that is the biggest site on the internet running that framework though you should have an inside-out understanding of the technology you are using."
Well, I bet that's true now.. Or will be..
But I can't imagine anyone not building or releasing a Web app until they have an inside-out understanding of the technology.
Assuming they have some means to monetize their traffic, they can now go hire someone to fix a problem most people wish they had.
I have to admit that I did not do any web development, but I have a pretty good idea of what kind of complexity and challenges it does involve. I also know about it from interaction with the frontend developers themselves and from toying around it.
I know what kind of tools are available, I know how dead easy debugging is. There is nothing nearly comparable in complexity with a hardware design.
1. Do they understand the basic machinery of a web application (assuming the job is about building web applications)?
2. Can they take a vague problem ("the page is loading slow") they might get from an actual non-technical user and drill down to identify what precisely the issue is? Is it DNS? Is it a proxy server/load balancer? Is their latency at the DB layer? How would you tell the difference between all of these?
reply