This article is written with considerable snark--put on your flameproof suit if needed. I'm not actually a jerk when interviewing people, but I do get frustrated when candidates fail to do basic preparation. If you're unsure about how to prepare for a programming interview, read on...
I know this might come as a shock to you, but most programming job applicants suck. I’ve interviewed my fair share this month, and it’ll be a lot easier for all of us if I tell you upfront what I’m looking for.
As a hiring manager, my job is to make sure you can do the job you’re applying for. For programming that means you need to be able to program. So when I whip out a laptop in our round-one interview and ask you to write some code, try to hide your terrified expression.
Here’s a simple version of the MapReduce framework presented in the now-famous Google paper by Dean and Ghemawat. My version of MapReduce is not intended as a usable high-performance framework, but rather as a learning tool. My goal is twofold: first, to learn to write algorithms in distributed/parallel MapReduce style. Second, to see how simply these concepts can be expressed in Ruby.
I use the Rinda framework to distribute tasks to remote workers. This simplifies a great deal of the MapReduce grunt work. The map and reduce code, along with data, is marshaled and sent over the network transparently. Creating a MapReduce job is as easy as creating an object, assigning lambdas for map and reduce, assigning data, then telling it to run.
I have over a decade of professional C++ experience, but I don’t call myself a “C++ Programmer.” Am I competent with programming in C++? Yes, very much so. But I refuse to let my skills be pigeon-holed by the language I’ve historically used. Nor should you.
Use the right tool for the job, the saying goes, and software development is no exception. Programming languages, frameworks, and other tools are the subject of religious-caliber debate but they are just means to a greater end. This article is a call to both programmers and their managers: a good programmer cannot be summed up by the list of tools they use.
Last night I attended the inaugural meeting of the Boulder-Denver Ruby User’s Group. “Meeting” was a term used in the loose sense–it was more a gaggle of Ruby enthusiasts sitting around tables with beer, chatting about Ruby and other geek stuff. The meeting was held at a brewery, so it was impossible to hear people more than a couple feet away, but as the group shifted around I probably talked with half a dozen others.