5 ms·

How do you compensate for the fact that you don't know the codebase that well? I feel like a lot of the value of interviews is that you see how a candidate thin

How do you compensate for the fact that you don't know the codebase that well? I feel like a lot of the value of interviews is that you see how a candidate thinks through a problem that you have also thought deeply about, which gives more fruitful discussions.

saimiam 6y ago
This is a great question. Guess OPs approach only works if they are hiring someone much more junior than themselves so that experience trumps code/domain familiarity.
- gkoberger 6y ago
  Not at all! I’m pretty experienced, but most people I interview or hire are much better engineers than me! Imagine you’re taking a class on a topic you don’t know. You can tell pretty quickly from how the instructor talks and explains something if they know what they’re talking about. It’s very similar! I’ve certainly interviewed people much more skilled than me in languages I’ve never used, and still got a pretty great sense of their expertise.
gkoberger 6y ago
Well, that's not how I tend to manage day-to-day. I don't give engineers I manage a problem I've already figured out and solved, and then expect them to do it the way I would. Rather, the engineers on the team are usually building something new, and figuring out how to accomplish it is their responsibility. This way of interviewing mimics that a lot closer. If someone can't explain to me a project they're working on, then they probably won't be able to do the same while we're working together. And that's just as important of a skill as writing code. If I'm expecting interviewees (who are nervous!) to learn and understand my codebase/problem, why can't I do the same for theirs?
- yowlingcat 6y ago
  Love this attitude. It's a great attitude and it shows. A very common thing I notice with interviewers is that they do one interview over and over again until it's super polished, but paradoxically, they won't compensate for that and in effect, the bar gets higher and higher for later candidates than earlier ones. Flipping the script not only is a great way to balance things here, but it also says a lot about your own confidence. I might have to lift your approach here!
  - gkoberger 6y ago
    Yup, exactly! The interviewer gets annoyed, since it's "so obvious" how to solve the problem... much like anything becomes obvious if you've done it a few dozen times. Or they tune out. Or they dismiss any variation as "wrong" rather than giving it a chance.
  - OmarShehata 6y ago
    I also love this attitude but I disagree about this negative effect you're talking about in reusing problems. What happens in practice is the interviewer compares candidates answers to each other, not to his/her own way of solving it. It doesn't matter what whether the solution is "obvious" to the interviewer. If I hired someone who only did OK on this question and they ended up being a great engineer (and that happened multiple times) that lowers the bar for the test (or tells me it's not a very good test etc)
    - musingsole 6y ago
      You're missing the part where the interviewer is changing with each interview (and the rest of their life in general). They phrase the problem differently, get anxious as the interviewee approaches different parts of the task. So, the interviewer thinks they're giving the same test and can fairly compare the outcomes. The GP's point is that's just not true Whether it works out to be a harder or easier interview over time because of these changes probably depends on the individual interviewer.
    - johnm 6y ago
      Sorry but the pointed out problem is both way more commoin and way way more of an issue. Interviewers talk about "I just want to see how someone thinks" but the implicit biases and the overuse of problems leads to unconscious expectation setting and rigidity in the interviewers. In fact, I explicitly test for this by giving valid answers using e.g., techniques that I don't think the interviewer is familiar with precisely to see how open minded the interviewers actually are. Their response is amazingly revealing about the interviewer and the organization behind them.
- bryanrasmussen 6y ago
  So practically - do you or some of your team get added to their project so you can track what they're doing? do you (or others on team) ever make suggestions on how the code should be written? I think this would be an interesting way to pre-teach the hire on how you like things structured. on edit - I guess since you ask them questions that implies making suggestions as well, but just wondering how it works.
  - johnm 6y ago
    Lots of why did you, why didn't you, what about this, how did you deal with that (and back to why). :-) I signal a lot of things like testing by asking them. It gives room for the candidate to ask those sorts of questions back about how we do things.
  - gkoberger 6y ago
    It's all done live! The first time we hear about what they're working on is during the interview, and we never keep any of the code. It's great to see how they can articulate what they're working on, combined with actually working on it. We sometimes might make suggestions, but rarely for the sake of code quality. We'll once in a while ask for something unique just to get them out of a rut, and see if they can improvise. Otherwise, we're here to learn and listen, not teach :)
