4 ms·

When I see a new grad say they're an advanced Java developer, I take it was a grain of salt. Then they don't remember what the associative array implementation

by jjice 4y ago

When I see a new grad say they're an advanced Java developer, I take it was a grain of salt. Then they don't remember what the associative array implementation is called in Java (HashMap). If you don't know your language's standard library implementation of common collections, you're not advanced. But I make sure to not judge them on that. They're often over zealous and looking for a job, so I don't blame them. The content of the interview is the real meat and potatoes in my experience.

ajross 4y ago
> But I make sure to not judge them on that. [...] The content of the interview is the real meat and potatoes Which is to say, the difference between a genuinely good candidate and one that merely claims to be is clearly visible in exactly the kind of interview the linked article is arguing against. I think there's lots of room for criticism of the Big Tech Coding Interview. But "it doesn't work" is just not reasonable. It does work, it objectively works very well, probably better than other techniques (the existence proof being that there aren't any other hiring organizations out there beating the FAANGs at their own HR game). If you want to criticize, point out that it doesn't necessarily work fairly. It rejects specific qualified candidates more often than it should, and it fails to reliably measure other areas of qualification than mere technical skill. But don't say it doesn't work, or that it's a waste of time. Show, don't tell. If you know how to hire better people, then do so and beat the world.
- SamoyedFurFluff 4y ago
  I have one and it’s quite difficult because it requires the interviewer to know their shit: drill down on a feature or technology listed in the resume in the interview with the developer. Get into the technical scope, the tradeoffs, pinch points and cruxes of problem set. Understand what the definition of success was in that feature and the individual contribution involved. A dev who only passably did the work or did so heavily relying on others expertise won’t be able to answer precise trade off questions in this way. Ultimately though if they did the work they did the work, and that’s more important than any leetcode/trivia nonsense.
  - Hermitian909 4y ago
    People have been re-discovering this technique for over a decade now at least. It's actually used at quite a few big tech companies, but only for strategic hires. You touch on one of the reasons this technique isn't used in general: > it’s quite difficult because it requires the interviewer to know their shit Having an interviewing team in an engineering org n > 100 with the following properties is nearly impossible: 1. Everyone knows their shit 2. Everyone cares enough to give the interview well 3. Has enough throughput to meet the company's hiring needs 4. The interviews are given in such a way that legal isn't worried we'll get slapped with a discrimination lawsuit
