3 ms·

"One common misconception I keep seeing is the idea that the interview result revolves around solving the question." Candidates know this. The issue is: Inte

by urthor 5y ago

"One common misconception I keep seeing is the idea that the interview result revolves around solving the question." Candidates know this. The issue is: Interviewers who do their job, and build a broad based picture of a developer's skills and give fair ratings, are rare. The perception is 75% interviewers don't even bother. They're tired, they're unmotivated. Their annual bonus doesn't reflect "conducts fair and balanced job interviews." They underclock their brain to 10% of its maximum, and at the end of the hour look at how shiny and perfect the piece of code at the end is. Despite whatever the intentions of the system, I don't think anyone has ever hired a candidate with a messy code who spoke and reasoned well. My extremely strong perception, having never conducted a big tech company interview, is that a candidate who submitted a shiny piece of clean code at the end of a technical interview will always be first pick. No matter how much they mumbled. A picture is worth a thousand words. A shiny perfect coding solution is a perfect image in the mind of the interviewer. Interviewers are human, fallible people. When they're doing the end of day calibration on interview performance, having a shiny perfect solution changes their perception of a candidate utterly.

pc86 5y ago
I had an interview a few weeks ago that ended in an offer and was basically a verbatim Spiral Matrix problem from LeetCode (they had changed the starting direction of the spiral but that's it). Didn't run it once because we ran out of time, and when I pasted it into LC after the interview, noticed several errors to the point where it's honestly probably better we didn't run it. The interviewer was super engaged the whole time. When I'm conducting interviews, I'll do LC easies or mediums depending on the role we're hiring for - basically a couple easies for a new grad or someone with just a couple years of experience. One medium for a mid-level. If you're a senior we're not doing a coding exercise, we're having you teach us a system you've designed in the past, then we're going to change some of the core assumptions/requirements and see how your design changes. This has worked super well for us in the past, especially at the senior level. I would say most of the mid-levels we've hired since I've started doing this did not have a working solution at the end of the interview.
- urthor 5y ago
  The "Merge intervals" question, or variations in particular are such a good interview question. Off by one errors. Test the developers on the off by one errors. Whatever your skillset it's truly the fairest tool in the book I think.
- lmm 5y ago
  That sounds even worse in terms of setting realistic expectations for what the job will involve day-to-day. How many times is someone actually going to redesign a system like that?
  - pc86 5y ago
    Respectfully disagree. Teaching and explaining the current system to new and lower-level folks is arguably one of the most important skills for a senior developer. As for the system, they're not redesigning anything, they're teaching something that (as a senior) they should already know, as if we're juniors. Think typical box-arrow system architecture diagram, DB schema, that sort of thing.
    - lmm 5y ago
      Explaining the system is certainly something that happens, but in terms of hours/month I'd say it's something you do less of than leetcode-like coding work. Actually reconsidering your core design in response to some changing fundamentals, which sounded like it's what you're testing in this interview, is something that you do a few times a year at best.
lhorie 5y ago
Yeah, this is admittedly a problem. I don't have a great solution other than relentless education, which is... hard. Especially at scale. From a cultural side, some companies have a competency pillar that is supposed to embody the idea of being a "good person". In mine, we call it "Citizenship", it's tied to performance appraisal and interviewing is one way to develop that competency. As for code cleanliness, I've passed candidates with messy or even broken code before, if the candidate demonstrated competence in enough other aspects and the code quality issues can be attributed to nervousness or running out of time half way through a refactor or whatever.
- urthor 5y ago
  I guess the question is, what's the proportion either side? Is it 25% will do it properly, 75% don't? Am I too cynical about tech interviews, or too optimistic? I'd also add, for a couple of companies, Google's approach springs to mind. I think for places where, you know, they do search algorithms, knowing how to print the spanning tree of a graph is probably an important thing to know.
  - lhorie 5y ago
    My understanding is that googlers typically don't know/care what role the candidate is applying for (outside of maybe the hiring manager round). There are arguments both for and against their methodology. Personally I think there's a strong correlation between necessity and hiring quality (i.e. if teams really need the help, they typically engage candidates more meaningfully than the Google-style clinically impartial methodology)
    - urthor 5y ago
      That makes sense. Sounds a bit like what my old timer buddy says. Google's KPI is hiring talent away from competitors who physically live in the San Francisco bay area. And the ads/ML teams that they drench in their 1%ers. Everyone else is window dressing.

by urthor 5y ago

pc86 5y ago

I had an interview a few weeks ago that ended in an offer and was basically a verbatim Spiral Matrix problem from LeetCode (they had changed the starting direction of the spiral but that's it). Didn't run it once because we ran out of time, and when I pasted it into LC after the interview, noticed several errors to the point where it's honestly probably better we didn't run it. The interviewer was super engaged the whole time. When I'm conducting interviews, I'll do LC easies or mediums depending on the role we're hiring for - basically a couple easies for a new grad or someone with just a couple years of experience. One medium for a mid-level. If you're a senior we're not doing a coding exercise, we're having you teach us a system you've designed in the past, then we're going to change some of the core assumptions/requirements and see how your design changes. This has worked super well for us in the past, especially at the senior level. I would say most of the mid-levels we've hired since I've started doing this did not have a working solution at the end of the interview.

urthor 5y ago
The "Merge intervals" question, or variations in particular are such a good interview question. Off by one errors. Test the developers on the off by one errors. Whatever your skillset it's truly the fairest tool in the book I think.
lmm 5y ago
That sounds even worse in terms of setting realistic expectations for what the job will involve day-to-day. How many times is someone actually going to redesign a system like that?
- pc86 5y ago
  Respectfully disagree. Teaching and explaining the current system to new and lower-level folks is arguably one of the most important skills for a senior developer. As for the system, they're not redesigning anything, they're teaching something that (as a senior) they should already know, as if we're juniors. Think typical box-arrow system architecture diagram, DB schema, that sort of thing.
  - lmm 5y ago
    Explaining the system is certainly something that happens, but in terms of hours/month I'd say it's something you do less of than leetcode-like coding work. Actually reconsidering your core design in response to some changing fundamentals, which sounded like it's what you're testing in this interview, is something that you do a few times a year at best.

lhorie 5y ago

Yeah, this is admittedly a problem. I don't have a great solution other than relentless education, which is... hard. Especially at scale. From a cultural side, some companies have a competency pillar that is supposed to embody the idea of being a "good person". In mine, we call it "Citizenship", it's tied to performance appraisal and interviewing is one way to develop that competency. As for code cleanliness, I've passed candidates with messy or even broken code before, if the candidate demonstrated competence in enough other aspects and the code quality issues can be attributed to nervousness or running out of time half way through a refactor or whatever.

urthor 5y ago
I guess the question is, what's the proportion either side? Is it 25% will do it properly, 75% don't? Am I too cynical about tech interviews, or too optimistic? I'd also add, for a couple of companies, Google's approach springs to mind. I think for places where, you know, they do search algorithms, knowing how to print the spanning tree of a graph is probably an important thing to know.
- lhorie 5y ago
  My understanding is that googlers typically don't know/care what role the candidate is applying for (outside of maybe the hiring manager round). There are arguments both for and against their methodology. Personally I think there's a strong correlation between necessity and hiring quality (i.e. if teams really need the help, they typically engage candidates more meaningfully than the Google-style clinically impartial methodology)
  - urthor 5y ago
    That makes sense. Sounds a bit like what my old timer buddy says. Google's KPI is hiring talent away from competitors who physically live in the San Francisco bay area. And the ads/ML teams that they drench in their 1%ers. Everyone else is window dressing.