Hacker News Reader

Comment by peterangular | Hacker News Reader

If I'm hiring a SWE that will touch anything web I expect them to know the basics of HTTP and to be capable of referencing/digesting an RFC. It's a common interview question for these roles to outright ask, "how does the internet work?" gesturing to a whiteboard. It's a reasonable stance to take.

Overall I agree with your gate-keeping comment - that's how people interview/hire. I disagree that it "has no place" - if I'm hiring a mid-to-senior engineer that's web-capable I am 100% gate-keeping to make sure they have an intimate understanding of HTTP + are capable/comfortable reading RFCs.

View on HN

> how does the internet work?

It's like a series of tubes. That's why SWE work involves so much plumbing and getting deep into all sorts of $#!+.

While Internet is a series of tubes, SQL is a sewer: You need a lot of layers to interact with it because it’s very dirty. Real engineers have Liquibase over Hibernate and completely hide SQL from developers. Also it’s extremely slow, I don’t know why old people like it. That’s why NoSQL works better when you have large databases, like a thousand documents or more.

Also, React is not slow at displaying tables. If it’s slow, you can use plugins to hide cells which are not in the viewport.

(Old farts like me manage a billion records and display tables of 7k rows x 100 columns in a webpage in mere milliseconds, a joy that React developers will never understand. Why do you need more than 10 lines if you have pagination, they say).

I would say that if a web dev can articulate http verbs, their uses, and how to design a cohesive naming strategy and documentation scheme, that's all they need to be competent. There is no need to read the HTTP RFS for most design tasks. I can understand those requirements for Google, AWS, Facebook devs, but 90% of the work out there doesn't need that level of understanding to make something decently performant.

90% is an exaggeration. Even someone doing CRUD has to be familiar not only with HTTP verbs, but also some headers, response codes, query strings, request bodies, understand how caching works, etc, at some point. The only way to avoid it is only working for years on the simplest of projects.

They don't have to read RFCs in bed before sleep, but they should at least know the gist of what they contain.

All those things that you listed can be learned without reading the RFCs though, no? But yeah, I agree with the list you wrote. That's what I had in mind.

That's why I wrote "They don't have to read RFCs in bed before sleep, but they should at least know the gist of what they contain."

I bet this is a poor juniors interview out there:

Interview 0:

"I expect them to know the basics of HTTP and to be capable of referencing/digesting an RFC"

Interview 1:

"All devs should be up to speed on the mysterious world of character sets, encodings, Unicode, all that stuff"

Interview 2:

"Any real programmer can reverse a string in C without a buffer"

Interview 3:

"I expect anyone working with k8s to understand the cgroup fundamentals."

Interview 4:

"No really. What is html5?"

Why would you need to be capable of referencing a HTTP RFC?

Are you doing something fancy with HTTP?

Would it count as “fancy” to find out whether header names are case sensitive? Plenty of useful things in there.

I certainly don't think that's a thing someone needs to know to be a useful web developer. I've certainly never needed to care, although I wouldn't classify myself as web in particular.

I've never needed to look up if headers were case sensitive, it's just never caused an issue in my 10 years experience.

Referencing, no. But being able to look up the answer to an tricky edge case in the RFC is a valuable skill

Thats a really odd set of things to gatekeep on.

What, fundamental knowledge and capability?

Fundamental for those whose job is building web servers, sure. Id expect nothing less from the authors of apache, nginx, etc.

Reply on news.ycombinator.com