inopinatus 6y ago
Ask them to explain it to you. The quality of the understanding that you gain, and their willingness and ability to engage with your curiosity, is one measure of the candidate. A coarse-grained qualitative measure perhaps, but certainly one aligned to dev team productivity.

saimiam 6y ago

This is a great question. Guess OPs approach only works if they are hiring someone much more junior than themselves so that experience trumps code/domain familiarity.

gkoberger 6y ago
Not at all! I’m pretty experienced, but most people I interview or hire are much better engineers than me! Imagine you’re taking a class on a topic you don’t know. You can tell pretty quickly from how the instructor talks and explains something if they know what they’re talking about. It’s very similar! I’ve certainly interviewed people much more skilled than me in languages I’ve never used, and still got a pretty great sense of their expertise.

gkoberger 6y ago

Well, that's not how I tend to manage day-to-day. I don't give engineers I manage a problem I've already figured out and solved, and then expect them to do it the way I would. Rather, the engineers on the team are usually building something new, and figuring out how to accomplish it is their responsibility. This way of interviewing mimics that a lot closer. If someone can't explain to me a project they're working on, then they probably won't be able to do the same while we're working together. And that's just as important of a skill as writing code. If I'm expecting interviewees (who are nervous!) to learn and understand my codebase/problem, why can't I do the same for theirs?

yowlingcat 6y ago
Love this attitude. It's a great attitude and it shows. A very common thing I notice with interviewers is that they do one interview over and over again until it's super polished, but paradoxically, they won't compensate for that and in effect, the bar gets higher and higher for later candidates than earlier ones. Flipping the script not only is a great way to balance things here, but it also says a lot about your own confidence. I might have to lift your approach here!
- gkoberger 6y ago
  Yup, exactly! The interviewer gets annoyed, since it's "so obvious" how to solve the problem... much like anything becomes obvious if you've done it a few dozen times. Or they tune out. Or they dismiss any variation as "wrong" rather than giving it a chance.
- OmarShehata 6y ago
  I also love this attitude but I disagree about this negative effect you're talking about in reusing problems. What happens in practice is the interviewer compares candidates answers to each other, not to his/her own way of solving it. It doesn't matter what whether the solution is "obvious" to the interviewer. If I hired someone who only did OK on this question and they ended up being a great engineer (and that happened multiple times) that lowers the bar for the test (or tells me it's not a very good test etc)
  - musingsole 6y ago
    You're missing the part where the interviewer is changing with each interview (and the rest of their life in general). They phrase the problem differently, get anxious as the interviewee approaches different parts of the task. So, the interviewer thinks they're giving the same test and can fairly compare the outcomes. The GP's point is that's just not true Whether it works out to be a harder or easier interview over time because of these changes probably depends on the individual interviewer.
  - johnm 6y ago
    Sorry but the pointed out problem is both way more commoin and way way more of an issue. Interviewers talk about "I just want to see how someone thinks" but the implicit biases and the overuse of problems leads to unconscious expectation setting and rigidity in the interviewers. In fact, I explicitly test for this by giving valid answers using e.g., techniques that I don't think the interviewer is familiar with precisely to see how open minded the interviewers actually are. Their response is amazingly revealing about the interviewer and the organization behind them.
bryanrasmussen 6y ago
So practically - do you or some of your team get added to their project so you can track what they're doing? do you (or others on team) ever make suggestions on how the code should be written? I think this would be an interesting way to pre-teach the hire on how you like things structured. on edit - I guess since you ask them questions that implies making suggestions as well, but just wondering how it works.
- johnm 6y ago
  Lots of why did you, why didn't you, what about this, how did you deal with that (and back to why). :-) I signal a lot of things like testing by asking them. It gives room for the candidate to ask those sorts of questions back about how we do things.
- gkoberger 6y ago
  It's all done live! The first time we hear about what they're working on is during the interview, and we never keep any of the code. It's great to see how they can articulate what they're working on, combined with actually working on it. We sometimes might make suggestions, but rarely for the sake of code quality. We'll once in a while ask for something unique just to get them out of a rut, and see if they can improvise. Otherwise, we're here to learn and listen, not teach :)

inopinatus 6y ago

Ask them to explain it to you. The quality of the understanding that you gain, and their willingness and ability to engage with your curiosity, is one measure of the candidate. A coarse-grained qualitative measure perhaps, but certainly one aligned to dev team productivity.