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 are slides from my presentation at the Boulder/Denver Ruby Group on “Simple MapReduce with Ruby and Rinda.” This is much of the same material as my article on the topic, but it focuses on the high points and perhaps better illustrates what’s going on. If you were at the meeting and have comments on the presentation, or have time to play with MapReduce, shoot me an email and let me know!
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.
Here are slides from my presentation at the Boulder/Denver Ruby Group last night. It’s Ruby-focused “Lessons Learned” based on the project I’ve been leading this year, the software for Spectra Logic’s new disk arrays. Topics covered include embedded vs. Internet web servers, interfacing with hardware and 3rd party tools, text processing, and a lot of Ruby on Windows stuff.
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.
