The Coding Monkey

Is Interviewing Worthwhile?

nick@thecodingmonkey.net (Nick) — Wed, 23 Apr 2008 16:12:20 GMT

As part of my consulting work, I do technical interviews, both for my consulting company, and sometimes for clients as well. This is fairly new to me, but I've jumped in with both feet and like everything I do with my job, I've tried to read up as much as I can in order to get as much good information and do the best job possible. I take interviews very seriously, and have always seen them as an important step in the hiring process. That's why I found this particular tidbit from a recent Megan McArdle post to be quite troubling:

There's a rich body of literature suggesting that job interviews are actually counterproductive. You are much better off hiring people (or not) based on their resume and/or body of work. Interviewing actually reduces your chances of hiring a satisfactory candidate.

This hit me hard to be honest. Has what I've been doing for the last several months to vet candidates been a waste? My gut reaction is of course to say no, but I think she brings up an important point, which I've read many places. Most people who interview don't do a great job at it, because they let the interviewee do most of the talking. If you let the person being interviewed do most of the talking, of course you won't find out anything. They've practiced their schpeel over and over again, and have it down pat, or at least they should. As a result you might hire somebody who is all fluff and no substance. Worse yet, you can miss out on a great person who has deep knowledge, but is very nervous and not a good speaker, or is introverted, and therefore doesn't know how to sell themselves.

One of the posts from Coding Horror that I found to be incredibly useful was this one on getting a phone screen right. The gist of the post is that you, the interviewer, should drive the interview. The interview should be technical, and very specific. Ask them to define common terminology, describe a sample architecture for some made up problem, or how they would approach solving a problem. Interrupt the candidate often with questions regarding how they did something specifically, or why they chose one method over another.

The problem for technical people is that we usually don't have a portfolio we can share! When a programmer leaves a job, they generally can't bring the source code they wrote with them and show it to a perspective employer as a sample of their work. Megan has the advantage of working in a field where she can do just that. She can take articles she's written for other publications and show them to someone else as an example of the quality of her work. In the technical world, the resume can be pretty useless. They may accurately describe projects that they've been part of, but may exaggerate their part in creating that project. And just because you helped write a piece of software that is in production today... was it written well, with good architectural and object oriented design techniques and is it maintainable? Or was it certified as "Works on My Machine"?

In our profession, its also easy to get roped into the "years of experience myth". Technology changes so quickly that a great portfolio of projects in one technology doesn't show whether or not you can, or are willing to, learn the next great technology that your company wants to employ. In fact, I've often found that the best candidates in highly technical positions are the youngest candidates, because they still remember how to learn, and are passionate about it. The older people get, the more settled into their ways they become, and the more likely they are to pigeon hole themselves into static methodologies. That's why I always ask people what blogs they read, magazines they subscribe to, and what, if any, user's groups they are active in. That is a huge indicator as to how passionate about learning technology someone is. One of the best people I've seen hired recently was in his 50's. Software development for him was a second career, and he took it up with a fierce passion. So you shouldn't simply look at age either.

In short, if you don't think that interviewing is worthwhile, then it probably means that you're simply running down a person's resume, and letting them talk about where they've worked. That is not how to do an interview.

Follow Me on Twitter

© Copyright 2010 Nick Schweitzer. This feed is for personal non-commercial use only. All other uses are strictly prohibited without express permission from the author.

A Scary Realization

nick@thecodingmonkey.net (Nick) — Tue, 30 Oct 2007 21:36:48 GMT

I've gone from being Peter Gibbons, to being Bob Slydell.

God help me.

Follow Me on Twitter

© Copyright 2010 Nick Schweitzer. This feed is for personal non-commercial use only. All other uses are strictly prohibited without express permission from the author.

How Is Agile Methodology Like Cholesterol?

nick@thecodingmonkey.net (Nick) — Thu, 28 Sep 2006 13:34:03 GMT

To be honest, I'm still not quite sure exactly what "Agile Methodology" is. I've read several books on the subject, and there are plenty of companies out there that like to think they use parts of it in their development process. I say "parts" because they really just cherry pick the things that they thought they could sell to management without changing too much of their current process, yet still sound like they're on the cutting edge. There are so many different versions of "Agile Methodology" out there, it's enough to make your head spin. That's why this blog post is so damn funny:

Yeah. Well, they make money hand over fist, because of P.T. Barnum's Law, just like Scientology does. Can't really fault 'em. Some people are just dying to be parted with their cash. And their dignity.

The rest of us have all known that Agile Methodologies are stupid, by application of any of the following well-known laws of marketing:

