4 ms·

I interview senior SWEs at a big tech company (I've done in the order of a few hundred interviews, which were a mix of coding and system design sessions). I'm

by lhorie 5y ago

I interview senior SWEs at a big tech company (I've done in the order of a few hundred interviews, which were a mix of coding and system design sessions). I'm always open to hearing about ideas to improve my interviewing, but I find that threads like this are repetitive and not really actionable. One common misconception I keep seeing is the idea that the interview result revolves around solving the question. IMHO, that's a bad approach (which is unfortunately taken by many interviewers) and in fact it's an incomplete way of assessing candidates, given that most big tech companies have a list of competencies and/or values that are supposed to be evaluated. Big tech companies usually want interviewers to assess on multiple dimensions, ranging from communication quality to specialization fit. As an interviewer, you're supposed to think of the question as a vehicle to go over these topics, not a pass/fail end goal in and of itself. In my interviews, I pace my hints with the goal of having the candidate complete the question, even if it means dictating answers to unblock them. There's nothing worse that sitting there wasting time feeling smug when the candidate gets stuck on something. Time is short, so it's much better to move on quickly to different topics than linger on something unproductive. If you're on the interviewer side, my number one advice would be this: question the calibration of the question bank. It's usually a kitchen sink of everything the person writing it could think of, without regards for time. You might already feel that you don't have time to cover everything that the question is supposed to cover, let alone all the non technical criteria that leadership asks for. So instead, cover a few actual technical concepts (syntax, recursion, what have you) to rule out complete incompetence, and then take liberties to go into topics that do cover a wider variety of aspects. For example, discussions about testing, refactoring or debugging can all be productive ways to spend time in a coding interview. </two-cents>

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.

by lhorie 5y ago

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.