Mainly because a lot of the things you just listed are incredibly stupid requirements.
If I spent my life doing ruby sites that save basic data into a mysqldb, why does it matter whether I use sometching that takes 100,000 operations or 10,000 ones, when the web page still opens in 0.5 vs 0.51 seconds?
Or who gives a damn about system traces when I can put echo's in a PHP page and just view source?
Who gives a fuck about TCP when the browser abstracted that all away?
And when you say write a program, you clearly mean a console app, which again, unless you've written one, which junior programmers may never have done because someone else always wrote the helper & utility apps, it's pretty daunting the first time if you don't even know about main. Which suddenly makes it pretty easy. Imagine asking a front end developer to make a console app in their interview.
You do a particular type of programming. You seem to want to judge everyone else by your niche without understanding that a lot of the skills you list as essential are actually almost completely irrelevant to huge swathes of programmers. And they haven't learnt about them, because they don't need them.
The poster you're replying to isn't narrowing to a niche, he/she is simply trying to catch a red flag. You're right to be concerned that there are many interviewers who will climb way down the ladder of abstraction to their own particular niche and then crucify a candidate. But this isn't one of them. The poster even explained that it was only really a negative if all were wrong. I use a similar process as a quick pre screen.
Sailing through all questions allows us to proceed at a relaxed pace. Having nothing to say for one or two questions tells me nothing (it could easily be a fault of my question rather than the candidate). But no coherent answer to any question? Red flag.
Exactly. I've had several candidates that I have passed who on the TCP question have said "I don't know, networking is not my strong point." That's great! Knowing when you don't know something and should just move in is a real strength.
As long as someone does fine on most of the rest of the questions, having one or two gaps in knowledge is not a problem, I can tell from the other questions that they'll be able to pick it up if they need it, or ask for help when they need it.
This sort of attitude is part of why I suspect that even with all the incredible advances in computer hardware, that all of our applications seem to be just as slow and bloated as their equivalents were 20-30 years ago.
Mainly because a lot of the things you just listed are
incredibly stupid requirements.
Do you know the job I'm hiring for? Perhaps I'm hiring for something a little more complicated than a front-end developer over a CRUD app.
If I spent my life doing ruby sites that save basic data
into a mysqldb, why does it matter whether I use
sometching that takes 100,000 operations or 10,000 ones,
when the web page still opens in 0.5 vs 0.51 seconds?
Because sometimes, those 100,000 operations actually wind up pushing it from 0.5 to 5 seconds. Or even worse, something that works with 1,000 records in .5 seconds, once you go up to 100,000 records takes over an hour, because you're doing something that takes O(n^2) time, so a hundredfold increase in number of records leads to it taking ten thousand times longer. If you don't even know what big-O notation is, or how to think about an algorithm like that, you may not even realize why everything has suddenly gotten so slow; or even worse, you may have designed and implemented a large system with that O(n^2) baked in to the very fundamental design, so it would require a huge rewrite to eliminate it.
Who gives a fuck about TCP when the browser abstracted
that all away?
It is not always abstracted away as cleanly as you would like. For example, here is a bug that occurred when Firefox sent an HTTP request in several smaller packets rather than one larger one, and that caused it to break when talking to IIS:
How would someone impacted by that be able to even figure out what's going on, if they don't know anything about what HTTP is built upon?
Imagine asking a front end developer to make a console
app in their interview
Hey, it's a good thing this isn't my front-end developer interview; in that, I give people a basic REST API to program against, and have them write a simple frond-end for it, using any toolkit they like. No console apps at all in my front-end interview.
This is my back end, systems interview, for people working on a network attached storage system, where we frequently need to debug complex problems in a distributed environment, solve compatibility problems with third party proprietary software in which the options for debugging it are slogging through syscall traces or stepping through it in IDA, where we've had performance problems where tweaking the kernel's TCP retransmit timeout for systems that we knew were on the local network has made a huge improvement.
You do a particular type of programming. You seem to want
to judge everyone else by your niche without
understanding that a lot of the skills you list as
essential are actually almost completely irrelevant to
huge swathes of programmers.
Or maybe my interview is tailored for the job that I'm hiring for? As I said, this is my back-end, systems interview, and I have a different one for front-end developers.
And as I said, I don't expect every developer to pass every question. I do still ask the TCP and algorithmic complexity questions to front-end developers, but if they do poorly on those while being able to write up a front-end to spec based on the API I give them, and being able to describe intelligently how they would design a more complex interface with richer interactivity, then I know that they can do the job assigned and we have sufficient other people who can do review to ensure that they don't write themselves into a corner complexity-wise or help them debug weird problems due to something in the networking stack. Or if they do well at the TCP and algorithmic complexity, but are relatively new to front-end development, I know that they have a good base of background knowledge and analytic mind, which means they should be able to pick up the rest of the skills they need without too much difficulty.
But if someone does poorly on everything, or more than a couple of the questions, it means that we would basically be flying blind hiring them; we would need to train them up on everything they need to do, and in the end, there's no guarantee that they'd actually be able to perform.
You ask TCP questions to front end developers? It sounds like you are exactly the sort of interviewer this article is calling out.
Do you not think that this sort of specialised stuff is really easy to learn? That you should be asking questions to discover programming ability, not pointless reference knowledge in quiz questions?
I've debugged complex IIS bugs and found insane bugs in IMAP implementations that were caused by a change in the way Outlook handled the protocol.
I did not need to know that before I debugged it. That sort of reference knowledge is rapidly discoverable while you do the debugging. Most of that stuff I will never need to know again.
When I say "TCP questions", I mean that I ask the standard "what happens when you type google.com into your browser and press return," and expect to get them to mention TCP at some point. If they don't, I specifically prompt them, asking what protocols HTTP is built on top of, and how it finds the address of the server to contact.
I am not looking for detailed knowledge of receive windows, sequence numbers, or anything of the sort. I consider knowledge that TCP exists, and DNS exists, to be sufficient. And as mentioned repeatedly, even if they know nothing of this question, this is one of many. I want to see if they are the type to dig into the stack and learn more than just their particular domain, but the basic programming exercise and portfolio are the most important things that I look at.
The browser's abstractions are leaky, and given that I tend to work with small teams, an understanding of how the sausage is made is important. And I don't think you can really understand HTTP without understanding TCP at at least a high level. So if I'm hiring for a senior frontend person, I'd expect them to know how it works, and in discussing things (not "technical questions", I just talk to interviewees and go from there) I'd expect some demonstration of things that can make me feel confident that they won't be unduly thrown in day-to-day work by something involving it.
No they're not! Virtually no javascript developer needs to know about TCP.
Ajax doesn't go wrong. Most people abstract it even further using jquery and probably don't really know about how XMLHtttpRequest works.
What you've just said is absolute bullshit. Complete and utter horseshit. It's an artificial barrier you've erected to filter out people who aren't like you.
How wrong would you have had to write your javascript that you'd need to start knowing the specifics of two levels of abstraction down?
I am completely flabbergasted that a professional programmer would claim they needed a high level of understanding of TCP to write javascript.
I think you're misinterpreting the use of "high level" here. It's not that the candidate needs "a high level of understanding", it's that they need "a high level understanding". "High" here is in reference to the level of abstraction.
A high level understanding could mean something as simple as understanding the request-acknowledge nature of TCP, as opposed to the 'fire and forget' mechanism of UDP.
As to the claim that virtually no javascript developer needs to know TCP, that becomes less of a truth the closer you get to experimenting with tech like websockets, which is increasingly becoming part of javascript developers' jobs.
I think you're latching onto a narrative that you already made up about the poster before you even began this debate.
There's a large leap between what the poster is saying "I ask a wide range of questions to catch red flags if they get all wrong", and what you're saying "the poster is saying that javascript devs NEED to know TCP! Obviously an elitist filtering mechanism!".
Exactly this. A "pass" on that question consists of mentioning HTTP, DNS, and (perhaps with some prompting about what protocols underlie HTTP) TCP. A strong pass involves being able to tell me that DNS is usually UDP based, and being able to describe what distinguishes TCP from UDP. A very strong pass involves being able to describe in detail recursive DNS queries, talk about the fact that DNS can use TCP rather than UDP for queries or replies larger than what fit in a single packet, being able to tell me a bit about how TCP congestion control, sequence numbers, acks, Nagle's Algorithm, and the like work.
I should point out that I recently talked to a college junior who got a "very strong pass" on this question as a front-end intern candidate. If she can do that as a front-end oriented candidate with only a couple of years of experience in school, I don't think it's unreasonable to expect a professional with several years of experience to have at least the basic knowledge that TCP exists.
Some people are stronger in one area than another; so I cover a number of areas, and expect them to do well on a majority, but not all, of the questions. Even if you fail this question, just saying that you don't know anything about networking, if you do well at all of the others we will bring you in for the in-person interview; we have recently hired someone who simply said "I don't know" on this question, and was a bit fuzzy on the big-O questions, but did fine on on all of the rest.
Yes, this. Thank you for a reasonable reply to an unreasonable post.
(And as to the rest of his very angry post, I'm not a front-end developer, I do platform work and what some folks call devops. I can tell you exactly how XMLHttpRequest works, in detail, with diagrams. I can also go on at length about the DOM, the travishamockery of CSS, as much JavaScript minutiae as one would like...I think a basic understanding of the world around us is important to being good at things. Being "a front-end programmer" doesn't mean you should be so incurious as to not know how things you don't touch every day but directly inform the things that you do actually work.)
Except when it does. Did you miss the bug report I linked, in which it went wrong in one way when Firefox sent something as two separate packets, which caused IIS's HTTP implementation to break, and then when that was fixed the fix caused other regressions:
And this is only one of many such bugs; I've seen others in practice as well. It requires no special use of JavaScript to hit such bugs; just an unfortunate interaction between the particular browser and back-end server, of which there are many possible combinations, especially when you add transparent proxies into the mix.
By the way, when I'm looking for a frontend developer, I'm also not looking for someone to do the very most basic CRUD app plus some JavaScript for interactivity. I'm looking for someone to be able to do a rich, desktop-style app that pushes the boundaries of what can be done with HTML5 video. This is an area where you will be running into browser bugs on a regular basis, and need to know when to stop trying to solve the problem yourself and push the bug report upstream to the browser vendors, and in order to be able to do that it helps to have a knowledge of what is going on at that level. For this application, we accept that we will only be running on the very latest releases of a few select browsers, until interoperable support for the kind of stuff that we're working on becomes more widespread.
If I spent my life doing ruby sites that save basic data into a mysqldb, why does it matter whether I use sometching that takes 100,000 operations or 10,000 ones, when the web page still opens in 0.5 vs 0.51 seconds?
Or who gives a damn about system traces when I can put echo's in a PHP page and just view source?
Who gives a fuck about TCP when the browser abstracted that all away?
And when you say write a program, you clearly mean a console app, which again, unless you've written one, which junior programmers may never have done because someone else always wrote the helper & utility apps, it's pretty daunting the first time if you don't even know about main. Which suddenly makes it pretty easy. Imagine asking a front end developer to make a console app in their interview.
You do a particular type of programming. You seem to want to judge everyone else by your niche without understanding that a lot of the skills you list as essential are actually almost completely irrelevant to huge swathes of programmers. And they haven't learnt about them, because they don't need them.