8 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. He's not aski

• joshstrange 5y ago
  > 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.
  • 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.
• munk-a 5y ago
  I'd strongly dispute this point - these tags need to (usually) be written once per organization, occasionally you need to come in and fiddle with it, but the contents of your page header should occupy no brainspace. Additionally I think this interview question might be testing a depth of knowledge, but not one that's actually relevant for your position. I've worked on backend systems for most of my life (that and databases) and I can definitely name the purpose of most of these tags since, back before node, I'd just be popping them out in some PHP file somewhere - again, once written and then mostly forgotten about. If the job responsibilities are going to involve a modern front-end framework/language suite and your interview isn't even touching on that topic then you're not effectively interviewing for the position - you're querying about some corollary information that most people in the space will sort of know but, if I was their manager, I'd be happy as a clam if they popped over to the MDN and copy-pasted a big chunk of this as a starting point... assuming they ever actually needed to interact with it.
  • grumple 5y ago
    Not only do these get written once per organization, but they are specific to that organization. With the exception of the doctype, html tag, viewport, and charset, we use none of the rest. And our attribute usage differs.
  • Jorge1o1 5y ago
    That’s exactly why it’s such a bad interview question, regardless of how “fundamental” it is to a website, changing the HTML <head> tags will never be within the new hire’s scope of work. They will basically never ever in their entire career need to do this. It’s like hiring a C++ developer by quizzing them on random gcc flags. These are things that make up 0.00001% of the total work produced by the dev.
    • redonyo 5y ago
      Now I'm thinking its a good idea to quiz developers on the first 10 lines of some arbitrary Makefile
  • pythonaut_16 5y ago
• Jare 5y ago
  > What needs to be tested is how well do you know your domain I pretty much never look for this in an interview, outside of specific claims from the candidate, specific needs for the position, or the bare minimum. I try to evaluate candidates for their ability to think, reason and operate in a domain. Knowledge is easy to acquire and useless in the face of changing tech.
  • devoutsalsa 5y ago
    Ask me questions I can't answer using Google. If you do ask me questions I can Google, let me answer the what I can from memory & give me points for looking up the rest.
  • nomel 5y ago
    I think this only works if management has enough foresight to hire before the person is actually needed, to allow for ramp up. Unfortunately, I've never seen this, so the person needs to be able to hit the ground running, meaning general intelligence is put to the side, which really sucks.
• deleted 5y ago
  [deleted]
• deleted 5y ago
  [deleted]
• jtchang 5y ago
  Is this sarcasm?
• svachalek 5y ago
  Wow, there seems to be a consensus that being able to read an entire HTML file is not a reasonable expectation of a senior frontend engineer. That's news to me, and honestly I can't imagine how narrow the job definition must be if it doesn't include a working understanding of page headers.
  • ge96 5y ago
    It's auto filled ha ! then tab (emmet). To me though most important is that viewport scale 1 and similar tangent, using offsetWidth for Mac's higher DPI screen.
  • june_twenty 5y ago
    Senior engineers duties including mentoring juniors, working with managers and architects, setting and maintaining the technical direction of a project, having input into planning etc etc etc. Talking about the first 10 lines of a website and seniors is laughable.
  • jrockway 5y ago
    I don't think there's a consensus. This is a totally fine interview question. If you read a thread on hiring, you'll learn that you can't ask a coding question, you can't do a take-home coding test, you can't talk through system design, you can't expect people to have a Github or portfolio, and you certainly can't rely on academic credentials. At that point, it sounds like you have to hire the first person that responds to your want ad, and I'm sure someone is against that too. The only consensus is that people that care strongly one way or another will write a comment. Those that don't really care just go read some other article ;)
  • gedy 5y ago
    "but, but leetcode cramming didn't prepare me for this!" /s
  • ZephyrBlu 5y ago
    Unless you are hired for a very specific function, why would testing specific knowledge be useful? The way I see a Senior is someone who can autonomously get shit done. How does testing for specific knowledge help determine if someone is capable of solving problems autonomously? If they don't have knowledge they should be able to seek it out.
• deleted 5y ago
  [deleted]
• deleted 5y ago
  [deleted]
• lhorie 5y ago
  FWIW, the article said this is a question they use for a senior full stack role, not a frontend specialist role. With that in mind, the question does seem a bit badly formulated. For example, why would you ask about tags that you know through calibration that nobody will answer satisfactorily? And if you're already gathering signals about frontend specialization fluency by discussing web vitals, accessibility and other topics that would already establish competence, then why continue to get into these trivia style questions? Seems like a bit of a waste of time. One potential problem with this approach of trivia checkbox ticking is that you could be selecting for "mini me" candidates, meaning that you're overfitting for the skillset you already have. For example, maybe the candidate is "full stack" from a primarily backend background, but you're formulating questions like this because you have a frontend background. But then they might seem less qualified than a mid-level frontend-only person because the interview was focusing on frontend, even though stronger expertise on backend would complement your current skill pool better.