No, you're crazy! (or, the problem with assuming that computer programmers have all that much in common)
![CropperCapture[96]](http://static.flickr.com/2099/2240863575_349455f83d.jpg)
Five Non-Essential Phone Screen Questions Which Tell Me Nothing
Jeff Atwood recently linked Steve Yegge's post on Five Essential Phone-Screen Questions. My first impression was that it was horrible advice. For reference, here's the five areas which Steve considers essential in eliminating poor job candidates:
- Coding. The candidate has to write some simple code, with correct syntax, in C, C++, or Java.
- OO design. The candidate has to define basic OO concepts, and come up with classes to model a simple problem.
- Scripting and regexes. The candidate has to describe how to find the phone numbers in 50,000 HTML pages.
- Data structures. The candidate has to demonstrate basic knowledge of the most common data structures.
- Bits and bytes. The candidate has to answer simple questions about bits, bytes, and binary numbers.
He goes on to give some example questions, including the following:
- What's the worst-case insertion performance of a hashtable? Of a binary tree?
- What are some options for implementing a priority queue?
- Format an RGB value (three 1-byte numbers) as a 6-digit hexadecimal string.
- Tell me how to test whether the high-order bit is set in a byte.
- Write a function to count all the bits in an int value; e.g. the function with the signature
int countBits(int x)
Now, in fairness, both Jeff and Steve were careful to clarify that these aren't go/no-go questions. The idea is to use these to determine if an applicant has a total void of knowledge in a fundamental area.
However, I still believe that Steve's questions would be useless in hiring someone to work on my current projects. I don't care if a candidate can check if a high-order bit is set, to the point that I might be a little turned off by an applicant whose answer revealed they were a bit-twiddler. I've hired bit-twiddlers before, and while they interviewed well, they weren't much help in shipping applications. Worse, we're wasting valuable time talking about hexadecimal formatting when we should be covering things like database access and rudimentary knowledge of HTML and HTTP. An applicant could ace the above questions and be clueless on where to start with constructing a web application.
You see my error, don't you?
Steve Yegge works for Google. Steve and I are both professional programmers; in fact we both work on web applications. Yet, our jobs are no more related than if we were both doctors in different fields - say, a podiatrist and an orthodontist. For example, if you work for Google, you're going to be concerned with how to make your applications run against huge data sets using large, unreliable computer clusters. None of those are priorities in applications I work on, since I'm generally working against a relational database which aren't running at high volume or scale. So, Steve is thinking about how to build Google-scale applications running on Map/Reduce, while I'm working on comparatively small projects running against relational databases.1
As Dare points out, it's incorrect to view that dichotomy and try to pick a winner in a fight between Map/Reduce and Relational Databases. Both are tools, used to solve very different problems. Problems which are so different that those who solve them are essentially in different lines of work.
Different enough that Steve Yegge isn't qualified to interview people who will work on my projects (nor I, his).
Computer Programming: A Field, Not A Job Description
The field of computer programming is a wide one, a fact we seem to ignore when blogging about "the way computer programming ought to be done." It's amusing to read comments on popular blog posts (e.g. just about anything Jeff writes) and watch the arguments:
- You're crazy! There's no way programmers should [insert topic here]! I've never had to do that in fifteen years of professional development!
- No, you're crazy! I just coded it up in Lisp last week, and anyone who can't isn't a real programmer!
Of course, the real answer is that both people are crazy for assuming that they're colleagues.
Information Is Useless Without Context
Steve Yegge is the guy to listen to - especially if you want to know about writing Lisp in Emacs, or managing a 500KLOC Java game you wrote in your spare time. Joel Spoelsky is an undisputed expert - on running a business that produces wonderfully usable bug tracking software (on classic ASP and PHP).
And since you're here, I'll mention that my field of expertise: I specialize in ASP.NET web applications running on SQL Server, generally slanted towards the bleeding edge of Microsoft technologies. It's been a decade since I shipped production C++ code, and I haven't been paid to write PHP code in seven years. I spend an inordinate amount of time reading about what's going on outside of my speciality, but I know the limits of my expertise, and so should you. When you're reading my opinions you be aware of my background for three reasons:
- You should know when I'm speaking from experience (as opposed to just making stuff up)
- You should be aware of any bias or unspoken assumptions that I bring to an opinion, such as assuming that most non-academic applications will work with relational databases
I don't believe that we should require authors to bury their opinions in weasel words and disclaimers. Rather, as readers, we need to appreciate the author's context and bias, and intelligently translate their opinions to our context.
And It's Not Just About Differing Fields Of Expertise, Either...
I've noticed that unspoken bias and context often explains a lot of long-running arguments. For example, I had a long running argument with another developer over WinMerge vs. Beyond Compare. I'm talking about a blood feud spanning years, raging in the battleground of inexpensive file merge applications. Finally, we got on the phone and spent an hour, taking turns explaining why we thought our application was superior. When we were done, we both understood the real issue: he primarily used Beyond Compare to deploy files to a webserver, while I used WinMerge to handle source merges in Subversion. We'd come up with different answers to the question of "What's the best file diff/merge utility" based on different, unspoken assumptions as to what the utility would be used for.
The same sort of solution seems to be useful in just about any seemingly intractable argument in our field. Is there a case in which your views on Test Driven Development wouldn't apply? Your thoughts on dynamic SQL vs. stored procedures? Project management methodologies? Your decisions to use Microsoft software or GPL software (or both, or neither)? Managed code environments vs. C and C++?
1 Just for context, I think I could adequately answer just about every question on Steve's list. I'm not being defensive, I'm arguing that these questions don't come close to defining the successful developers I work with.