I would think that if you would walk out of an interview if the interviewer asked you basic questions then those questions have done their job.

It’s not a quiz, if done right. But you can get to know a lot about someone even by how they respond to not knowing the answer.

Someone with experience knows it’s not a big deal to not know every bit of trivia, but they can talk intelligently about what the code might do. And they know how to find out.

For example, they may point out they know about charset=utf8 in the Content-Type header and admit they thought the meta tag was redundant, and you can have a conversation from there. Or how about "I know 'ltr' means left to right but I never thought about using it with lang=en, but now I want to see what 'rtl' does with English". I suppose it's not the best starter question, but I don't think it needs to be to suss out good candidates from bad ones.

Rage-quitting the interview or blurting out confidently wrong guesses, on the other hand, are bad signals.

I want to hire you, not someone who's never really thought about what's going on. These questions are just a trick to force someone to step out of the box and go deep into some fundamental web concepts. It's not about memorizing some HTML tags, it's about knowing why they exist.

edit: This is just in the hypothetical scenario I'd be hiring a senior frontend web developer. You generally only need maybe 30% of those, the rest I can get trained on developing features within 3 months after finishing a 10 week bootcamp. I wouldn't bother asking them how UTF-8 works, I just explained what the word "encoding" means to a junior who'se been outpacing me for the past 3 months. The person who reviews their merge request should definitely know what UTF-8 is.

The ground is beneath you too but you would fall to your roasty death in the center of the planet if it wasn't there, and if you have a gaping hole in your knowledge base then identifying and resolving it before some portion of the companies' success is resting on your too-narrow shoulders is a good idea.

I'd much rather work with and for any of the people replying than you.

Nobody cares about text-size-adjust and other such nonsense. It doesn't materially change anything.

If someone said that to me in an interview my next question would be "Why did you apply for a senior frontend dev role then?"

Nobody cares about text-size-adjust and other such nonsense.

Senuor frontend devs do care about that, because it affects the display quality, accessibility, and readability of a web app on a mobile device. If you get text size wrong on a site like Amazon or Twitter you could push tens of thousands of people to stop engaging with the site. Imagine if the "Buy Now" text on a button overflowed because the font was too big so it read "Buy no" instead. That would have an impact on revenue.

Don't take this type of exercise personally; it's not aimed at you - it's aimed at the many people who call themselves "full-stack engineers", but haven't ventured beyond the bounds of a particular framework.

That's a great point. Lots of people think that full-stack means knowing how to use npm to install tailwind and express. They just don't know what they don't know.

A "full-stack engineer" should be very familiar with standards like TCP/IP, HTTP headers, the OSI model, CSS things like flexbox, DOM, CORS, SQL, websockets/eventsource, unicode etc etc as well as probably multiple web frameworks in multiple languages, various backend and cloud platforms (at least enough to get around in) like AWS and GCP, and understand what proxies and TLS are and what they do, and probably also how to do things like Let's Encrypt and write secure code with XSS, CSRF, etc hardening.

Obviously, everything is a gradient, and nobody is perfect with everything (as well as the JS build tool of the week) but this stuff takes years and perhaps decades to really grok. There's nothing wrong with being a "junior dev", or just a "dev", or whatever -- it takes a lot of effort to master your craft, especially when you're crossing multiple domains from front-end to back-end to security to architecture. But it is important to know where you best fit in, at least at whatever your current career stage is.

> "at least enough to get around in"

Because, you're right -- cloud-based knowledge changes a lot faster (and gets wider) than standards-based, and it's actually a lot less useful because you don't know from year to year if the knowledge is even still relevant or if the product is still supported.

And, yes, you do need to keep standards-based knowledge top-of-mind, even if you perhaps are not currently building projects on them and even if you can't remember the specifics of syntax etc. Knowing every tool in your toolbox will make you a far better engineer, and, yes, it absolutely can be done.

That person doesn't exist, gradient or not. There's no way for someone to be "very familiar" with so many different domains at the same time. By the time you gain familiarity with all the domains, the information you initially learned will be out of date or you will have forgotten.

Also, full-stack colloquially refers to someone who can work on frontend and backend.

It takes a lot of time work to stay on top of these things but it’s a passion, and some things I know exist but don’t know the current incantation for (like getting full screen access for a game engine). It used to be quite long, but I think it’s much less LoC these days. Anyway… we do exist.

Like I said, for me it’s a passion. It probably won’t come up in an interview unless it’s a startup and the job sounds incredibly interesting. Even then I might keep my mouth shut just to not come across as over-qualified or “too expensive.”

Since that isn't possible I have to assume that you have a different definition of "very familiar" than I do.

On my free time, I work on various things like building a cockpit for a flight sim, building my own Bluetooth door lock, learning new languages and frameworks, creating SDKs for my favorite language to popular services, etc.

Oh but I don’t know how to do SRE. No interest.

I also have no interest in an SRE role. I don’t like being on-call. I build systems to fail gracefully so I never work weekends, but most people don’t do that for some reason.

I currently work as a SWE. We don’t have explicit roles where I work, but my responsibilities are in-line with a principal or lead engineer.

I consider myself a mediocre senior web dev, and I am can humbly say that I'm very familiar with all of the listed, without intentional effort in that direction over the years, simply because I wanted to understand the context of some of the things I needed to do, and also poke into each enough to understand how much depth there is and what I don't know. It is natural that it tends to add up.

Over the years, I saw a strong correlation between that breadth and how "good" someone was - on the example of someone working on the fronted in a team, I see 3 basic categories:

1) Not very good: I can do only the most direct and specified things and if something doesn't go as implementation plan intended, or requires outside of what I see as my "formal scope" (e.g. "frontend developer", so React + CSS), I expect someone to solve it so I can continue

2) Ok, but limited: I do only the things inside my "formal scope", so if I'm building a frontend to a web app, it's someone else's responsibility to think about e.g. security - but when something doesn't go as planned along my line of work, I'll find why and unblock it

3) Good: We're building a web app, what are all the things it needs to consider and achieve? My part in the team is this UI / frontend, but if security is important for this use-case, how will my frontend be cognizant of the security goals? I should read up that OSI thing I heard about, cover the basics on my side, and start the discussion on it so we as a team ensure the frontend part is good security-wise

To me this is not equivalent to "very familiar". I think whakim's comment puts things well:

> I use AWS day-to-day, but haven't used GCP day-to-day in 5+ years - should I realistically be able to keep abreast of the vast number of GCP changes that have happened over that time (plus all the changes in devops that make the workflows I was using 10 years ago look outdated)? Many projects don't need Websockets or Eventsource - do I have to keep that knowledge top-of-mind across the years that I don't use them? Can you really claim that you're "very familiar" with that web framework that you used two jobs ago - assuming there haven't been a bunch of major changes since then?

https://news.ycombinator.com/item?id=30474206

Just because you've never met one doesn't mean they don't exist.

However, often, people like this (sadly) move into management or into higher-level architecture types of roles, and let their tech skills go fallow.