8 ms·

You should absolutely see how they code - I've interviewed so many people on the phone who couldn't code their way out of a paper bag, but they could speak to i

You should absolutely see how they code - I've interviewed so many people on the phone who couldn't code their way out of a paper bag, but they could speak to it enough to fool you.

missosoup 7y ago
Maybe enough to fool you. It's pretty easy to tell if someone knows a topic or not by just asking increasingly more specific technical questions to follow up on their answers.
- sumanthvepa 7y ago
  This exactly. Start with general questions and get more specific until they are unable to answer or they exceed the depth of your own knowledge on the topic. You’ll be surprised how often that good candidate will take you out of your depth.
- mattbillenstein 7y ago
  Maybe - I mean, you just get signal from actual coding, I think it's pretty hard to discount entirely. How they solve problems, what mistakes they make, how they debug - I think it's just too valuable to not spend some time on. And I'm not giving them riddles - I give them easily solvable problems that can be done in almost any programming language. And I've given the same problems enough to know what it canonically looks like in a dozen languages.
dvt 7y ago
> ...but they could speak to it enough to fool you I keep hearing about this mythical coding con man, but I've yet to find anyone that can both have an intellectually stimulating conversation about a technical topic while at the same time suck at coding. I can generally tease it out in 15 minutes tops.
- recursive 7y ago
  You may be better at interviewing than some of us. Personally, I can't figure out how to tell if someone can actually write code in a conversation.
  - AlwaysBCoding 7y ago
    ask them what they've built in the past and start digging in from there.
    - recursive 7y ago
      I've certainly done that. But if it's in a domain I'm not familiar with, I'm not going to be able to tell if its real.
      - grecy 7y ago
        Don't focus on the domain, focus on the coding. i.e. don't talk about what they were doing, talk about how they did it. Where there any performance considerations? concurrency? what did they do for testing? was it automated? How the thing deployed? do they maintain it? etc. etc. In doesn't matter that in all of the above I'm talking about the code used to talk to little green men on Mars (which you know nothing about), but it matters how I used code to solve all the problems which are common across all kinds of software.
        webo 7y ago
        I’ve done over a hundred technical interviews in the past 5 years. You can tell a lot about someone by quickly glancing over a project source code, comments, documentation, automation, etc vs talking to them for an hour or two. (to be clear I’m not talking about live coding or take-home problems) There are bunch of people who can sound smart by just referencing stuff they read online or in the books. I don’t focus on specific technologies or frameworks because everyone has different backgrounds. However I do focus on CS fundamentals and software engineering practices. These don’t say much about actual coding skills.
sumanthvepa 7y ago
Turns out that I don’t actually need to. For us, as developer you will almost certainly run into tech that you know very little about but need to work with it anyway. So ability learn quickly and solve problems is more important. So intellectual horsepower, analytical and problem solving skills and most importantly a sense of agency and willingness to do what it takes to ship code out is more important. If the developer’s code isn’t beautiful and idiomatic, I will go and refactor it to make it so after we’ve shipped product. And given that the developer is a quick learner and has experience with writing good code it the past they will pick it up quickly. So I essentially screen on credentials: where did they go to school, where have they worked. and then make decision on the interview.
- mattbillenstein 7y ago
  I think credentials are sorta worthless - I've worked with people who worked at great companies, went to great schools, still very weak at coding and problem solving. I guess ymmv. Also, you personally refactoring people's code after the fact is not a great way to go about team building - I would try to get more of this into the PR process, teach them what they're not doing rather than do it for them.

You should absolutely see how they code - I've interviewed so many people on the phone who couldn't code their way out of a paper bag, but they could speak to it enough to fool you.

missosoup 7y ago

Maybe enough to fool you. It's pretty easy to tell if someone knows a topic or not by just asking increasingly more specific technical questions to follow up on their answers.

sumanthvepa 7y ago
This exactly. Start with general questions and get more specific until they are unable to answer or they exceed the depth of your own knowledge on the topic. You’ll be surprised how often that good candidate will take you out of your depth.
mattbillenstein 7y ago
Maybe - I mean, you just get signal from actual coding, I think it's pretty hard to discount entirely. How they solve problems, what mistakes they make, how they debug - I think it's just too valuable to not spend some time on. And I'm not giving them riddles - I give them easily solvable problems that can be done in almost any programming language. And I've given the same problems enough to know what it canonically looks like in a dozen languages.

dvt 7y ago

> ...but they could speak to it enough to fool you I keep hearing about this mythical coding con man, but I've yet to find anyone that can both have an intellectually stimulating conversation about a technical topic while at the same time suck at coding. I can generally tease it out in 15 minutes tops.

recursive 7y ago
You may be better at interviewing than some of us. Personally, I can't figure out how to tell if someone can actually write code in a conversation.
- AlwaysBCoding 7y ago
  ask them what they've built in the past and start digging in from there.
  - recursive 7y ago
    I've certainly done that. But if it's in a domain I'm not familiar with, I'm not going to be able to tell if its real.
    - grecy 7y ago
      Don't focus on the domain, focus on the coding. i.e. don't talk about what they were doing, talk about how they did it. Where there any performance considerations? concurrency? what did they do for testing? was it automated? How the thing deployed? do they maintain it? etc. etc. In doesn't matter that in all of the above I'm talking about the code used to talk to little green men on Mars (which you know nothing about), but it matters how I used code to solve all the problems which are common across all kinds of software.
      - webo 7y ago
        I’ve done over a hundred technical interviews in the past 5 years. You can tell a lot about someone by quickly glancing over a project source code, comments, documentation, automation, etc vs talking to them for an hour or two. (to be clear I’m not talking about live coding or take-home problems) There are bunch of people who can sound smart by just referencing stuff they read online or in the books. I don’t focus on specific technologies or frameworks because everyone has different backgrounds. However I do focus on CS fundamentals and software engineering practices. These don’t say much about actual coding skills.

sumanthvepa 7y ago

Turns out that I don’t actually need to. For us, as developer you will almost certainly run into tech that you know very little about but need to work with it anyway. So ability learn quickly and solve problems is more important. So intellectual horsepower, analytical and problem solving skills and most importantly a sense of agency and willingness to do what it takes to ship code out is more important. If the developer’s code isn’t beautiful and idiomatic, I will go and refactor it to make it so after we’ve shipped product. And given that the developer is a quick learner and has experience with writing good code it the past they will pick it up quickly. So I essentially screen on credentials: where did they go to school, where have they worked. and then make decision on the interview.

mattbillenstein 7y ago
I think credentials are sorta worthless - I've worked with people who worked at great companies, went to great schools, still very weak at coding and problem solving. I guess ymmv. Also, you personally refactoring people's code after the fact is not a great way to go about team building - I would try to get more of this into the PR process, teach them what they're not doing rather than do it for them.