Recently, I have had a couple of companies give programming tests to individuals that have had code accepted for an open source project. Why is that? Sometimes I have a hard time understanding what is going to be gained by doing so. I have always been under the impression that if your code is accepted by a particular project, that is a testament to your abilities to program in that language. At the very least, it is the perfect opportunity for a company to take the necessary time to review the code to determine ones ability. Most of the time, below par code is not allowed into an open source project. Just the process of elimination given the competition.
However, for some apparent reason unbeknownst to me, that universally visible code is not enough. Again, I ask why is that? Corporations constantly are trying to evolve the hiring process at their companies. Meanwhile, they lose sight of the core of the mission at hand. While all this "trickery" takes place with exams that usually have gray areas, people that could be great assets to achieve the corporate mission are passed over. Perhaps that does not hurt them tremendously at the moment given the economic environment, but over time, it will provide a challenge for them.
Everyone wants to find the best person for the job. That should be the goal of every open job requistion. In order to do so, perhaps some of the processes that are put in place should be examined given the position at hand. Does a person that has viewable code out there need to be given a debatable quiz on code structure? I, of course, think not. But, I realize that is just my opinion. Let me know what you think.
Subscribe to:
Post Comments (Atom)
2 comments:
Hi Brent,
Having just interviewed someone who has had code submitted to the kernel, I have to say we were very disappointed when we threw a few programming questions at him. He didn't even get off first base, even with quite a bit of coaching. Clearly he wasn't going to fit in with our team or culture if he can't brainstorm code. There are some kinds of open source development (perhaps fixing device drivers for a vendor) that are very structured, and maybe don't lend themselves to creative programming.
I guess you could argue that some people don't test well...and that could certainly be true...but everyone has their favorite filters...
Dave B
I started a job back in April as a senior Linux administrator, running 125 servers for an ISP. Normally I've been interviewed and then tested, but this company did the testing first- apparently they had already found several people who looked nice in a shirt and tie and who interviewed well, but who didn't really know what they were doing when it comes to Linux. Apparently some of the people who had taken (and not even remotely passed) the technical test were former system administrators for other companies, with several years of experience. After talking to them, they were truly surprised that most of these people couldn't even fix a simple grub issue.
They got tired of wasting time interviewing people who didn't have the knowledge and experience for the job, so they started doing the technical test first.
Granted, this was for a system admin job rather than a programming job, however I think the situation would be very similar for a programming job, especially if the job involves working on a team with other programmers. Just because your code was accepted for one open-source project doesn't necessarily mean you're going to be a good fit for every project in the world.
Each job has its own requirements. A properly written programming test can tell whether the applicant has the skills and knowledge needed for that particular project, as well as whether or not their code is going to "fit in" with the other people involved in the project. Not only does the applicant have to be able to work with the existing code, but the existing programmers need to be able to work with the applicant's code as well.
As the first comment said, some jobs require different degrees of being able to think on your feet. I've had programming jobs where somebody else had already designed the overall structure of the final product and I was just writing code for specifically defined pieces of that overall structure. I've also had jobs where I was designing the overall structure AND writing part of the code.
I've known people who could write code all day long by themselves, but ran into trouble when they had to write code which interfaced with other peoples' code. I've also known people where just the opposite- they were fine when working within a strict framework, but couldn't handle the more creative processes involved in architecting a project. Personally, I find myself to be more productive when working alone, however I'm okay with being part of a group project as long as I understand how my own code fits into the larger framework of the project.
Different projects involve different kinds of situations, and having your code accepted for an open source project doesn't necessarily mean that somebody is going to be a good match for every project in the world. I think employers owe it to themselves to at least try and make sure that an applicant is going to "fit" into the project, not only in terms of technical skills and knowledge, but also in terms of being able to think on their feet, or to follow an existing framework, as the project requires.
Post a Comment