5 ms·

> I'm sorry but if you don't understand most of the first ten lines of twitter.com (or any website) you're just not a senior frontend web developer. cough No t

> I'm sorry but if you don't understand most of the first ten lines of twitter.com (or any website) you're just not a senior frontend web developer. cough No true Scotsman cough I'm loving the way you are putting words in my mouth about what I do/don't know from those headers. I can explain most all of them but that doesn't stop it from being a stupid exercise. If you start a potential working relationship with me by asking me to explain 10 lines of HTML head tags then that tells me you focus on all the wrong things. By the way, I am a senior frontend web developer and I've been quite successful at it, thank you very much.

jenscow 5y ago
This is basic stuff. Perfect answers aren't required.. it's just whether or not you can have a conversation on something technical which you ought to be, according to your job title, at least vaguely familiar with. 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.
- gunapologist99 5y ago
  > 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.
  - whakim 5y ago
    I think it's unrealistic for any engineer to remain highly proficient in many of those things simultaneously. 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? I guess my point here is that proficiency teaches you some knowledge, but perhaps more importantly it provides you with context, guidance and direction when picking up new stuff (or catching up on old stuff).
    - gunapologist99 5y ago
      When referring to AWS/GCP, I said, > "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.
  - ZephyrBlu 5y ago
    > A "full-stack engineer" should be very familiar with... 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.
    - withinboredom 5y ago
tinco 5y ago
I never doubted you were. That's why I'm saying you're not serious if you say you don't know these things that you obviously do. I'm 100% sure you'd ace the first ten lines of Twitter's html question. 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.
- jkubicek 5y ago
  It's also about your communication style. If you know what an HTML tag is for, can you clearly explain it in language that's easy to understand? If you don't know what it does, do you just say that, or do you try and bullshit your way through the answer?
- BizarroLand 5y ago
  And, if I was trying to hire someone and had this type of conversation with them and they stormed off in a huff, I would be grateful. I don't want to employ people who can't get out of their own mental demesne to have the conversation that I, as an employer, want to have, and I for sure as hell would not want to hire someone who got upset that I asked them questions that they consider beneath them during the interview where the point is for me to figure out how much value you bring. 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.
  - hluska 5y ago
ALittleLight 5y ago
I don't think it's a great question, partially because there are a lot of meta tags there and it feels a bit redundant and slow, and partially because the phrase "first ten lines of Twitter's source code" makes me since - but, I don't see the problem with it. It's a basic question asking you to talk through some stuff. Test of knowledge and communication. There is a right and wrong way to evaluate to evaluate this kind of thing - e.g. "Didn't know about the direction property in the HTML node? Terrible, get out." Would be a pretty lousy interview, but there's no reason to assume the interviewer is going to do that and anyone could beat jerk with any set of interview questions. 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.
- hombre_fatal 5y ago
  These conversational questions where you talk out some code are probably the most pleasant interviews. 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.
  - nomel 5y ago
    I assume that I'm bad at interviews, but I've had people intelligently talk about code, but then completely fail at simple coding tasks. In pretty much all of the cases, they completely understood what was going on, but they were part of a team where someone else was actually implementing it all. So, I think more is needed. This seems to be great for screening though, since it can be done casually, on the phone or while eating a sandwich.
deleted 5y ago
[deleted]
ohgodplsno 5y ago
A web developer that can't explain extremely basic tags for something that is the absolute foundation of their tech does sound quite a lot like a scotsman not knowing how to speak Scottish.

jenscow 5y ago

This is basic stuff. Perfect answers aren't required.. it's just whether or not you can have a conversation on something technical which you ought to be, according to your job title, at least vaguely familiar with. 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.

gunapologist99 5y ago
> 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.
- whakim 5y ago
  I think it's unrealistic for any engineer to remain highly proficient in many of those things simultaneously. 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? I guess my point here is that proficiency teaches you some knowledge, but perhaps more importantly it provides you with context, guidance and direction when picking up new stuff (or catching up on old stuff).
  - gunapologist99 5y ago
    When referring to AWS/GCP, I said, > "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.
- ZephyrBlu 5y ago
  > A "full-stack engineer" should be very familiar with... 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.
  - withinboredom 5y ago

tinco 5y ago

I never doubted you were. That's why I'm saying you're not serious if you say you don't know these things that you obviously do. I'm 100% sure you'd ace the first ten lines of Twitter's html question. 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.

jkubicek 5y ago
It's also about your communication style. If you know what an HTML tag is for, can you clearly explain it in language that's easy to understand? If you don't know what it does, do you just say that, or do you try and bullshit your way through the answer?
BizarroLand 5y ago
And, if I was trying to hire someone and had this type of conversation with them and they stormed off in a huff, I would be grateful. I don't want to employ people who can't get out of their own mental demesne to have the conversation that I, as an employer, want to have, and I for sure as hell would not want to hire someone who got upset that I asked them questions that they consider beneath them during the interview where the point is for me to figure out how much value you bring. 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.
- hluska 5y ago

ALittleLight 5y ago

I don't think it's a great question, partially because there are a lot of meta tags there and it feels a bit redundant and slow, and partially because the phrase "first ten lines of Twitter's source code" makes me since - but, I don't see the problem with it. It's a basic question asking you to talk through some stuff. Test of knowledge and communication. There is a right and wrong way to evaluate to evaluate this kind of thing - e.g. "Didn't know about the direction property in the HTML node? Terrible, get out." Would be a pretty lousy interview, but there's no reason to assume the interviewer is going to do that and anyone could beat jerk with any set of interview questions. 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.

hombre_fatal 5y ago
These conversational questions where you talk out some code are probably the most pleasant interviews. 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.
- nomel 5y ago
  I assume that I'm bad at interviews, but I've had people intelligently talk about code, but then completely fail at simple coding tasks. In pretty much all of the cases, they completely understood what was going on, but they were part of a team where someone else was actually implementing it all. So, I think more is needed. This seems to be great for screening though, since it can be done casually, on the phone or while eating a sandwich.

deleted 5y ago

[deleted]

ohgodplsno 5y ago

A web developer that can't explain extremely basic tags for something that is the absolute foundation of their tech does sound quite a lot like a scotsman not knowing how to speak Scottish.