4 ms·

> ...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 intelle

by 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.
      - lsalvatore 7y ago
        How much faith do you really have in these questions? This could be your entire 45 minute interview: Where there any performance considerations: Yes, the spaceship was extremely slow at first. After reverse engineering the launch protocol, we discovered that we could increase speeds by 5x simply by limiting the fuel cell usage. "Oh tell me about your rocket fuel cell usage"- Well, we have this thing called a fuel cell. It takes 5 batteries. 10 minutes of business logic later... * Now let's spend 25 minutes talking about infrastructure and team dynamic * Concurrency: None needed here. What did they do for testing: We used Jest. Was it automated: Yes. How was it deployed: Github / Heroku / AWS Do you maintain it: Yes, we maintain it with my little green friends. We each take turns writing code and maintaining the rocket protocols. It's actually quite nice. * Oh, well I guess we're out of time. * Congrats, you just hired a guy who read a few blogs and made up a few stories.
        bostik 7y ago
        > your entire 45 minute interview There's your problem. Right there. I don't think we can evaluate whether someone can do a decent job in 45 minutes. Or an hour. Sure, we can spot and confirm a hopeless case in 20. But beyond that, an hour is simply not enough. I've been involved in hiring and interviewing for close to 15 years. The best results have been with candidates with whom I've arranged to have at least 90 minutes, and where that time ended up being well spent. It takes a while to get comfortable, to warm up, to establish a common ground. And it sure as hell takes time to actually discuss a technical problem, whether it's design or a programming problem, as the solution unfolds. The desire to shoehorn an interview into at most 1-hour slots is not designed to find the best candidates. From where I look at things, it's designed around the idea that most business meetings are booked for one hour each, and the cadence in the day must fit the business of, well, doing business. And it kind of works, because everyone (or near it) has the context and shape of the problem fairly clear in their heads. But for an interview? A process, where by definition you are dealing with people who are not well versed in your business? Companies book 1-hour interview slots because it's convenient - for their employees, including those who have no part in the interview process, but who are expected to attend other 1-hour meetings with the people who are involved. The gauntlet of 1-hour interviews feels like a very much intended consequence of the organisation thinking in terms of 1-hour slots for everything. The result is a grueling exercise very few like, and almost everyone with experience despises. It's bad for the candidates, it's bad for interviewers, and I'm pretty sure it's bad for the companies. But it keeps getting done that way because the cargo-cult of 1-hour slots for everything can not be reasoned with, or deviated from, results be damned. Just think how well you would do the engineering and programming part of your profession if you had to carve everything into 1-hour slots. After all, PG wrote about it back in 2009: http://www.paulgraham.com/makersschedule.html http://www.paulgraham.com/makersschedule.html
  - google234123 7y ago
    For all you know they might have just followed some online tutorial.
    - read_if_gay_ 7y ago
      You can figure out whether they actually understand what they’ve done by asking the right questions. E.g. not “how did you do that” but “why did you do it this way and not that way?”
lsalvatore 7y ago
One time I hired someone who provided a very intellectually stimulating conversation over the phone. He couldn't ship anything. Now, I make sure I ask someone a question over the phone, and watch them code. You could call it an IQ test. I call it a technical interview.
hoorayimhelping 7y ago
You ever worked with someone who was really good at setting up environments? Or really good at refactoring the structure of the code? They'd always be pushing fixes and updates, and writing tutorials on the perfect environment set up, but when you look at their work, you realize they never actually shipped any products that required taking a risk or trying something unknown. All they did was restructure code that other people wrote. These people are really good at having intellectually stimulating conversations. They're the kind of people who lurk on hobby forums and can tell you all about the hobby, but have never actually done it themselves. They're the people for whom the phrase, 'do you even lift' was coined. They'd lurk on /fit/ and talk about form and theory, but would never post any videos of themselves. They can tell you why you want to drive your hips out of the bottom of a squat, but they've never actually felt what it's like to be at the bottom of a squat and want to just give up and have to grind through it. They're the people who watch twitch streamers and think they're good at the game cause they understand the decisions the streamer was making, but they've never actually had to make those decisions themselves under pressure. I've worked with a handful of these people over the years. They usually get in early and embed themselves in way that makes them seem important or very knowledgeable.

