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.
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.
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.
I am not sure this is well grounded in the studies of human psychology.
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.
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.
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.
> 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.
> 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.
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.
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?
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.
Have things changed so much that knowledge of meta tags is specialist now?
Assuming this interview was for a front end role that is.
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.
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.
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...
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.
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.