[HN Gopher] Explain the first 10 lines of Twitter's source code ...
___________________________________________________________________
Explain the first 10 lines of Twitter's source code to me
Author : ohjeez
Score : 126 points
Date : 2022-02-25 16:11 UTC (6 hours ago)
(HTM) web link (css-tricks.com)
(TXT) w3m dump (css-tricks.com)
| paxys wrote:
| I was going to say what's the point of asking such basic, obvious
| questions, but reading the replies in this thread - yikes! If you
| cannot answer at least 7-8 of the 10 questions in under a minute,
| you have no business being a web developer, forget calling
| yourself a "senior" one. If I was an interviewer in this
| situation, I'd be perfectly happy with a candidate who thinks
| they are too good for this walking away and taking their
| framework-of-the-month skills elsewhere.
| jenscow wrote:
| Such responses actually highlight the need for us to do basic
| checks like this.
| missblit wrote:
| So... how did I do? ;)
|
| ---
|
| <!DOCTYPE html> is a magic string that indicates the document
| should be parsed as an HTML5 document (possibly avoiding quirks
| mode too? I don't remember what triggers that).
|
| "Doctype" comes from the XML concept, and XHTML documents may
| have a different doctype.
|
| <html> is the document's root element. It's supposed to be there
| but the browser will create it if you leave it off.
|
| ltr means the document direction is left to right. direction here
| refers to the direction of lines (e.g. in English lines go left
| to right, in Arabic lines go right to left). There's another
| value that influences writing mode too below the document level,
| but I forget what it's called.
|
| Browser implementers and webmasters have to be careful with a non
| RTL direction; as it changes the scrolling element origin, the
| browser will have to deal with logical vs physical coordinates,
| and scrollX may go negative. I believe scrollX was reconciled
| across the different browsers fairly recently.
|
| The meta tags tell you metadata about the document. I believe
| they're supposed to go in the head section, but again the browser
| will create that for you if you don't.
|
| lang just tells you the language of the page. I'm not familiar
| with what this is used for, but you could imagine a search engine
| using it for one thing (e.g. Google's "display only results in
| English").
|
| The two letter country code comes from some standard I don't
| remember the name of. Also used in TLDs. Watch out for easy to
| confuse countries like cn, ca. Some websites like to use the
| trendy .io TLD, but I heard rumors it wasn't run very well.
|
| charset="utf-8" means the document's bytes should be treated as
| unicode. Note that this meta tag should occur in the first 1024
| bytes of the document or browsers may not notice it. Without
| specifying the charset the browser will likely fall back to... I
| think latin1?
|
| Anyway I read once that browsers don't get too fancy with the
| encoding detection on purpose, to avoid people relying on
| unreliable heuristics.
|
| Another interesting point is that Chrome can load utf-8 documents
| as utf-8 without a metatag if it's a file:// URL. I guess
| conceptually this is because local files can't specify the
| encoding in HTTP headers or something?
|
| Viewport specifies the responsive sizing behavior. This is
| described in the CSS Device Adaptation Level 3 spec; but the
| section on actually parsing this tag is pretty gnarly. If I
| remember right it was a non-normative section and had a few weird
| corners that were likely left over from matching browser
| implementation quirks.
|
| Anyway you need the viewport for responsive viewport sizing. 99%
| of the time you can just copy-paste the usual string and don't
| need to get fancy with custom values or anything. There's also a
| newer way to specify the viewport behavior through CSS (and
| indeed Chrome basically converts the meta tag to this
| internally), but it didn't really work right last time I tried
| it.
|
| "og:" is from some semantic web standard. I never learned the
| details, but basically it tells crawlers some basic information
| about the page's contents.
|
| For the remaining lines; presumably Safari recognize some custom
| meta tags to change Apple device theming. The "origin-trial" may
| refer to Chrome (or Safari?) origin-trials, where webpages can
| opt into (or sometimes out of) experimental browser behavior.
|
| Line 10 is CSS. Presumably there was a <style> tag off the right
| end of the screenshot on line 9.
|
| Interesting point about CSS or JS embedded in HTML:
|
| This actually changes the parser's language from HTML parsing to
| CSS or JS parsing on the fly. But with a special rule to look for
| the end tag and switch back to HTML. This is why you'll see
| people break up the string "<script/>" if they have to embed it
| in JS embedded in HTML.
|
| But my favorite is the <plaintext> tag which switches the parser
| to... plaintext. Unlike CSS or JS there is no special escape-
| hatch and it's just plaintext for the rest of the document.
|
| Speaking of embedded languages: SVGs have a title element but it
| isn't the document's title element. Poorly written browsers or
| crawlers could confuse the SVG title with the document title if
| they don't have an understanding of tag namespaces (another relic
| from XML perhaps?!)
| tjungblut wrote:
| > Another interesting point is that Chrome can load utf-8
| documents as utf-8 without a metatag if it's a file:// URL. I
| guess conceptually this is because local files can't specify
| the encoding in HTTP headers or something?
|
| You can guess the encoding after reading a few bytes from the
| request. Checkout universalchardet from Mozilla or the
| equivalent Java port:
| https://github.com/albfernandez/juniversalchardet
|
| By the time the meta tag is parsed, you almost always know the
| right encoding already.
| missblit wrote:
| So actually reading the post now:
|
| > People even used to use * { margin: 0 } which is totally
| overkill and not great for performance.
|
| Wait why would that be bad for performance? Zero margins should
| be just as fast as 8px margins, and if you have this style in
| the head section it's not like the browser will have to
| relayout a bunch of stuff.
| enkrs wrote:
| The argument on performance comes from the idea that
| theoretically the rules are applied in order. So the browser
| has built in stylesheet of 8px, and after that a margin of 0
| is calculated. (And after that, some more specific margin in
| the stylesheet is recalculated)
|
| Basically * { margin: anything } adds one extra calculation
| to each element in the page.
|
| Not sure if the performace hit is measurable tough, knowing
| how much optimization goes into browser engines.
| csnover wrote:
| The universal selector has the potential to be slower than
| other selectors in naive CSS engines because CSS works by
| matching selectors from the right to the left. A rule like
| `.baz *` matches _every element_ on the page (vs something
| like `.baz .foo` which only matches elements with `.foo`).
| The match is only rejected after walking up the DOM tree to
| the root node to see if any parent elements have the `.baz`
| class or not.
|
| In the case of a single universal selector, there is no
| performance issue, the selector just matches every element,
| which is fine.
|
| In modern engines, there is also no performance issue, they
| JIT compile selectors[0] and do other stuff to be fast. Even
| old engines wouldn't really have a performance issue in
| practice unless you were doing something else bad, like
| having extremely deep DOM trees with extremely large numbers
| of elements.
|
| [0] https://webkit.org/blog/3271/webkit-css-selector-jit-
| compile...
| ejb999 wrote:
| Its interview questions like this that makes me never interview
| for a new job. I get jobs when I need them pretty easily, but
| usually just through someone who already knows me and/or worked
| with me before and skip the silly interview questions like this.
| RandallBrown wrote:
| What don't you like about this question?
|
| The author isn't looking for exact right answers and just wants
| a discussion about the technology to gauge your skill.
|
| I enjoy interviews like this.
| heavyset_go wrote:
| Quizzing on trivia, especially minutia that can be looked up and
| fully understood in less than 2 minutes, seems like a waste of
| time to me on the interviewer's part.
|
| I also find it strange to pick apart and quiz on the messy output
| of Twitter's frontend frameworks, compilers/transpilers,
| minifiers, bundlers, etc. It's akin to feeding a binary or some
| bytecode into a decompiler and quizzing on its output.
| iratewizard wrote:
| The best questions are the simple ones that start a
| conversation. That only works if the interviewer is confident
| in their ability to read people and competent at their job.
| These articles are written by and for people who don't meet
| those criteria.
| heavyset_go wrote:
| I just don't see the value in the questions from the OP. What
| if the person being interviewed genuinely doesn't know and
| says, "I don't know"? Asking them to then guess what the
| markup could mean doesn't really tell you much about their
| skills or abilities. It feels like a potential dead end to
| me. I think there is better material to review and ask
| questions about that actually pertains to the abilities of
| the interviewee or the skills needed for the job at hand.
| tgsovlerkhgsel wrote:
| There's 10 lines.
|
| If they're applying for a web development role and say "I
| don't know" to _all_ of them, it tells me enough about
| their skills and abilities to end the interview right
| there.
|
| If they don't know half of the trivia but tell me "this
| looks like it probably controls browser feature X", and
| they're making a _reasonable_ guess (regardless whether it
| is correct or not), that 's a good sign.
|
| If they don't know something but confidently pretend they
| know and spurt bullshit - red flag. I don't want to have to
| second-guess everything they say, and have them deliver
| something that looks right while being completely wrong.
|
| If you don't know what that specific prefixed attribute
| does, I don't care. If you don't know what a vendor prefix
| is in CSS, you haven't written much CSS.
| paxys wrote:
| Knowing what a <html> tag is is _very_ far from trivia. If
| someone fails to answer at least ~7 of 10 questions in this
| interview, there 's really no point in continuing on. I'd call
| it an excellent filter.
| irrational wrote:
| Why are lines 10+ not inside of a <style> tag? I wasn't aware you
| could put CSS into the document without being in a <style> tag.
|
| Also, why does the document not have a <head> tag? And, why does
| it not have a <title> tag?
|
| It appears that many things that I thought were normal to put
| into an html page are not.
| reaperducer wrote:
| _It appears that many things that I thought were normal to put
| into an html page are not._
|
| Those are normal things, but some companies like to deviate,
| often just to be different. For example, Google uses a Unicode
| lightning bolt as its DOCTYPE for Amp pages.
|
| However, saving 100 bytes on a page load can end up being
| actual money saved when you shove out as many pages as Twitter
| does in a month.
| irrational wrote:
| Saving bytes makes sense. But how does the rendering engine
| know that those lines are CSS instead of junk text? And
| without a head tag, how do those lines not end up as text in
| the body of the document? And isn't it strange that it
| doesn't have a title tag (though, if you aren't going to have
| a head section, maybe skipping the title tag makes sense
| too).
| hartator wrote:
| I think this might weed out more junior but very promising
| profiles.
|
| And remembering the Netscape days and why of each meta "hacks"
| might be a little tricky even for very senior profiles.
| Sohcahtoa82 wrote:
| > Twitter also applies user-scalable=0 which, as the name
| suggests, disables the ability to zoom
|
| I want to revoke the keyboard from whoever decided this is a
| feature.
|
| I understand removing features in order to clean up a UI, but
| this serves no such purpose. It's purely removing a feature
| because you think you know what the user wants, despite there
| being no negatives to leaving the feature enabled.
| tgsovlerkhgsel wrote:
| Check your browser settings under accessibility. It makes sense
| for most users to allow sites to disable this, because users
| accidentally zoom (especially by double-tapping) making the web
| app feel non-native and broken. But I believe most browsers let
| you tell them that you always want to be able to zoom, and then
| they ignore this setting.
|
| Providing it as a setting has the advantage that developers
| just set it (and you can tell your browser to ignore it),
| instead of finding some horrifying and harder-to-avoid way of
| preventing the browser from zooming.
| savrajsingh wrote:
| WebKit ignores this, I can resize Twitter no prob
| https://webkit.org/blog/7367/new-interaction-behaviors-in-io...
| Forge36 wrote:
| I assumed my accessibility settings were overriding this.
| Enough websites had disabled zoom I turned it on.
| munk-a wrote:
| Ditto for everyone who has ever written code to stop me from
| copying text - they're obnoxious anti-features.
| buro9 wrote:
| I'm an old-timer and mostly backend now... I knew all but one of
| these lines. But the chances of me now being able to make a
| website based on modern frontend frameworks is near zero.
| scrozier wrote:
| I've been doing web development since the web began, literally.
| The percentage of my time that I've cared about the stuff in this
| header is approximately .000047%. And when I do care, I can look
| it up and reacquaint myself. A full stack developer has so many
| things to know. This is representative of the kinds of questions
| that make interviewing so awful these days.
|
| Oh, and I've interviewed hundreds of front end developers, so
| I've been on both sides of the table.
| fleddr wrote:
| The comments in this article are embarrassing. It shows none of
| you have even basic reading comprehension. Either you didn't read
| the article at all or not very carefully:
|
| "So, instead, we have an hour-long technical discussion where I
| ask them questions about web vitals, accessibility, the browser
| wars, and other similar topics about the web. One of the
| questions I always like to ask is..."
|
| It's ONE of the questions, so those concluding it's a terrible
| interview altogether are dramatizing.
|
| As for the question being relevant or not, I think it actually
| does say a lot about a developer. Just those few lines of code
| show historic knowledge, internationalization, SEO and social
| networks, mobile optimization, CSS normalization, and bleeding
| edge features (origin-trial).
|
| In that sense it's an effective question. You learn a lot about
| someone with little code, even if the understanding of some
| individual lines is not a showstopper.
|
| Finally, saying that your framework usually generates this for
| you isn't the great answer you think it is.
| pwdisswordfish9 wrote:
| With that title, I would have expected an analysis of leaked
| backend code.
| [deleted]
| kabes wrote:
| So his way to test a full-stack javascript developer is to let
| someone explain 10 lines of which none is javascript.
| zamadatix wrote:
| If you position yourself as a full stack JavaScript developer
| and you think talking to 10 lines of non-JS front end code is
| too much out of a 1 hour long interview I'd be extremely
| suspicious of how much time you've spent on the front end half
| of JavaScript integration.
| cogman10 wrote:
| The issue I have with this test is it tells you nothing about
| the person you are interviewing.
|
| When would you actually create such tags as a fullstack dev?
| Almost never. 90% of the time, those tags are auto generated
| by some boiler plate app.
|
| A person that can answer correctly MIGHT be someone that's
| looked into those tags and done things the hard way, but is
| that really someone you need to hire? A person that answers
| incorrectly doesn't necessarily seem like someone I wouldn't
| hire. After all, what do I care about someone knowing the
| intricate details of the "html" tag and how it interacts with
| various browsers? That's write once and forget sort of code.
|
| If you wanted this test to mean anything, why are you picking
| worthless trivia. Why not, instead, pick something like a
| function out of jquery or your own code base and ask the same
| question "Tell me what this function is doing".
| irrational wrote:
| > 90% of the time, those tags are auto generated by some
| boiler plate app.
|
| Well, that's a problem. If you don't know how to create a
| web page with out having to fall back to using "some boiler
| plate app", I question if you really are a fullstack
| developer (I would also question if you really can consider
| yourself a web developer at all, but I know that will just
| upset people, so I won't go there).
| zamadatix wrote:
| "Explain the first ten or so lines of the Twitter source
| code to me." doesn't read to me like a test, it reads like
| an opener. Sure, it's possible to show off you know 100% of
| the trivia for the tags that show up... but more so it's an
| opener for you to talk to about how much background you
| know, how much you can relate what you didn't know to
| things you did or have worked on, and how much you've
| bothered to go beyond "that boilerplate is generated for
| me" and look into what the first few lines of the webpages
| you work on do.
|
| The point does not at all seem to be "Aha, gotcha! You
| didn't know about the syntax for Apple's limited PWA like
| functionality offhand in an interview. 5 demerits, next
| question!".
|
| A person that can hold a good discussion around these tags
| is both likely to be one that has truly been developing
| pages for a couple of years and has an interest in learning
| more than how to make their framework work rather how to
| make any framework work in a browser. If you're not able to
| say something cursory about language attributes I'm going
| to have a hard time believing you've full-stacked a multi-
| language website (not that I wouldn't but it'd lead to a
| lot of different questions later). If your response about
| the doctype line is "it's boilerplate put in by my IDE" my
| first thought isn't going to be "oh they just spend a lot
| of time writing code in the rest of the page" it's going to
| be "they either don't care what the first line of the page
| is about or it's been so long since they've touch the front
| end directly they can't say anything about the first tag. I
| wonder how well they can deal with integrating the front
| end JS with the page" and steer to towards more about that.
|
| Also the interview was mentioned to be an hour long, if 10
| lines of HTML boilerplate, most of which should be on every
| page, is too far into the weeds of front end time wise then
| I'd have severe concerns the candidate would be too back-
| end heavy. Yes, other things should be talked about too,
| that's why the interview is an hour and this singular
| question is only about 10 lines.
| ZeroGravitas wrote:
| I thought "full-stack" implied you understood the front-end web
| environment?
| Viliam1234 wrote:
| > A full-stack developer should be able to change a diaper,
| plan an invasion, butcher a hog, conn a ship, design a
| building, write a sonnet, balance accounts, build a wall, set
| a bone, comfort the dying, take orders, give orders,
| cooperate, act alone, solve equations, analyze a new problem,
| pitch manure, program a computer, cook a tasty meal, fight
| efficiently, die gallantly. Specialization is for junior
| developers.
|
| -- Robert A. Heinlein
| y42 wrote:
| I'd say that's legit, considering what he is looking for - full
| stack. JavaScript is strongly connected to the term
| WebDevelopment and thus to HTML. That's just basic knowledge.
| kabes wrote:
| Sure, but it also means being skilled in writing Node
| backends and I'm doubtful if knowing what some meta tags mean
| is a good indicator for that.
|
| This is the equivalent of interviewing for a C developer by
| letting him explain a Makefile.
| jbki1121 wrote:
| what's wrong with that? surely a c developer would know
| their tools. I wouldn't call it a stretch to ask if a java
| developer could explain maven
| cogman10 wrote:
| Pretty much the same thing that would be wrong with
| asking a javascript dev to explain grunt.
|
| What if that C++ dev primarily uses visual C++ and Visual
| studios projects? What if the C++ dev primarily used
| Cmake, ninja, or scion (or any of the other thousands of
| C++ build tools).
|
| What if that C++ dev never really needed to start a
| project from scratch?
|
| The issue is testing someone on minutia doesn't tell you
| anything about how capable they are. In particular,
| testing them on minutia that they very likely rarely
| interact with is beyond pointless.
| ripley12 wrote:
| > What if that C++ dev primarily uses visual C++ and
| Visual studios projects? What if the C++ dev primarily
| used Cmake, ninja, or scion (or any of the other
| thousands of C++ build tools).
|
| Then it's an opportunity for the candidate to explain the
| tools they _do_ use.
|
| There are certainly bad interviewers out there who misuse
| these kinds of questions, but I think they're fine if
| used as conversation starters.
| jbki1121 wrote:
| if it makes any difference, I was referring to C, for
| which Make is the majority, I think - could be wrong,
| though, since I'm not a c developer.
|
| But to the point, I'm not sure if the code at issue would
| be considered minutiae or not, but I believe that the
| more curious you are, the more you tend to dig into the
| details, and a person doing this over many years would
| attain a rich knowledge-base spanning depth and breadth.
| I know as a java developer that I've referred innumerable
| times the docs for the POM and settings structure in
| order to explore the limits of customizing my build,
| which would include the rather obscure features. Not
| saying this is technically comparable to meta tags in
| html, but maybe that's what the author was going for.
| whateveracct wrote:
| It's not that they can't technically answer it.
|
| It's that the signal you're gonna get out of such an
| interview is gonna be so low that whoever you end up
| hiring is mostly going to be due to chance + how much you
| "liked" them.
| [deleted]
| RGamma wrote:
| Self-description about the business that is mentioned in the
| first sentence: "Beautiful interior design for your home with the
| flexibility to /rent/ or buy the furniture you love"
|
| Renting furniture... Isn't it weird* how the right to own drives
| capitalism which spawns businesses that thrive on you not owning
| the things they sell you?
|
| * read: perverse
| new_guy wrote:
| That seems a pretty basic question for a senior position, it's
| weird the author says most candidates failed it.
| leftnode wrote:
| "Senior" developers tend to waaaaaay overestimate their
| abilities, unfortunately.
| kache_ wrote:
| My expectations for people cratered after I began interviewing.
| It's.. incredible.. how untechnical people applying for highly
| technical positions can be.
| lghh wrote:
| How is not knowing something unethical?
|
| [EDIT] - they said "untechnical", not unethical.
| hknapp wrote:
| un - technical
| InvaderFizz wrote:
| Agreed. It's sad how many SRE candidates are positioning
| themselves as senior and end up being someone with basically
| nothing more than surface level knowledge of AWS manages
| services.
|
| I have a relatively similar approach as the article:
|
| 1. I have them walk me through a production dockerfile and
| explain what is going on (it is not a very complex
| dockerfile).
|
| 2. I have them troubleshoot a broken web server with the most
| basic scenario (public web server that we run, ec2 with
| apache2, public ip, no load balancers, no cdn, just a VM
| serving a static html page on xyz.actualdomain.com).
|
| Things that are broken:
|
| 1. NXDOMAIN (I make sure to unset the DNS before the
| interview)
|
| 2. Security group isn't allowing 80/443
|
| 3. NACL isn't allowing egress
|
| 4. iptables isn't allowing 80/443
|
| 5. Apache2 is stopped
|
| 6. Apache2 is bound to 127.0.0.1:80/443
|
| 7. Self signed TLS
|
| I don't require specific incantations, I know I can't write
| the iptables insert without looking up an example. But I do
| expect candidates to know where and what to look for to
| troubleshoot the entire chain. They are allowed to run any
| command they want (I'm running it on a screen share). If they
| get stuck on a portion, they get some hints, then finally
| they get given the answer to get past it. My goal is not a
| gotcha, my goal is to see how they attack the problem and if
| they are at least familiar with how things can break and have
| guesses at fixes.
|
| Fully a third of interviewees get stuck on NXDOMAIN, which is
| just shocking to me interviewing people that, on paper, have
| over a decade of deep Linux and cloud experience.
|
| To me, the scenario I present is basic troubleshooting and
| something that should be a breeze for most candidates.
| jaywalk wrote:
| So many people have the idea that "senior" is just someone
| who's been doing it for a long enough time.
| dgritsko wrote:
| It feels kinda reminiscent of a "FizzBuzz" type of question,
| serving as a litmus test or catalyst for an informal
| conversation rather than anything strictly defined.
| Taylor_OD wrote:
| Ah. FizzBuzz the destroyer.
| sontek wrote:
| I saw a tweet yesterday where someone with 4 years of
| experience was looking for a Staff Engineer position. One thing
| the engineering community doesn't lack is confidence in our
| abilities, even if we aren't there yet.
| sockpuppet69 wrote:
| kache_ wrote:
| I've seen interns perform better than "Staff Engineers" at
| some companies.
|
| Leveling is purely a function of leverage and nothing else.
| I'm ~4yoe and I find myself in meetings pretty much entirely
| populated by staff engineers. I've seen kids come right out
| of waterloo with more skills & knowledge than I think I'll
| ever manage to get. I've seen people get to Staff at FANG
| before 27
|
| Anything is possible, just get good :)
| jandrese wrote:
| > <html dir="ltr" lang="en">
|
| This one surprised me a bit. Are there browsers that are default
| Right-to-Left rendering and are going to put English language
| characters backwards if you don't specify the direction?
| dymk wrote:
| There's probably a line of code that looks like this:
|
| > echo('<html dir="$dir" lang="$lang">')
|
| (or something similar), and they unconditionally include the
| `dir` attribute without checking if it's already set to the
| default value a browser would assume.
| j-krieger wrote:
| No, but a screen reader that has set rtl as a default _might_.
| missblit wrote:
| Per https://html.spec.whatwg.org/multipage/dom.html#the-dir-
| attr... it'll default to LTR
|
| > The directionality of an element (any element, not just an
| HTML element) is either 'ltr' or 'rtl', and is determined as
| per the first appropriate set of steps from the following list:
|
| > ... If the element is a document element and the dir
| attribute is not in a defined state (i.e. it is not present or
| has an invalid value) ...
|
| > ... The directionality of the element is 'ltr'.
|
| It's not that common to see LTR explicitly specified for the
| document, but you could imagine some code that either outputs
| ltr or rtl based on the user's preferences. (Indeed I just
| checked and twitter puts a rtl there if you're using it in
| Arabic)
| dpweb wrote:
| I think I'd enjoy this interview, as I don't really like people
| watching me code.
|
| But to have a discussion about quirky html history would be a fun
| (I think less stressful) way to spend the time.
| joshstrange wrote:
| I'm sorry but if a place I was interviewing for asked me this I'd
| end the interview and move on. This is about as useful as knowing
| how to write C boilerplate on paper from memory (something a
| college professor had us do for an exam), which is to say it's
| completely useless.
|
| > The first line of every document's source code is perfect for
| this interview because how much a candidate knows about the
| DOCTYPE declaration closely resembles how many years of
| experience they have.
|
| This just screams "I have some esoteric knowledge and I'm going
| to lord it over you", sure I remember vaguely when the html
| doctype first came out but knowing what that does doesn't make me
| a better programmer. I write that line 1 time max in a project
| and then never think about it again. Why would you ever harp on
| that? Especially when most frameworks your are going to be using
| handle that all for you or it's in the default header
| block/index.html?
|
| Talk to me about how I'd solve a problem or how I'd architect
| something but don't quiz me stuff I rarely need to know. Even PHP
| argument order (a near-useless skill) is more useful than this
| list. Give me 5 minutes on google and I'll tell you what every
| single one of the tags mean/do (the ones I might not know off the
| top of my head), that's a way more important skill then being
| able to spout off what they are from memory.
| ASalazarMX wrote:
| I'll gladly admit that creating boilerplate from memory is a
| low-value skill, but you absolutely must know why it is there,
| and what does it do.
|
| Through the eyes of the interviewer, you googling those tags
| means you don't know what they do. If you were hired and for
| some reason had to change those tags, what is the chance that
| you'll just google and copy/paste? (again, through the eyes of
| the interviewer)
|
| To be fair, not all people work the same way. Some are happy to
| swim through the mountain of knowledge that web development has
| become these days, others are happier specializing in a subset
| of web development, and others will prefer to diversify their
| knowledge outside of web development, which means wider breadth
| in exchange for lesser depth. The interviewed should make sure
| to clearly transmit how he works, so the interviewer doesn't
| have to make too many assumptions.
| jollybean wrote:
| It's not 'useless' and it doesn't scream 'knowledge signalling'
| - it's just not a very good question.
| chrismarlow9 wrote:
| Yeah I'd only ask that question if I was interviewing people to
| work at w3.org.
|
| The years of experience line is nonsense. I learned html 25
| years ago and can only describe what that line does in pretty
| generic terms. It's like asking a journalist candidate to give
| you the Webster definition of "amalgamation".
| tinco wrote:
| 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 asking you to recite them from
| the top of your head, he's asking you to have a simple
| conversation about them.
|
| Who cares if you can architect Twitter. Any college graduate
| can make a half hearted attempt at architecting some bullshit.
| What needs to be tested is how well do you know your domain. If
| you claim to have ten years of experience as a web developer,
| how much did you actually learn in those ten years?
|
| You can't be serious that you couldn't explain what UTF-8 is,
| or why text direction might matter, or why we put social media
| links in our headers if you claim to be a senior frontend web
| developer.
| jtchang wrote:
| Is this sarcasm?
| munk-a wrote:
| 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 wrote:
| 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.
| [deleted]
| svachalek wrote:
| 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.
| june_twenty wrote:
| 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.
| ge96 wrote:
| 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.
| Jare wrote:
| > 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 wrote:
| 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.
| [deleted]
| joshstrange wrote:
| > 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 wrote:
| 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.
| tinco wrote:
| 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 wrote:
| 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?
| ALittleLight wrote:
| 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 wrote:
| 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.
|
| Rage-quitting the interview or blurting out confidently
| wrong guesses, on the other hand, are bad signals.
| [deleted]
| zitterbewegung wrote:
| IMHO instead of doing fancy tricks the first day for
| interviewing take something that could be completed in one day
| at the job you are interviewing for and if you can complete it
| or get it near enough I would think that would be a better
| criterion to hire. Also, this interview would be paid for the
| first day at the same rate that you would be hired for.
| tgsovlerkhgsel wrote:
| I think it's a very good question. You're not just checking
| boxes and giving a score here, and if the interviewer is any
| good, it's not just about "how many correct answers".
|
| The depth of each answer gives you a lot of information about
| the depth and breadth of the candidate's knowledge. It
| immediately lets you tell the complete idiot who has always
| copy-pasted without any understanding from the person who lives
| and breathes web standards.
|
| Since some of the questions are very esoteric, as you said, it
| lets you judge how the candidate deals with lack of knowledge.
| Do they make up some bullshit pretending to be confident (which
| could be a huge problem in a real project), or do they say "I
| don't know this one, but based on X I assume it's probably Y"?
| teaearlgraycold wrote:
| I agree. If this is judged by how many you can answer then
| the interview isn't useful. But if the interviewer uses it as
| a launching point from which the candidate can talk about
| their experience with web technologies then it's a great
| addition to a longer interview.
| forty wrote:
| It's not a very good question and it's not a very good answer
| either. Discussing the DOCTYPE without mentioning SGML or XML
| seems to be a bit weird to me.
| rjh29 wrote:
| That was more relevant 10 years ago. Nowadays the primary
| point of the html doctype declaration is to say 'I am HTML5'.
| I know this and I'm not even a frontend developer.
| ramesh31 wrote:
| Count me as someone who loves this. I could turn this prompt into
| an enjoyable 30 minute discussion easily. I am a front end
| developer, not a computer programmer. I cannot reverse a linked
| list or invert a binary tree. But I can explain in depth to you
| about every single aspect of the browser, HTML, CSS, JS, and UI
| engineering in general. I have a decade of deep, specialized
| expertise in building software for web browsers, and an
| encyclopedic knowledge of web technologies. I can build anything,
| and my previous work speaks for itself. But I simply cannot pass
| the SV Leetcode/whiteboard style interviews. It's maddening.
| maxbaines wrote:
| Why the first line of Twitter, why not Facebook.com or Google.com
| actually I just looked there all very different given meta tags
| for each company, i.e Facebook does not use twitter meta tags
| from what i could see neither does the google home page, although
| i guess there search does.
| jdrc wrote:
| I like that now we have "apple" tags, and "twitter" tags
| everywhere. Maybe cocacola and mcdonalds should buy a tag too ,
| because, why not. At least facebook had the decency to call their
| tags "open graph"
| jeroenhd wrote:
| I'm not so sure about this one. There's not much open about
| opengraph other than that Facebook published the for wat they
| want to use. Everybody else copied it, but Facebook decides
| what does and doesn't make it into the standard.
|
| At least Twitter has the decency to mark their proprietary
| standards as proprietary.
| jdrc wrote:
| why didnt twitter just use og: ? it 's the exact same
| content. they create tag pollution without thinking
| DHPersonal wrote:
| This test leaves me conflicted. I'm often surprised by what
| developers remember and more importantly forget; it seems that
| after a while the fundamental elements of what makes up a website
| are lost in the sea of new development languages or platforms.
| I've done front-end design and development for over a decade now
| but have largely leaned into the prototyping and design area of
| that career, so my knowledge of development is limited enough to
| not have forgotten HTML and the markup for building a page. I
| would've been able to ace this test while also failing to be
| suitable for a senior Javascript developer. Developers here on HN
| who would likely be able to outwit me in every way in development
| seem to have lost touch with simple HTML markup. Still, I wonder
| if something important is lost when development requires these
| basic elements of a page to be forgotten in service of a new
| framework or language.
| dvtrn wrote:
| Hi! I'm not a front-end person, I'm an ops guy, I live in the
| world of bash terminals and thread dumps. My knowledge of HTML
| and CSS is enough to make some headings and paragraphs. So pardon
| what might be to you folks who look at this daily-seem like a
| "duh" question.
|
| The article says this:
|
| _You might think that this information is redundant because the
| browser already knows that the MIME type of the response is text
| /html; but in the Netscape/Internet Explorer days, browsers had
| the difficult task of figuring out which HTML standard to use to
| render the page from multiple competing versions._
|
| Are there still a lot of browsers in use that have difficulty
| figuring out the HTML standard, and if not, is the doctype
| declaration just an anachronism of markup?
|
| Asked in a less roundabout way: If response data is sufficient
| for a browser to know what it needs to do, and modern browsers
| support such capability: why do we still declare document types?
| ZeroGravitas wrote:
| Browsers include a lot of crazy backwards compatability stuff.
| You can basically trigger a whole different experience with the
| right/wrong doctype line.
|
| I guess it'll disappear eventually and become an opt out rather
| than an opt-in, but not sure if we're there yet, IE11 has been
| a major drag on progress.
| csnover wrote:
| It can never disappear and become an "opt out" without
| breaking backwards compatibility. This has nothing to do with
| old browsers, but rather, old content. You can't go back in
| time and rewrite every HTML file ever published in order to
| have them "opt in" to quirks mode.
| jaywalk wrote:
| It's not that there's any "difficulty" in figuring it out, but
| it's literally part of the standard. An HTML 5 page will not
| render correctly without <!DOCTYPE html> even in modern
| browsers.
| dvtrn wrote:
| Ok, that's fair, it's in the standard.
|
| I suppose my _real_ question is (and maybe this is a
| discussion that 's been beaten to death and I'm merely
| ignorant of it): why does the standard require it, if modern
| technology seems to have obviated the need for it?
|
| Am I too far off the mark with "backwards compatibility" as a
| scientific wild-ass guess or is it more complicated than
| that? And if so, with what kind of devices/browsers that
| would still be in use today?
| jaywalk wrote:
| It is for backwards compatibility, but you're thinking
| about it in reverse. It's so that modern browsers can also
| render pages written to older standards correctly as well.
| They will not use "HTML 5 mode" unless the page explicitly
| declares that it's HTML 5. Nor should they, because you
| can't have a valid HTML 5 page without it.
| dvtrn wrote:
| The loud noise you're hearing is the sound of a bunch of
| old, rusty mechanical gears clanking into place. This
| explanation makes perfect sense to me now. I hadn't done
| much serious front-end things since high school in the
| early 2000's and even then I had no idea what "web
| standards" were. I just knew how to make pages and
| display images for a counter-strike 1.6 clan haha.
|
| Thanks for taking me to school.
| jaywalk wrote:
| No problem, glad I could help!
| jeroenhd wrote:
| Most browsers have quirks modes for different types of HTML
| standards. Certain errors are renderered in certain ways
| because that's what web devs used to expect, even if they
| weren't following the standard. If you strictly enforce
| XHTML1.1 or HTML4 because the website says that's the standard
| it follows, you end up with tons of broken websites. It's a
| consequence of websites historically being lenient with front
| end developers.
|
| The HTML5 string basically says "I promise to be good, please
| turn off your weird workarounds". Of course, HTML5 has been
| around long enough that some browsers still have certain
| quirks, but they're not as extensive as the ones before HTML5.
|
| Compared to the `<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
| Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">`
| monstrosity from before, I'll happily take the modern standard.
| There's no version number anymore, just a simple HTML
| identifier.
| dinkleberg wrote:
| I'm imagining many of the people who are against this idea have
| never been on the interviewer side. Or aren't web developers and
| feel they should be able to answer this regardless.
|
| The intention of questions like these aren't to see if you know
| all the answers, it is to have a discussion and to learn about
| your experiences and see how you think.
|
| Also if you're applying for a web dev role and you're not fairly
| familiar with what real world HTML looks like it's may not be a
| great fit. You may not remember the exact syntax (because who
| care, you can google it), but you should have an idea of what
| you're sending over the wire.
| tgsovlerkhgsel wrote:
| Also, people who haven't been on the interviewer side have no
| idea what kind of idiots apply to jobs they're absolutely not
| qualified for.
|
| Like web developers who couldn't make a reasonable guess at
| more than two of these lines.
| noahjk wrote:
| HN: complains about leetcode-esque interviews
|
| Also HN: complains about alternative conversation-style
| interview
|
| I don't work on the front-end, but I have had a general
| curiosity for it for a while, and I think this would have been
| a great conversation starter! And I think a lot are missing the
| point that the interviewer isn't exactly using this to just
| "fail" people. Like you mentioned, these are the sort of out-
| of-the-box conversation starters that good interviewers try
| hard to come up with so they don't have to just give coding
| tests and ask the top 30 JS trick questions that are easily
| googleable.
| degenerate wrote:
| Exactly -- it gets people talking so you hear how they
| communicate and solve problems.
| jeffalbertson wrote:
| this is such a dumb, mediocre gotcha interview question.
|
| I prefer take homes to live coding questions but ffs, ask me
| questions that will pertain to my day to day responsibilities and
| have me explain my code sample. No FE dev in 2022 is creating a
| bunch of HTML pages.
| brimble wrote:
| Expecting people to know meta tags is ridiculous for all but very
| specialized roles. It's the kind of thing you rarely touch once
| it's set up. I'd expect most developers to be able to guess
| correct or near-correct answers just from context, which I guess
| is a test of a certain kind of reading ability. So I suppose
| that's some kind of signal. But this stuff changes often enough
| and there's enough subtlety, and very few people touch it very
| often, that you _should_ be consulting a guide or reference most
| every time anyway.
|
| This is probably a test of some useful ability for developers to
| have, but it's not knowledge of these things in particular.
|
| Also:
|
| > <meta name="theme-color" [...]
|
| > This is the proper web standards-esque equivalent of the Apple
| status bar color meta tag. It tells the browser to theme the
| surrounding UI.
|
| Oh, so _this_ is the horrible thing that 's infecting my desktop
| Safari and making it hideous and weird and inconsistent?
| Interesting.
| TameAntelope wrote:
| I think expecting people to know things they really shouldn't,
| and seeing how they react to that lack of knowledge is a very
| important part of interviewing.
|
| I assume this isn't the only question OP asks in their
| interviews, but I think it's got a couple of good outcomes and
| returns a lot for the length of time it takes to go through.
| kemar wrote:
| - https://htmlhead.dev
|
| - https://github.com/kevinSuttle/html-meta-tags
| wlesieutre wrote:
| _> Oh, so this is the horrible thing that 's infecting my
| desktop Safari and making it hideous and weird and
| inconsistent? Interesting._
|
| FYI you can disable the coloring as well as the "compact"
| layout that mushes the URL bar into the active tab and hides
| its <title>
|
| https://www.macrumors.com/how-to/safari-macos-turn-off-websi...
| brimble wrote:
| Yeah, reading TFA prompted me to finally go figure out how to
| do that :-)
|
| Much better. No more wild recoloring of my browser chrome
| because I switched tabs.
|
| > FYI you can disable the coloring as well as the "compact"
| layout that mushes the URL bar into the active tab and hides
| its <title>
|
| Did that day-1 with the new Safari. That part was wholly
| intolerable, not just ugly and annoying.
| bdcravens wrote:
| It's not a test of their meta tag knowledge, it's a test of how
| well they can speak to concepts with some context. (For
| instance, I don't really do anything with Open Graph, and I
| don't know the meta tag off the top of my head, but I spotted
| it in this example)
| ProAm wrote:
| And this is for a furniture rental business...? I think there
| is a easier way to determine if a candidate has the minimum
| technical skills required for the job besides a diminutive
| interrogation about Twitter.
| iamben wrote:
| > Expecting people to know meta tags is ridiculous for all but
| very specialized roles.
|
| Devil's advocate - is it? You're right, this stuff rarely gets
| touched, and (aside from changing the colours in the bit you
| hate!) it's the kind of stuff I'd normally boilerplate between
| projects.
|
| But if you're interviewing for a role and you're not giving
| them a coding test (yet?) but looking to see how _curious_ they
| are, how disparate their knowledge is, or just (as you say) how
| good someone is at guessing from context - isn 't this a fun
| experiment?
|
| I'd imagine just seeing how people deal with the answers gives
| you a good idea as to how they'd approach something when you're
| working together. Are they guessing? Confidently wrong? Seen it
| before but don't know what it is? Can roughly talk around it
| and what it does without exactly knowing? Proficient in it all
| (and how that relates to what they have or haven't said on
| their CV - have they under or over sold themselves?!)?
|
| I assume you could apply the same sort of test to any domain -
| test someone on something closely related you don't necessarily
| _need_ to know and see how they react.
| bri3d wrote:
| The problem with these "present a tangental question /
| loosely unfamiliar but similar" questions is that they become
| useless when a candidate _does_ know the answer as memorized
| trivia. At that point you 're looking for a signal about
| "what does the candidate do when presented with something
| familiar but unknown" but receiving "can the candidate
| regurgitate an answer."
|
| Of course you can then ask a different question, follow-ups,
| and so on, but you're so far off baseline compared to most
| candidates that the question starts to become useless.
| thomasahle wrote:
| I don't think the point is that every interviewer should
| ask about Twitters source code, and every interviewee
| should memorize it.
|
| The point is to ask a few randomly sampled knowledge
| questions to measure how well rounded the candidate is.
| Taking the "first 10 lines of Twitter" is just one way to
| sample such questions.
| [deleted]
| [deleted]
| TrickardRixx wrote:
| If you want to know how curious I am, ask me. If you want to
| know how disparate my knowledge is, ask me. If you want to
| know how good I am at guessing from context, ask me. If
| you're asking about meta-tag trivia, all you're going to find
| out is if I know meta-tag trivia. I know myself way better
| than any interviewer possibly can. If you don't trust me to
| evaluate myself, then you shouldn't be hiring me into a
| creative, professional, self-directed position.
| thomasahle wrote:
| In my experience, lots of people apply for jobs they aren't
| qualified for. How does I as the interviewer know which
| candidates I can trust to assess themselves and which I
| can't?
| munk-a wrote:
| I mean, a fair number will walk in the door talking about
| C-pound. A number of them will exclaim "What wizardry is
| that!" when you open up the developer console (or accuse
| you of hacking). Just do your best to sus out obvious
| lemons and fix the rest in post (i.e. figure out if
| they're full of crap during their probationary period).
|
| If you have specific pieces of technology you're working
| with and want to interview about then take an afternoon
| and just code up some bizarre snippets to go through with
| them - add a few mistakes they should be able to catch
| and just talk through their process.
|
| I honestly don't think opening up a random website and
| asking about some of the source code is a terrible
| approach... if you're interviewing someone for writing
| HTML in the 90's - in the modern world all the JS is
| minified (and likely generated by a framework), the CSS
| is absolutely atrocious to read (usually also generated)
| and the HTML is pretty much irrelevant. Use something
| that's going to be applicable to candidates to judge
| their understanding - I've always been fond of short
| puzzles very much _unlike_ this one (it 's way too
| arcane) in PHP `0x5 &$var=['cow' => 6]['cow']`[1] - just
| blerbs where you can step through some syntax
| understanding and problem solving at the same time.
|
| An actually good suggestion is to check out a random
| (ideally mostly self-contained) file from your codebase
| from a decade ago and step through what's awful about it
| - all code bases have these, and they're usually still
| kicking around as active code in production. At one of my
| more recent interviews they sent me login.php (the one
| actually in production, which they knew was broken - they
| had _two_ developers before me which were really
| overworked) and just asked me to mark up wrong stuff - I
| found SQL injections, unbound variables, conditions that
| would result in invalid HTML and broken forms and some
| terrible decisions from a readability perspective. I
| spent... maybe an hour on it.
|
| 1. https://3v4l.org/85MV3
| rileymat2 wrote:
| " I know myself way better than any interviewer possibly
| can. If you don't trust me to evaluate myself, then you
| shouldn't be hiring me into a creative, professional, self-
| directed position."
|
| I am not sure this is well grounded in the studies of human
| psychology.
| munk-a wrote:
| I think it's extremely fair to not trust people to
| evaluate themselves when doing open hiring - for
| networked candidates you can usually relax some
| assumptions and for very senior/niche positions there's
| usually ample street knowledge available... but in these
| cases you're relying on a third party for some level of
| vetting. I would never solely trust a second party during
| hiring unless I had some method to confirm at least some
| of what they're saying.
|
| A lot of companies are far too hesitant to trust
| employees, but blind trust is unwise - you can end up
| with an employee that either wastes three months salary
| or actively causes damage.
| rileymat2 wrote:
| I think we may be talking about slightly different
| things.
|
| There is a ton of well researched psychology work on self
| deception, confirmation bias, it goes on and on.
|
| Asking about the things that the OP was mentioning are
| deep psychological traps. Perhaps the OP has deep self
| awareness, but that does not apply to the general
| candidate or human.
|
| Our blind spots of our own actions and behaviors are
| profound.
| tshaddox wrote:
| It's really just the same kinda thing that fills most coding
| interviews (that aren't just pure live coding challenges):
| the interviewer is testing for something that isn't directly
| relevant to the role, because of course in the real role
| you'd be able to (and should!) research all the appropriate
| meta tags you should have on your web site, but since the
| interviewer deems it too difficult to actually directly test
| for the ability to do the job, they instead test for things
| that _surely the candidate must have ran into before and has
| a good enough memory to at least have a conversation so that
| I can subjectively judge how skilled the candidate is_.
| matth3 wrote:
| I've not been a frontend dev for well over a decade but I knew
| the meaning of all these meta tags. Back then I think it'd be
| pretty rare to find a good frontend developer who couldn't say
| what these were.
|
| Have things changed so much that knowledge of meta tags is
| specialist now?
|
| Assuming this interview was for a front end role that is.
| krapp wrote:
| >Have things changed so much that knowledge of meta tags is
| specialist now?
|
| Yes. More or less all web development now involves generating
| HTML with a language that compiles to javascript and a
| framework. No one even looks at, much less directly interacts
| with, fundamental web code anymore, and HTML has become
| esoteric "low level" knowledge like assembly language.
| matth3 wrote:
| But we've always generated the html using other languages,
| still needed to have a pretty decent idea of how it works.
| I find it hard to believe that's all redundant now in quite
| the same way knowledge of assembly is when your a python
| dev for example.
|
| Like take the open graph meta tags for example, for certain
| websites it'd be a big oversight to leave them out because
| you never bothered to learn what they were.
|
| I don't know if all this makes for a decent interview. Just
| blows my mind that people deem it too low level to have to
| care about, but what do I know anymore, it's been a real
| long time since I made a web page.
| Alex3917 wrote:
| > It's the kind of thing you rarely touch once it's set up.
|
| Exactly. Surely being able to actually configure the metadata
| tags on a webpage correctly must be more valuable than being
| able to remember what the different configuration options do
| years later, no?
| umvi wrote:
| The author says he doesn't expect perfect answers
|
| > Note that since our technical discussion is a conversation. I
| don't expect a perfect answer from anyone. If I hear some right
| keywords, I know that the candidate knows the concept, and I
| try to push them in the right direction.
|
| If I were being interviewed, I would probably say "yeah all
| those meta tags are metadata for various consumers. The apple
| related ones are probably for tailoring the page for display on
| apple devices"
|
| Hopefully that's good enough, if I were doing the interview I
| wouldn't expect more than that.
| brimble wrote:
| Yeah, the post indicates that the author might be Doing It
| Right, but then there's stuff like:
|
| > Surprisingly, only a few people knew about the dir
| attribute in my interviews
|
| No. Most of those few people who "knew" it are decent-to-good
| readers with enough context to figure it out, and in this
| _particular_ case they probably recognized "ltr", then
| worked backward to get what "dir" means, and were confident
| enough about that guess to state it as fact. They did all
| this in less than a second, because, again, they're decent-
| to-good readers who had the right context for this particular
| task. If this had been a made-up attribute you'd have gotten
| nearly as many people who "knew" it, I guarantee.
|
| This is closer to a web dev reading test than a direct test
| of knowledge. Which, again, might not actually be a crazy
| thing to administer.
| filmgirlcw wrote:
| You're right that this is closer to a reading test than a
| direct knowledge test, but I don't think that's a bad
| thing.
| jspash wrote:
| But don't underestimate the importance of reading as a
| skill! It's incredibly frustrating to see devs make stupid
| mistakes and spend time trying to get something to work
| when the answer is right in front of their nose.
|
| I see this too often. A developer (usually more towards the
| junior end) who think they can just chug through any
| problem. Trying this, then that, then google, then that
| again. When, if they would just stop and think through the
| problem - and use their eyes - they would see the solution
| was there all along.
| filmgirlcw wrote:
| Totally agree. I've definitely made this mistake myself
| (we all have) and the lesson is definitely to stop,
| think, read the code and that usually helps with the
| solution (or at least makes it easier to hone in on what
| to google)
| tedunangst wrote:
| It's a perfectly cromulent attribute!
| johannes1234321 wrote:
| They don't expect candidates to be able to write the "right"
| set of tags, but they use them as a basis for discussing
| different topics and recognizing things and maybe doing
| educated guesses in the meaning are quite useful skills.
| filmgirlcw wrote:
| I actually really like this and I'm a bit surprised to see all
| the pushback. If someone asked me this in an interview, I would
| have no problem talking about all of the stuff (origin trials, I
| might have messed up, but I might have been able to BS my way
| through the answer depending on the full length of the line and
| what context I could glean from it) and even now standards and
| boilerplate and defaults have evolved over the years.
|
| Now, whether or not that would be a good indicator for my
| viability as a front-end dev, I'm not sure. But at least it would
| show I have an understanding of what is going on and how to read
| and explain it. Which is better than a lot of leetcode exercises.
|
| I actually like the idea of asking people to explain code to them
| -- even if it isn't something like the first ten lines. If I'm
| proficient in a language, I should hopefully have a good idea of
| what is going on, at least in a sample app. And that is a useful
| skill, especially if your job is to come into an already
| established codebase.
| jenscow wrote:
| > able to BS my way through the answer
|
| That's it. Anyone claiming to be a _senior full-stack engineer_
| should be able to BS their way through this.
|
| If you're shocked by what you see on a "view-source" screen,
| then you haven't been doing this for very long, and you're not
| really "full stack".
| filmgirlcw wrote:
| Absolutely. And I'll also say that as an interviewer, I
| appreciate someone who can BS though something like this.
| Because part of the job is BSing through a lot of stuff.
| devoutsalsa wrote:
| If someone can get stuff done on the front-end and back-end
| at a senior level, who cares what they've memorized? I used
| to memorize all sorts of stuff. The only advantage it gave me
| was occasionally sounding smart, which it came at the expense
| of learning actually interesting things, like how to pick a
| useful database schema.
| filmgirlcw wrote:
| I don't think of this as rote memorization tho. This is
| about, can you read, identify, and explain the different
| parts. Now, you might not think that is a good test to see
| if someone is competent or not -- and I'm not going to
| pretend it is perfect. But as these things go, I don't
| think it's a bad starting point.
|
| I could explain nearly every one of those ten lines (and
| again, I'd have to see to full origin-trials line to know
| for sure, but I'd say there is a 70% I could infer/BS the
| answer), not because I've memorized anything but because
| I've spent years writing and reading this sort of thing.
|
| Now, if you asked me to write the first ten lines perfectly
| without any mistakes or use of code completions or
| boilerplate, I would almost assuredly fail. To me, that's a
| stupid memorization test. But asking someone to explain why
| something is there and what it does, I don't think that's
| the same thing at all.
| jenscow wrote:
| But for the job in question, this kind of stuff isn't
| memorisable factoids.
|
| Knowing what these 2 tags are for is fundamental, the
| wording of the attributes are vaguely self-descriptive, and
| recognising CSS from HTML is instinctive.
|
| You can't "get stuff done" without being able to at least
| bullshit the basics.
| jrochkind1 wrote:
| You don't know this stuff because you have "memorized" it,
| like with flash cards or something as some kind of
| memorization exersize. You know it because you know web
| technologies.
|
| It's weird to use "memorization" as basically a synonym for
| "remembered". Being a good developer is not just copy-and-
| pasting things from google, it involves actually
| understanding some technologies. Understanding technologies
| is not "memorization".
| tgsovlerkhgsel wrote:
| And BS-ing through it is exactly one of the red flags I'd be
| looking for as an interviewer.
|
| I don't want people who tell me "it's all under control" and
| "I know this" and then the result is a disaster. I want
| people who tell me "I know X and Y but I'll have to look up
| Z". Tell me that you don't know but are assuming, _then_ show
| me your reasoning skills by "BS-ing your way through it".
| deckard1 wrote:
| This seems to be closer to the right approach to interviewing
| over the leetcode grind, but it's the _wrong_ example. The head
| tags are trivia and have changed _a lot_ over 5-10 years (not to
| mention Twitter doesn 't include the head tag which is just
| wrong, IMO, though every browser since the '90s is flexible on
| this and everything else to do with HTML). Many front end devs
| haven't touched the head tags because that's a separate team. Or
| it's the lead devs that set that up. It's also the kind of thing
| you set once and never touch again and every site will use
| different head tags.
|
| A better approach is to drop into some code and ask the candidate
| to explain it. What's the code doing, why is it doing it. Maybe
| even show some code with a bug and have the candidate fix the
| bug. That's like 60% of most jobs right there. Reading code,
| understanding what it's doing, and figuring out how to make
| changes to it.
| brundolf wrote:
| I think this is fine as a fun litmus test, I don't think it's
| fine as a key criterion. If a person didn't know a single one of
| these, they should still be in the running (if marked down a
| little bit). Most senior front-end devs I would expect to have a
| decent grasp on maybe 1/3 of these.
|
| I think it's fine to have some ridiculous questions that you
| don't expect anyone to get perfectly, just to gauge, though it's
| important to communicate that to the candidate so their nerves
| aren't rattled when they feel out of their depth
| MaxMoney wrote:
| dillondoyle wrote:
| I know these, because I build websites, often simple static
| sites. A bunch are social or just rendering on apple devices.
|
| And manifest wasn't even in there. though does anyone actually
| 'install' pwa 'apps' (sorry double apps)?
|
| IDK why anyone who's main job is not SEO or building static html
| pages should know this. Except maybe viewport for people writing
| css by hand. Hell even then.
|
| You can just use a generator. I think the SEO one that generators
| most of this is the #1 wordpress plugin
| dark-star wrote:
| I wonder why people keep calling HTML "source code"
| sockpuppet69 wrote:
| brimble wrote:
| It screams "non-technical manager" (or journalist, or
| politician, et c) to me (though that doesn't seem to actually
| be the case, here?)
| xiekomb wrote:
| Ahah this! When reading the post title I was wondering if
| Twitter backend end (or even front end) source code had leaked.
| As a candidate I would give minus 1 point to the interviewer ;)
| leephillips wrote:
| I don't, for one. From the title I thought this was about the
| code that runs the Twitter back end. I would call this "markup"
| or "HTML".
| shadowgovt wrote:
| Great discussion of what these mean, but terrible idea for an
| interview question. As a rule, I really try to shy away from
| questions where the answer is "I don't konw, but I'd be happy to
| look it up if it were relevant to my job," and with modern
| frameworks direct knowledge of these tags is almost never
| relevant.
|
| (On the other hand, if the candidate had access to a computer,
| following their process of looking these up might be
| interesting...).
| ripley12 wrote:
| I see this as similar to the "what happens when you visit
| google.com?" question - it's a starting point for conversation,
| not gotcha trivia.
|
| I certainly wouldn't expect anyone to know every answer off the
| top of their head, but talking through a candidate's educated
| guesses can be informative.
| fefe23 wrote:
| May I jump in to point out that this is not "Twitter's source
| code". It's their HTML.
|
| Source code implies it's a programming language. This is not.
| This is HTML, which is a Markup Language (hence the ML in HTML).
|
| There is probably some Javascript code there further down but you
| didn't look at it.
|
| In common parlance, Twitter's source code is the source code to
| their web services and backend systems, which is not public.
| FatalLogic wrote:
| Calling it "Twitter's HTML Source" or "Twitter's HTML Source
| Code" would be reasonably clear. But just saying "Twitter's
| Source Code" does imply something other than that, probably
| non-public backend code, you're right
|
| That would make me wonder about the interviewer's experience.
| That's not a feeling you want to have at the start of an
| interview
| tfvlrue wrote:
| I tend to agree with this. My expectation from reading the
| headline was that it would be code from the backend (which
| admittedly seemed odd, since that's not public).
|
| I can't recall ever seeing someone use the phrase "X's source
| code" to mean HTML. In my view it's data, not code. Just like
| you wouldn't call some XML file "source code" -- it's purely
| descriptive markup. When a browser's context menu says View
| Source, the word "code" isn't implied. It's the same usage of
| the word "source" meaning "origin" (as in "cite your sources").
|
| Maybe I'm being overly pedantic, but the phrasing definitely
| read strangely to me regardless. Speaking as someone who's done
| a mixture of programming and web development for over two
| decades.
| booleandilemma wrote:
| "Sorry, we don't hire pedants here"
| hoten wrote:
| The browser ui to view this Html has been called View Source
| for decades.
| paxys wrote:
| If someone starts arguing about this in an interview it would
| be the quickest no-hire decision ever.
| CPLX wrote:
| It's the _code_ you see when you view _source_
| jbki1121 wrote:
| I'd say it's fair enough to consider markup as code ("code" in
| the sense of morse code)
| Animats wrote:
| "As a side note, it looks like Twitter omits the HEAD tag for
| performance reasons"
|
| Yeah, right.
|
| HTML is supposed to be <html><head>head stuff</head><body>body
| stuff</body></html>. But in practice you see multiple HEAD
| sections, missing HEAD sections, multiple BODY sections, missing
| BODY sections, and even multiple HTML sections. If you omit all
| those tags, it still works, mostly.
| munk-a wrote:
| It's an absolute necessity that they shave 13 bytes off the
| packet size... to make room for more advertisements. Their page
| size is 90KB for me, which isn't great nor terrible, but
| violating standards "just because" feels unnecessary.
| sockpuppet69 wrote:
| jollybean wrote:
| This isn't a very great interview question.
|
| Testing detailed arcane knowledge is one thing, and it should be
| impressive if people know everything.
|
| But the web is a giant mess of technologies that nobody can
| really fully keep up with and I'd rather people spent that extra
| minute learning about another language or subject, than say the
| details of 'doctype'.
| partomniscient wrote:
| If anything this illustrates how convulated and painful web
| development has become.
|
| The design was that HTML was HTML and the client managed all the
| implementation details. Over time that got ruined by wildly
| different implementations, introducing non standard tags and so
| on.
|
| I'm glad I moved away from it before mobile versions of sites
| became a neccessity.
|
| Having to do all this work to cater for members that have a
| mobile device made by a specific manufacturer just emphasises
| that the whole thing has gone totally off the rails and
| completely awry. The ratio of actual information you read vs the
| amount of cruft that comes with it to display it is insane. And
| it's been a major issue for a long time. It was painful enough in
| the 'if !ie6'...era.
|
| At what point does the ongoing cost of presenting and maintaining
| the information exceed the value of the information itself?
|
| However, this is the reality of the online world we live in
| today. It also makes you appreciate the simplicity, usability and
| maintenance-ease of HN itself. You're already into the actual
| content only 3 lines in.
| ingvul wrote:
| And this is why the tech interview process is (still) broken.
___________________________________________________________________
(page generated 2022-02-25 23:00 UTC)