by dvt 7y ago

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.
    - lsalvatore 7y ago
      How much faith do you really have in these questions? This could be your entire 45 minute interview: Where there any performance considerations: Yes, the spaceship was extremely slow at first. After reverse engineering the launch protocol, we discovered that we could increase speeds by 5x simply by limiting the fuel cell usage. "Oh tell me about your rocket fuel cell usage"- Well, we have this thing called a fuel cell. It takes 5 batteries. 10 minutes of business logic later... * Now let's spend 25 minutes talking about infrastructure and team dynamic * Concurrency: None needed here. What did they do for testing: We used Jest. Was it automated: Yes. How was it deployed: Github / Heroku / AWS Do you maintain it: Yes, we maintain it with my little green friends. We each take turns writing code and maintaining the rocket protocols. It's actually quite nice. * Oh, well I guess we're out of time. * Congrats, you just hired a guy who read a few blogs and made up a few stories.
      - bostik 7y ago
        > your entire 45 minute interview There's your problem. Right there. I don't think we can evaluate whether someone can do a decent job in 45 minutes. Or an hour. Sure, we can spot and confirm a hopeless case in 20. But beyond that, an hour is simply not enough. I've been involved in hiring and interviewing for close to 15 years. The best results have been with candidates with whom I've arranged to have at least 90 minutes, and where that time ended up being well spent. It takes a while to get comfortable, to warm up, to establish a common ground. And it sure as hell takes time to actually discuss a technical problem, whether it's design or a programming problem, as the solution unfolds. The desire to shoehorn an interview into at most 1-hour slots is not designed to find the best candidates. From where I look at things, it's designed around the idea that most business meetings are booked for one hour each, and the cadence in the day must fit the business of, well, doing business. And it kind of works, because everyone (or near it) has the context and shape of the problem fairly clear in their heads. But for an interview? A process, where by definition you are dealing with people who are not well versed in your business? Companies book 1-hour interview slots because it's convenient - for their employees, including those who have no part in the interview process, but who are expected to attend other 1-hour meetings with the people who are involved. The gauntlet of 1-hour interviews feels like a very much intended consequence of the organisation thinking in terms of 1-hour slots for everything. The result is a grueling exercise very few like, and almost everyone with experience despises. It's bad for the candidates, it's bad for interviewers, and I'm pretty sure it's bad for the companies. But it keeps getting done that way because the cargo-cult of 1-hour slots for everything can not be reasoned with, or deviated from, results be damned. Just think how well you would do the engineering and programming part of your profession if you had to carve everything into 1-hour slots. After all, PG wrote about it back in 2009: http://www.paulgraham.com/makersschedule.html http://www.paulgraham.com/makersschedule.html
- google234123 7y ago
  For all you know they might have just followed some online tutorial.
  - read_if_gay_ 7y ago
    You can figure out whether they actually understand what they’ve done by asking the right questions. E.g. not “how did you do that” but “why did you do it this way and not that way?”

lsalvatore 7y ago

One time I hired someone who provided a very intellectually stimulating conversation over the phone. He couldn't ship anything. Now, I make sure I ask someone a question over the phone, and watch them code. You could call it an IQ test. I call it a technical interview.

hoorayimhelping 7y ago

You ever worked with someone who was really good at setting up environments? Or really good at refactoring the structure of the code? They'd always be pushing fixes and updates, and writing tutorials on the perfect environment set up, but when you look at their work, you realize they never actually shipped any products that required taking a risk or trying something unknown. All they did was restructure code that other people wrote. These people are really good at having intellectually stimulating conversations. They're the kind of people who lurk on hobby forums and can tell you all about the hobby, but have never actually done it themselves. They're the people for whom the phrase, 'do you even lift' was coined. They'd lurk on /fit/ and talk about form and theory, but would never post any videos of themselves. They can tell you why you want to drive your hips out of the bottom of a squat, but they've never actually felt what it's like to be at the bottom of a squat and want to just give up and have to grind through it. They're the people who watch twitch streamers and think they're good at the game cause they understand the decisions the streamer was making, but they've never actually had to make those decisions themselves under pressure. I've worked with a handful of these people over the years. They usually get in early and embed themselves in way that makes them seem important or very knowledgeable.