4 ms·

I ask the same thing you do: "Tell me about a project you've worked on." There is tons of ground we can cover with that: * implementation choices with pros and

I ask the same thing you do: "Tell me about a project you've worked on." There is tons of ground we can cover with that: * implementation choices with pros and cons * details about how the underlying system works * domain knowledge, where applicable * sample code where the candidate writes to mimic something from the system My interview style has always been: "Tell me what you know, and we'll see if that's true or not." Surprisingly, most candidates fail even that since they don't seem to understand their own projects. But I find this approach the fairest of all since it allows the candidate to lead the interview and it doesn't assume anything about the candidate's knowledge or prior experience.

lordnacho 5y ago
I work in the same industry as you and I agree. Your problems are never how to reverse a linked list, or finding the missing number. It's always tradeoffs: why does the business benefit from this technical decision over that one? What's the point of this language? What do you need in terms of hardware? How do you organise the code to suit the needs? The interview that's always worked for me in hiring is where we talk about the issue and we see if the person understands the problem. There's an infinite number of things we can get into, and if the person is experienced they'll never run out of things to say. I've never hired someone who turned out not to know the basic things like some particular algorithm. I suppose if we're talking the leetcode style interview loops, they normally have a system design part. That might be the closest to what I do.
edanm 5y ago
I once would've completely agreed with your point idea. But since then, I've had multiple experiences of talking with someone who made a great impression, super knowledgeable, but couldn't actually write any code in a real-world setting. This approach simply doesn't always work. Some people are amazing-sounding but terrible in practice. The reverse is also true - some people are terrible at talking about their work, but produce amazing code. (Their lack of communication skills might or might not hamper their actual job performance, depending on multiple factors.)
- chrisaycock 5y ago
  I agree that the interview can't be just war stories. There has to be code in there somewhere, like whiteboard sketches of an algorithm the candidate has implemented. On the other hand, leet code questions definitely don't show that the candidate can actually write maintainable, well-documented code with test suites and easy-to-use APIs.
  - edanm 5y ago
    Yes, luckily those aren't the only two options :) Though I will say that having some kind of fizz-buzz style phone screen is still, in my mind, a good idea. It saves a lot of time if it turns out that your candidate can't even write a simple for loop (and so many can't, to my great dismay).

lordnacho 5y ago

I work in the same industry as you and I agree. Your problems are never how to reverse a linked list, or finding the missing number. It's always tradeoffs: why does the business benefit from this technical decision over that one? What's the point of this language? What do you need in terms of hardware? How do you organise the code to suit the needs? The interview that's always worked for me in hiring is where we talk about the issue and we see if the person understands the problem. There's an infinite number of things we can get into, and if the person is experienced they'll never run out of things to say. I've never hired someone who turned out not to know the basic things like some particular algorithm. I suppose if we're talking the leetcode style interview loops, they normally have a system design part. That might be the closest to what I do.

edanm 5y ago

I once would've completely agreed with your point idea. But since then, I've had multiple experiences of talking with someone who made a great impression, super knowledgeable, but couldn't actually write any code in a real-world setting. This approach simply doesn't always work. Some people are amazing-sounding but terrible in practice. The reverse is also true - some people are terrible at talking about their work, but produce amazing code. (Their lack of communication skills might or might not hamper their actual job performance, depending on multiple factors.)

chrisaycock 5y ago
I agree that the interview can't be just war stories. There has to be code in there somewhere, like whiteboard sketches of an algorithm the candidate has implemented. On the other hand, leet code questions definitely don't show that the candidate can actually write maintainable, well-documented code with test suites and easy-to-use APIs.
- edanm 5y ago
  Yes, luckily those aren't the only two options :) Though I will say that having some kind of fizz-buzz style phone screen is still, in my mind, a good idea. It saves a lot of time if it turns out that your candidate can't even write a simple for loop (and so many can't, to my great dismay).