corrral 4y ago
> If you don't know your language's standard library implementation of common collections, you're not advanced. Heh. I've written production code—and lots of it—in... god, eleven or twelve languages? Not counting transpile-to-JS languages—add another two for that. Also not counting markup languages or CSS or anything like that. Oh, and I forgot bash, if that counts (not sure I'd count it). I'd probably get stuff like "how do you declare & populate an associative array?" wrong in at least half of them, and the others I'd basically be guessing but luckily several accept syntax so similar that if I used it on all of them I'd be correct in enough cases to get me up to about half-right. I'd have about as much trouble with this task in languages I last wrote fifteen years ago, as ones I wrote code in today. Stuff that's common to most or all languages, I tend not to keep in my head. Any given language probably has this kind of feature, so I just expect it to be there, and not confined to any particular language. I crib off nearby code, let my tools tell me the correct invocation, or look it up. If it's anything even somewhat common, there's usually an example nearby to use as reference, so it hardly even slows me down. If it's uncommon enough in the codebase that I have to look it up or spend 10 seconds finding an example in some other file, that probably means I'm not having to do that often, so that's OK too.
- eklitzke 4y ago
  That's fine if you're talking about languages you use infrequently, but if you can't declare and populate an associative array in the main language you're interviewing in you shouldn't be surprised if your interviewer fails you.
  - corrral 4y ago
    I usually try to drill syntax for about 30 minutes before an interview, for this reason—I'll forget it a few hours later, but that's fine, since it doesn't actually matter—but it's hardly ever been turned out to be a factor in a 20+ year career and 7 or 8 job switches, anyway. I mostly do it for my own peace of mind.
  - travisgriggs 4y ago
    But to GPS point, if this is going to be the new production language for this person for the next period, they’re going to lookup how to do this in seconds and then be an asset to you. Would you really rather have the junior developer who knows the answer to this question off the top of their head, but has so many other lessons to yet learn that GP can bring to the table? Honestly, once a person has demonstrated some proficiency in a cross section of languages, you should just skip the language proficiency section and instead talk about how learning new languages has gone in the past. Look for any red flags or biases that are going to be a hindrance in the new languages particular paradigm, but otherwise the “can you X” is already a done deal.

by jjice 4y ago

ajross 4y ago

> But I make sure to not judge them on that. [...] The content of the interview is the real meat and potatoes Which is to say, the difference between a genuinely good candidate and one that merely claims to be is clearly visible in exactly the kind of interview the linked article is arguing against. I think there's lots of room for criticism of the Big Tech Coding Interview. But "it doesn't work" is just not reasonable. It does work, it objectively works very well, probably better than other techniques (the existence proof being that there aren't any other hiring organizations out there beating the FAANGs at their own HR game). If you want to criticize, point out that it doesn't necessarily work fairly. It rejects specific qualified candidates more often than it should, and it fails to reliably measure other areas of qualification than mere technical skill. But don't say it doesn't work, or that it's a waste of time. Show, don't tell. If you know how to hire better people, then do so and beat the world.

SamoyedFurFluff 4y ago
I have one and it’s quite difficult because it requires the interviewer to know their shit: drill down on a feature or technology listed in the resume in the interview with the developer. Get into the technical scope, the tradeoffs, pinch points and cruxes of problem set. Understand what the definition of success was in that feature and the individual contribution involved. A dev who only passably did the work or did so heavily relying on others expertise won’t be able to answer precise trade off questions in this way. Ultimately though if they did the work they did the work, and that’s more important than any leetcode/trivia nonsense.
- Hermitian909 4y ago
  People have been re-discovering this technique for over a decade now at least. It's actually used at quite a few big tech companies, but only for strategic hires. You touch on one of the reasons this technique isn't used in general: > it’s quite difficult because it requires the interviewer to know their shit Having an interviewing team in an engineering org n > 100 with the following properties is nearly impossible: 1. Everyone knows their shit 2. Everyone cares enough to give the interview well 3. Has enough throughput to meet the company's hiring needs 4. The interviews are given in such a way that legal isn't worried we'll get slapped with a discrimination lawsuit

corrral 4y ago

> If you don't know your language's standard library implementation of common collections, you're not advanced. Heh. I've written production code—and lots of it—in... god, eleven or twelve languages? Not counting transpile-to-JS languages—add another two for that. Also not counting markup languages or CSS or anything like that. Oh, and I forgot bash, if that counts (not sure I'd count it). I'd probably get stuff like "how do you declare & populate an associative array?" wrong in at least half of them, and the others I'd basically be guessing but luckily several accept syntax so similar that if I used it on all of them I'd be correct in enough cases to get me up to about half-right. I'd have about as much trouble with this task in languages I last wrote fifteen years ago, as ones I wrote code in today. Stuff that's common to most or all languages, I tend not to keep in my head. Any given language probably has this kind of feature, so I just expect it to be there, and not confined to any particular language. I crib off nearby code, let my tools tell me the correct invocation, or look it up. If it's anything even somewhat common, there's usually an example nearby to use as reference, so it hardly even slows me down. If it's uncommon enough in the codebase that I have to look it up or spend 10 seconds finding an example in some other file, that probably means I'm not having to do that often, so that's OK too.

eklitzke 4y ago
That's fine if you're talking about languages you use infrequently, but if you can't declare and populate an associative array in the main language you're interviewing in you shouldn't be surprised if your interviewer fails you.
- corrral 4y ago
  I usually try to drill syntax for about 30 minutes before an interview, for this reason—I'll forget it a few hours later, but that's fine, since it doesn't actually matter—but it's hardly ever been turned out to be a factor in a 20+ year career and 7 or 8 job switches, anyway. I mostly do it for my own peace of mind.
- travisgriggs 4y ago
  But to GPS point, if this is going to be the new production language for this person for the next period, they’re going to lookup how to do this in seconds and then be an asset to you. Would you really rather have the junior developer who knows the answer to this question off the top of their head, but has so many other lessons to yet learn that GP can bring to the table? Honestly, once a person has demonstrated some proficiency in a cross section of languages, you should just skip the language proficiency section and instead talk about how learning new languages has gone in the past. Look for any red flags or biases that are going to be a hindrance in the new languages particular paradigm, but otherwise the “can you X” is already a done deal.