It made me start thinking about the value of good Java programmers. If you scan craigslist, you'll find a lot less Java freelance work than PHP. Looking at Elance, there were 75 PHP projects but only 29 Java projects, in web development. So it's a lot harder to talk about Java freelance work, and what's valuable, etc. It seems that most Java developer probably work for a company, instead of doing freelance work. It is also well known that Java development is more costly, which is probably why there is less freelance work -- typical food chain kind of thing.
One of the great points that Ben makes is that when doing freelance work, you should never under-bid. I agree with this, even though I definitely don't obey this. You see, I love doing freelance "moonlighting" work in my spare time. To me it's a chance to try out new technologies and hone my craft solving real world problems. Plus it's extra money, and who doesn't like that? Finally, I learned a valuable lesson when I was working for a consulting company. For any given project, there's at least twice as much money to be made as the client says there is. So if I see project out there with a fixed bid of $2000, I assume there's a pretty good chance I'll make $4000 in the end. Still, I think Ben is right. I underbid only when the project is an "investment" for me, i.e. a chance to learn or try out a new technology that I'm interested in.
Ok, so on the other side of things, how do you tell if somebody is a good programmer? I'll talk mostly about Java programmers, though most of my analysis is valid for many other kinds of programming. Let's get that out of the way first, actually.
So what's make a good Java programmer? They need to be a good programmer, period. That means the ability to think analytically and abstractly. Now that is a more difficult combination than you might think. I'm actually not as big on the kind of logic puzzle and brain teasers that are popular at Microsoft and now Google is famous for. I was recruited by Google last summer, and while I found some of the questions fun, I found little value in many of them.
I like problems that I see more of a direct connection to programming. It's not hard to come up with such problems, they're all around you. Just ask a non-programming friend about their job. Listen to what they do, then ask about things that are boring/tedious for them. These are all programming projects waiting to happen.
Of course it's also nice to take more "known" problems, i.e. problems where the solutions involve concepts that are common in the programming world. I was also recruited by Yahoo last summer, and they had much better questions there. Unlike with Google, I didn't sign an NDA about their process so I can talk about some of the questions they asked me. I interviewed with one of their search teams, and one problem I liked was about how to figure out the most frequently searched for terms. This is the basis for their Buzz Index. Anyways the problem boiled down to having lots of different data sources that kept track of searches and having to aggregate things efficiently. It's a real world problem where knowledge of data structures (heaps in this case) were helpful. But even if you didn't know about a heap, you could still come up with a good solution. Or even better, you could come up with a bad solution and the interviewer had the chance the criticize and give you a chance to improve on your solution. An English professor of mine loved to say that "writing is revision" and the same is true of programming.
So to me that was a good programming question. Of course I may be biased since I did well on the question. I think it's a much better question than "what is a heap?" or even "what is a heap and when would you use it?"
As for more Java specific things... Understanding the JVM is important to me, especially with regards to the trade-offs you make when you use Java instead of other programming languages. Despite what I do for a living, I'm a big believer in "right tool for the job." Most people (me included) don't usually have that luxury, i.e. you are quite limited in what tools you can use for a given job. Doesn't dimish the value in recognizing the limits of Java (or whatever) on a given task, and thinking about how some other technology might address the problem more easily. I don't like to get too involved in Java specifics. If people mention specific areas of expertise, then I do feel obliged to probe. That's as much about verifying integrity as it is about testing their knowledge.
And that brings me to my last point. There are many qualitative things that I look for in interviews. It's not just how good of a solution to a problem people come up with, it's how well they articulate it and how quickly they can solve it. If they get stuck, do they ask questions? If you give them help, how do they use it? For that matter, how quickly do they grok the problem at all? I also like to make stupid comments or questions. I like to see if they will reject this. These are all things that are good indicators of how productive they are going to be in the long run, and how much value they will add to my team.
Technorati Tags: programming, java, interview questions
No comments:
Post a Comment