Number of bugs definitely not, especially if he's maintaining a large or well-established code base. It is common for someone to be bogged down with problems r

Number of bugs definitely not, especially if he's maintaining a large or well-established code base. It is common for someone to be bogged down with problems rooted in someone else's past design. Also, if you're going to give bug reports any weight, you have to read them fully; a single bug report could point to incredible incompetence, while another developer's 20 bugs combined could all be really minor issues. Code reviews might be more applicable. But, like bug reports, the code being reviewed could be as much the fault of past developers as the person trying to make changes. There is also a tendency for peers to focus on minor issues like coding style, so make sure your reviews are covering real problems before you attach too much weight to the results. Having said that, this is what I would do: First, judge a programmer based only on the experience he claims to have. It's just not fair to dump a new programmer onto a team and expect brilliance; if his team is relatively brilliant, he will always appear incompetent. You should, however, expect improvements over time (such as, less time required to fix things, or more instances where he speaks up with new ideas). Next, judge a programmer based on individual work. Every programmer should have some task, even a small task, that is only theirs, even if the majority of the work requires teams. This makes it easier to judge how the programmer tackles problems, how code looks, etc. This also avoids the pitfalls above, as there are no excuses. Also, some programmers work best alone; you should be seeing their best work, and if that is shoddy, you should get rid of them. Only after considering the above, should you look at team work on large code bases.