4 ms·

Maybe it's just me, but when I look for great programmers, their ability to solve coding challenges is really the least of my problems. In my experience, the a

by rickmb 15y ago

Maybe it's just me, but when I look for great programmers, their ability to solve coding challenges is really the least of my problems. In my experience, the ability to leverage those skills into delivering mature, stable, maintainable and generally high quality software is considerably rarer than the skill to solve puzzles. And don't even get me started on non-technical skills, like being able to organize and plan the work, communicate with non-technical people etcetera. Basically, I don't see this kind of testing covering more than 5% of the screening effort.

timr 15y ago
You're not the only one. The more experience I get developing software with other people, the more I value stuff that isn't really captured by coding interviews: * do you thoroughly document your code without nagging? * do you value simplicity over cleverness? * do you think communication is a chore? * do you enjoy human interaction? * do you have empathy? * are you creative? * do you have good taste? Googrosoft-style interviews are great for selecting people with raw intelligence, a competitive streak and some level of arrogance. They're not quite as hot at selecting reasonably smart people who are personable, creative and tasteful. And that's a huge portion of the job when you're writing software in a group. Very little day-to-day software work requires raw brilliance, but nearly all of it requires communication, empathy, creativity and taste.
- jebblue 15y ago
  Well stated man totally well stated.
- rorrr 15y ago
  And how do you test for all of these things that you listed during an interview? I've been in charge of technical interviews for a large corporation for a year and a half, and there have been many truly shitty developers who couldn't solve even simple programming problems, but they knew how to bullshit, and they would totally ace your questions.
  - timr 15y ago
    "I've been in charge of technical interviews for a large corporation for a year and a half, and there have been many truly shitty developers who couldn't solve even simple programming problems, but they knew how to bullshit, and they would totally ace your questions." Well, first, it's not like I just ask someone if they enjoy documenting code, and expect them not to lie. That would be stupid. It's much easier to just ask coding questions than to figure out if someone is creative. That's why the problem is hard. Second, how do you focus on the other important factors, and still manage to test for coding ability? You ask coding questions -- you just don't devote the entire interview process to them.
diego 15y ago
Relevant, my blog post from a couple of weeks ago. http://blog.indextank.com/1030/interviewing-engineers-enough-with-the-whiteboard-coding/ http://blog.indextank.com/1030/interviewing-engineers-enough... TLDR: Most companies put too much emphasis on testing IQ and don't know how to evaluate what makes people great at building stuff that the company needs.
bradly 15y ago
I totally agree. Last year I interviewed at two YC companies, AirBnB and Heroku. At AirBnB the interview went great, but then I was given a 3 hour programming challenge that including a written analysis of my code. The challenge was not at all related at all to building web apps, and even the use of a database was not allowed to be used to solve the problem. At Heroku, we discussed a real issue they were having and halfway through the interview we were both up at the whiteboard bouncing things back and forth, drawing things up. At the end of the Heroku interview we both knew how the other worked and how we would work together.
- thomasgerbe 15y ago
  "At Heroku, we discussed a real issue they were having and halfway through the interview we were both up at the whiteboard bouncing things back and forth, drawing things up. At the end of the Heroku interview we both knew how the other worked and how we would work together." I find this kind of odd and correct me if you think I'm off because I'm not a programmer. But for any company to give you a problem that they are having and for you to help them solve it... shouldn't you get compensation for that (outside of a job position)? That's basically free consultation. It's like how some companies give design tests for designers, which is basically spec work. Even if they don't choose you, they could still take some of the ideas and implement it. It's one thing to give a general problem and analyze your problem solving skills and knowledge (as well as to verify your resume).
  - joshuacc 15y ago
    There is a difference between talking about how to solve a problem, and actually implementing the solution. Talking with a designer about the problems they would be facing and about how they would approach some of them is very different than having them implement the solution (a complete design). I suspect the same applies to programmers. As long as you're not asking for the implementation (working code), it's probably fine.
    - thomasgerbe 15y ago
      "There is a difference between talking about how to solve a problem, and actually implementing the solution." Is there? You are giving your expertise with the intention of improving their situation and potentially saving them time. It's not uncommon to get paid to consult about problems that a team is facing without actively implementing it yourself. How is this any different?

