5 ms·

> 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,

by iamben 5y ago

> 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.

deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
bri3d 5y ago
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 5y ago
  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.
TrickardRixx 5y ago
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 5y ago
  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 5y ago
    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 https://3v4l.org/85MV3
tshaddox 5y ago
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.

by iamben 5y ago

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]

bri3d 5y ago

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 5y ago
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.

TrickardRixx 5y ago

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 5y ago
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 5y ago
  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 https://3v4l.org/85MV3

tshaddox 5y ago

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.