Nick Mudge Ignition Software Consulting & Development

It seems like I've read a lot about the question "How do you know if someone is a good programmer or not?" And I've been surprised by the answers. I've read good programmers saying that they can't really tell if other potential programming candidates are good or not. I've read about the puzzle and algorithm type questions Google or Microsoft might give.

Maybe I am naive, I've never had to hire a programmer, but it sounds kind of easy to me. If you know programming and know good programmers, can't you tell if someone else knows programming and is anything like a good programmer?

If I were looking at hiring someone I would get the candidate talking about programming. I don't think it matters that much what the candidate talks about, just get him talking about it and his experiences. In discussing programming does the candidate talk about specific things and examples that demonstrate understanding of practical programming techniques or ideas? Or does he just use buzz words without relation to actual programming? Does it seem like the other programmers in the company will get along with this person? Are his interests in programming a good match for what you want to hire him for? I would also ask the candidate to send me some code he wrote that he is proud of and look it over.

I was prompted to write this post from what Bendan Eich had to say about hiring and recognizing programming talent in the book Coders at Work. I really liked what Bendan had to say about the subject. He's the kind of guy I'd want interviewing me for a job.

I've been reading the new Coders at Work book. It is great. I'm reading it straight through and I'm in the middle of the interview with Joshua Bloch. One really interesting subject that has been brought up in that interview is the trade off of power and complexity in programming languages.

It seems that the more power and flexibility you add to a programming language the more complexity you add to it. The more complex a language is the harder it is for programmers to understand it, read it and maintain it. Also the more complex it is the more likely it will be subsetted which can reduce the portability of the language among programmers. One programmer may know one subset of a language and another programmer a different subset. C++ seems a fine example of this.

That brings up some interesting questions. What philosophy should you take in creating a new programming language that you simply want to be beautiful and awesome? I know that's pretty general, but I'm kind of general about it right now. I think I tend toward the minimalist language design where you design a small powerful language from which you can build up complexity in different directions. Lispy sounding, isn't it? I wonder what other languages are like that.