Programmers Can't Interview
I saw Shelly Powers' post on how the computer field is broken. I'm terrible at interviewing, first of all. I've had to do it enough that I can put together a possibly reasonable idea of how a candidate will work out, but I don't feel like I'm really that good at it. Shelley has a number of good ideas, most notably:
Providing applications and having the person provide their own critique is an amazingly effective way of getting insight, not only into their problem solving skills, but also into their personality.
I used to do things like this: provide a piece of code and ask how it could be improved. What I wanted to see was whether people picked up on how errors were being handled, or obvious refactoring situations (nearly identical code segments back-to-back). My problem was to phrase the actual question in a way that wouldn't give away the answer I was hoping to hear. Possibly I shouldn't have worried about that, and just asked the candidates to show me the opportunities for refactoring.
My other favorite test was to ask a candidate to write a small WinForms program in C#. This assumed a few things: that the candidate had a passing familiarity with WinForms (in which case, I wouldn't give the test), and that the candidate knew C#, which was a requirement for the position. The problem was stated thusly: write for me a WinForms program that consists of 3 text boxes. When a number is entered into either of the first two boxes, the third is automatically updated with the sum of the first two numbers. At the lowest level, this really only requires that the candidate know about int.Parse(String) and how to set up the Control.OnTextChanged event. I felt that a mid-level programmer should be able to complete this in about 10 minutes. I would just sit back and try to be unobtrusive. In my experience, everyone I interviewed could do meet the 10 minute standard, some with more fumbling than others, but because they could use the compiler and run the program, the feedback loop made the process much less intimidating. Once the program was running, then we could get on to a discussion of design:
-
How do you handle errors? Invalid inputs, sums out of the range of integer values, etc.
-
How would you refactor this to allow for different operations other than addition?
-
How would you refactor this to allow for other numeric types (float, BigDecimal)? What would the challenges be?
-
How would you do this if it was a really long running operation, like mathematical operations on really huge numbers? The point of this question is that the candidates almost always handle TextChanged as a synchronous operation, so I would try to get them to think about how to unlock the GUI for a long operation. I didn't really care about the GUI part of it, but I wanted to see how they thought about asynchrony: launch an explicit thread, queue an event to the thread pool, whatever.
-
How do you know this works?
The last question is the key, because this should lead into a discussion of testing philosophy, and hopefully into a discussion of automated testing. I don't think any of these were deciding factors, though. After all's said and done, on any programming team, what you want is a group of individuals who agree to do things in the same way, or a compatible way, and not spend time arguing over how many spaces are in a tabstop, or where the curly braces go, or really much of anything. In a team environment, negotiation is key, and what I really want is for people who, when not in a position of explicit leadership, either know how to present their case and live with it if the leadership overrules them, or people who are accept direction from the start. I've found that programming jobs ultimately don't involve much programming, relative to the amount of time you spend doing debugging, operational support, testing, all the things that don't involve writing much code but seem to require somebody who knows how the code is written.
The entire scenario posited in the original is pretty dumb, I agree. The idea of asking programmers to program on paper was perhaps valid back when programming was actually done on paper punch cards. These days, it's just dumb. Let alone the fact that the artistically challenged such as myself can't draw a legible curly brace to save my life, I just don't write production code on paper. I rely heavily on my editor, and I personally don't care whether a candidate can create a solution on paper.
Also, the comments on the original post tend towards the priceless:
Very very common, alas. I once interviewed a candidate for a VBA job (yes, you can stop booing for the peanut gallery) whom I asked to swap two variable contents without using a temp variable. It's the standard a=a+b, b=a-b, a=a-b problem.
I'll admit that I don't know the whole context of the question, but the obvious shortcomings are that the desired solution works only for discrete quanties (i.e. not floating point numbers), and that the technique won't work for integers in languages with fixed numeric sizes (you could use XOR in that case), and... oh, yeah: the idea that you would have a need to actually do this in VBA. I mean, seriously: this is the kind of optimization that I used to be concerned about when I was writing assembler for devices with 4K of RAM. Which brings me to the last question I always ask: do you know how to use a profiler? The point of that is to weed out the individuals who would be tempted to spend any thought at all on how to swap two variables without a temp variable.
— Gordon Weakliem at permanent link
One!
Isabella turned one year old yesterday. We made cupcakes to celebrate; I was pretty suspicious of the recipe (cupcakes don't normally contain wheat germ) but they ended up being yummy. Izzy's big sister Elaina helped her open her presents and then it was off to an early bed - both girls have colds and need their sleep.