by rickmb 15y ago

timr 15y ago

You're not the only one. The more experience I get developing software with other people, the more I value stuff that isn't really captured by coding interviews: * do you thoroughly document your code without nagging? * do you value simplicity over cleverness? * do you think communication is a chore? * do you enjoy human interaction? * do you have empathy? * are you creative? * do you have good taste? Googrosoft-style interviews are great for selecting people with raw intelligence, a competitive streak and some level of arrogance. They're not quite as hot at selecting reasonably smart people who are personable, creative and tasteful. And that's a huge portion of the job when you're writing software in a group. Very little day-to-day software work requires raw brilliance, but nearly all of it requires communication, empathy, creativity and taste.

jebblue 15y ago
Well stated man totally well stated.
rorrr 15y ago
And how do you test for all of these things that you listed during an interview? I've been in charge of technical interviews for a large corporation for a year and a half, and there have been many truly shitty developers who couldn't solve even simple programming problems, but they knew how to bullshit, and they would totally ace your questions.
- timr 15y ago
  "I've been in charge of technical interviews for a large corporation for a year and a half, and there have been many truly shitty developers who couldn't solve even simple programming problems, but they knew how to bullshit, and they would totally ace your questions." Well, first, it's not like I just ask someone if they enjoy documenting code, and expect them not to lie. That would be stupid. It's much easier to just ask coding questions than to figure out if someone is creative. That's why the problem is hard. Second, how do you focus on the other important factors, and still manage to test for coding ability? You ask coding questions -- you just don't devote the entire interview process to them.

diego 15y ago

Relevant, my blog post from a couple of weeks ago. http://blog.indextank.com/1030/interviewing-engineers-enough-with-the-whiteboard-coding/ http://blog.indextank.com/1030/interviewing-engineers-enough... TLDR: Most companies put too much emphasis on testing IQ and don't know how to evaluate what makes people great at building stuff that the company needs.

bradly 15y ago

I totally agree. Last year I interviewed at two YC companies, AirBnB and Heroku. At AirBnB the interview went great, but then I was given a 3 hour programming challenge that including a written analysis of my code. The challenge was not at all related at all to building web apps, and even the use of a database was not allowed to be used to solve the problem. At Heroku, we discussed a real issue they were having and halfway through the interview we were both up at the whiteboard bouncing things back and forth, drawing things up. At the end of the Heroku interview we both knew how the other worked and how we would work together.

thomasgerbe 15y ago
"At Heroku, we discussed a real issue they were having and halfway through the interview we were both up at the whiteboard bouncing things back and forth, drawing things up. At the end of the Heroku interview we both knew how the other worked and how we would work together." I find this kind of odd and correct me if you think I'm off because I'm not a programmer. But for any company to give you a problem that they are having and for you to help them solve it... shouldn't you get compensation for that (outside of a job position)? That's basically free consultation. It's like how some companies give design tests for designers, which is basically spec work. Even if they don't choose you, they could still take some of the ideas and implement it. It's one thing to give a general problem and analyze your problem solving skills and knowledge (as well as to verify your resume).
- joshuacc 15y ago
  There is a difference between talking about how to solve a problem, and actually implementing the solution. Talking with a designer about the problems they would be facing and about how they would approach some of them is very different than having them implement the solution (a complete design). I suspect the same applies to programmers. As long as you're not asking for the implementation (working code), it's probably fine.
  - thomasgerbe 15y ago
    "There is a difference between talking about how to solve a problem, and actually implementing the solution." Is there? You are giving your expertise with the intention of improving their situation and potentially saving them time. It's not uncommon to get paid to consult about problems that a team is facing without actively implementing it yourself. How is this any different?