5 ms·

> these technical interviews are a lot more about "did the candidate approach the problem the same way you would?" honest question, I can only evaluate the cor

> these technical interviews are a lot more about "did the candidate approach the problem the same way you would?" honest question, I can only evaluate the correctness of a thing if I am familiar with the tech the candidate used to answer the question. Is this being unfair? Should I instead use the technical interview as a time to do as much information gathering as possible then take it back to the wider technical team for evaluation (provided I am not able to understand the technical answer myself).

gumby 6y ago
If the candidate is using a tech you’re unfamiliar with why are you interviewing them? In general* you want people who claim familiarity with the tech they will be using in the job. And if that is the case but you aren’t familiar with that tech (you work on a different part of the stack, say) then you shouldn’t be wasting their or your time having them code something up but instead you should be asking them about the parts which are the reason for you to be one of the interviewers. * yes there are several exceptions to this but they are exceptions.
- crescentfresh 6y ago
  > If the candidate is using a tech you’re unfamiliar with why are you interviewing them? did you read the article? Did you see the comment I was replying to? The gist is that a candidate may know other things that I don't and still successfully answers the technical question. Just because it wasn't using the tech I would have used to solve the problem doesn't mean they're unqualified. Not saying that's what you're saying, I'm just repeating explicitly what I only implied earlier.
notapenny 6y ago
I wouldn't call it unfair, but if you're giving the candidate the option to solve a problem in their language of choice, you may run into this. You can either constrain the problem (we work with languages X, Y Z, so pick either of those) or still give them the option but use it in another way. For example, I work in front-end but I do most interviews across front-end, back-end, devops, always together with someone who's familiar with the domain or the specific stack we're recruiting for. In that case I'm there to test more on softer skills, but also its a good test to see if a candidate can discuss their domain with someone who isn't familiar with it.
horsawlarway 6y ago
I think turn this on its head - You're not trying to evaluate the correctness of the thing, you're trying to evaluate the value add of the candidate. So instead of you trying to judge the value of the implementation based on some undefinable "technical correctness" have a discussion about the what the candidate has done/built. In this case - so many opportunities for great discussion around the tradeoffs of this approach: - What sort of load does it handle? - How portable is it? - What does developer setup for this environment look like, and what tools might you need to introduce the team to for them to be productive? - What might you do instead of this if we had requirement X, or challenge Y (ex: Network latency, computations/second, real time processing requirements, tooling/language constraints, etc)? - What are the scaling costs? - How do you put tests in place? - Etc. And then you expect to receive believable answers, and interesting conversation. Because at least in this case, it's pretty trivial to determine that the solution either does or does not work for at least a small subset of fizzbuzz. It can be really insightful to step back from the expectation that an interview is always "Interviewer is more experienced than interviewee" and instead just try to get an understanding of what working/talking with that person is like. For context - I've done about 150 software dev interviews over the last two years (principle/senior to junior/intern)

gumby 6y ago

If the candidate is using a tech you’re unfamiliar with why are you interviewing them? In general* you want people who claim familiarity with the tech they will be using in the job. And if that is the case but you aren’t familiar with that tech (you work on a different part of the stack, say) then you shouldn’t be wasting their or your time having them code something up but instead you should be asking them about the parts which are the reason for you to be one of the interviewers. * yes there are several exceptions to this but they are exceptions.

crescentfresh 6y ago
> If the candidate is using a tech you’re unfamiliar with why are you interviewing them? did you read the article? Did you see the comment I was replying to? The gist is that a candidate may know other things that I don't and still successfully answers the technical question. Just because it wasn't using the tech I would have used to solve the problem doesn't mean they're unqualified. Not saying that's what you're saying, I'm just repeating explicitly what I only implied earlier.

notapenny 6y ago

I wouldn't call it unfair, but if you're giving the candidate the option to solve a problem in their language of choice, you may run into this. You can either constrain the problem (we work with languages X, Y Z, so pick either of those) or still give them the option but use it in another way. For example, I work in front-end but I do most interviews across front-end, back-end, devops, always together with someone who's familiar with the domain or the specific stack we're recruiting for. In that case I'm there to test more on softer skills, but also its a good test to see if a candidate can discuss their domain with someone who isn't familiar with it.

horsawlarway 6y ago

I think turn this on its head - You're not trying to evaluate the correctness of the thing, you're trying to evaluate the value add of the candidate. So instead of you trying to judge the value of the implementation based on some undefinable "technical correctness" have a discussion about the what the candidate has done/built. In this case - so many opportunities for great discussion around the tradeoffs of this approach: - What sort of load does it handle? - How portable is it? - What does developer setup for this environment look like, and what tools might you need to introduce the team to for them to be productive? - What might you do instead of this if we had requirement X, or challenge Y (ex: Network latency, computations/second, real time processing requirements, tooling/language constraints, etc)? - What are the scaling costs? - How do you put tests in place? - Etc. And then you expect to receive believable answers, and interesting conversation. Because at least in this case, it's pretty trivial to determine that the solution either does or does not work for at least a small subset of fizzbuzz. It can be really insightful to step back from the expectation that an interview is always "Interviewer is more experienced than interviewee" and instead just try to get an understanding of what working/talking with that person is like. For context - I've done about 150 software dev interviews over the last two years (principle/senior to junior/intern)