6 ms·

My experience is that knowing who's a good programmer is like knowing what's art: you know one when you see one. That's why I don't get the coding interview.

My experience is that knowing who's a good programmer is like knowing what's art: you know one when you see one. That's why I don't get the coding interview. Just an everyday conversation with a coder will give you a better idea whether he's any good or not, and it will do this without stressing him out or impugning his integrity (which is exactly what you're doing when you ask someone a bunch of trick questions on a subject they've already claimed expert knowledge on in their resume).

steego 10y ago
I'm skeptical. There's always a set of programmers who sound erudite because they are erudite. It's typically not that easy to fake being erudite, so it naturally follows that programmers who sound and behave like they're competent are usually competent. A simple strategy would to always select from that pool. It might even be a relatively optimal strategy too if you account the time and effort to interview people. However, my experience has show me that assumption has been wrong on a number of occasions. People have both surprised me and disappointed me. I wish I could say it's been the rare case, but it's happened a lot more than I would have liked. I've considered I'm not the best judge of people, but I can't help but notice a lot of my colleagues aren't the best either. Some are and I envy their talents to notice some set of heuristics I haven't picked up yet.
- koverstreet 10y ago
  It's not about being erudite, or knowing lots of things. What you pick up on when you're having a conversation with another programmer about writing code is whether or not they give a crap about their craft and doing it well, and what kinds of things they think about and worry about in their code and the code they work with. The really good programmers are the ones who want to make the world of software a better place, without concern for ego or who wrote what.
  - jstewartmobile 10y ago
    Thank you koverstreet for putting it into words better than I could.
- jstewartmobile 10y ago
  Whenever I've had a problem with a hire, it has never been a competence problem. If I gave those people code problems, they would have knocked them out of the park, I still would have hired them, and I still would have had the problem.
danderino 10y ago
I completely agree with you. A simple conversation with someone is far more telling then having someone fixate on a single problem for 40 minutes

steego 10y ago

I'm skeptical. There's always a set of programmers who sound erudite because they are erudite. It's typically not that easy to fake being erudite, so it naturally follows that programmers who sound and behave like they're competent are usually competent. A simple strategy would to always select from that pool. It might even be a relatively optimal strategy too if you account the time and effort to interview people. However, my experience has show me that assumption has been wrong on a number of occasions. People have both surprised me and disappointed me. I wish I could say it's been the rare case, but it's happened a lot more than I would have liked. I've considered I'm not the best judge of people, but I can't help but notice a lot of my colleagues aren't the best either. Some are and I envy their talents to notice some set of heuristics I haven't picked up yet.

koverstreet 10y ago
It's not about being erudite, or knowing lots of things. What you pick up on when you're having a conversation with another programmer about writing code is whether or not they give a crap about their craft and doing it well, and what kinds of things they think about and worry about in their code and the code they work with. The really good programmers are the ones who want to make the world of software a better place, without concern for ego or who wrote what.
- jstewartmobile 10y ago
  Thank you koverstreet for putting it into words better than I could.
jstewartmobile 10y ago
Whenever I've had a problem with a hire, it has never been a competence problem. If I gave those people code problems, they would have knocked them out of the park, I still would have hired them, and I still would have had the problem.

danderino 10y ago

I completely agree with you. A simple conversation with someone is far more telling then having someone fixate on a single problem for 40 minutes