- anything that calls itself a "Methodology" is stupid, on general principle.
- anything that requires "evangelists" and offers seminars, exists solely for the purpose of making money.
- anything that never mentions any competition or alternatives is dubiously self-serving.
- anything that does diagrams with hand-wavy math is stupid, on general principle.

And by "stupid", I mean it's "incredibly brilliant marketing targeted at stupid people."

Not only is Agile like cholesterol, it's also like Scientology and your local circus. It's probably the most sensible look at Agile that I've read so far. Via Joel on Software.

Update: And here is the response, from Coding Horror:

Rather than wasting time and effort on discriminating between "good" and "bad" Agile, we should be banding together in the name of Anything But Waterfall. The fact that some maladjusted developer or project manager could use Steve's well-written, reasonable sounding rant as a justification to keep their project in the dark ages of Waterfall and BDUF absolutely kills me. Who is the real enemy here?

Read the whole thing.

Follow Me on Twitter

© Copyright 2010 Nick Schweitzer. This feed is for personal non-commercial use only. All other uses are strictly prohibited without express permission from the author.

Personable Doesn't Equate to Good

nick@thecodingmonkey.net (Nick) — Tue, 15 Aug 2006 16:53:38 GMT

This applies to more than just computer geeks. You see this in any specialized profession, especially ones that require great technical prowess or accomplishment. That's right, even doctors and lawyers can be like this. In some cases it's being known as a team player, or just personable, or having good bedside manner. Often times, this is how people unfamiliar with your profession measure your ability. If you have good bedside manner, then you must be a skilled surgeon. If you can relate well to a client, then you must be able to write wonderful briefs. If you're not a cubicle recluse, you write great code. Of course this is entirely false. In fact, often times it's the exact opposite. People who are the most introverted are often times the most skilled at their profession. But because they come off as shy, or maybe even rude, it's assumed they must not be good at what they do.

In my experience, some of the most clever, most skilled programmers have been very introverted, and very reclusive. They're the type of person who sits in their cube, and won't interact with you unless they have to. But the code which they produce is very high quality, and they have a very deep knowledge of software. Having spent part of my career hanging out in hospitals, I don't know how many times I've heard from nurses about about a doctor with terrible bedside manner, who was the best surgeon they knew of. Often times I think serious professionals tend to sacrifice the development of their interpersonal skills in order to concentrate on the technical aspect of their job.

I write this for two reasons. First, it's important to recognize this about yourself if you know you are this type of professional. People will judge you, fair or not, based on your ability to communicate well with others, even if it is not the most important part of your job. Of course, the ability to work well with others, and communicate effectively with patients or clients ought to be a highly desirable skill anyway, and so if you should recognize that it is a reflection on you, and try to improve.

I also write this to make others aware of this. Don't judge someone purely based on their interpersonal skills. While it may be important, it's often times not the most important skill to have for a position, and you may be passing up on someone who would do an incredible job for you. Moreover, someone who can talk a good game my not have the chops when it comes down to actually doing the job you hired them to do. Don't use one as your only measuring stick for the other.

The Development Process Explained

nick@thecodingmonkey.net (Nick) — Tue, 01 Aug 2006 15:44:42 GMT

One of my coworkers forwarded me this link, which has a great pictorial analysis of how the software development process works. It's priceless... and something to always keep in mind when you start a long running project.

Actually... You Didn't

nick@thecodingmonkey.net (Nick) — Fri, 14 Jul 2006 14:18:08 GMT

I review a lot of code during the day. Some people's code I review after they check-in to source code control, while one person in particular has to show me their changes before they're even allowed to check-in. Whenever she comes to me with her code changes, she always says "I fixed the bug"... and after looking at her code I always have to respond, "Actually, you didn't." This is quickly followed by, "Yes I did... that thing doesn't happen any more." And while that's always true... her solution was to simply comment out the offending code, instead of fixing the offending code, which results in a new bug to replace the one she supposedly fixed.

It's as if the function she commented out was called InsertDefectWithoutDoingAnyRealWork(), when in reality it's called DoSomethingAlmostRightThatStillHasToBeDone(). And then after I tell how her that her solution will cause functioning code to not function any more, and that she needs to go back and really fix the bug... as she leaves, she always says, "OK, but this did work."

No it didn't! Fixing a defect by causing 5 more is not fixing a defect at all! Fixing a defect by commenting out code is not fixing a defect! Every line of code was written for a reason. It may not do exactly what was intended, but there was a purpose to it's being there. So before you simply comment something out, you need to understand that purpose in order to make sure that by the time you're done, that functionality is either deemed to truly not be needed, or has been fixed.

That is when a defect is fixed.