A while ago my boss and I had a discussion about how to interview candidates for a programming job. Not being a programmer himself, the boss wanted me to supply some good questions that would show depth of programming knowledge, especially Ruby on Rails, which is what our site (http://trailmeme.com – tried it yet?) is built in. I think he was a bit surprised that I had very little interest in asking those kinds of questions. Once I explained myself, he was willing to trust my judgment (which is a nice thing to have in a boss). But he isn’t the first person to find my approach to interviewing candidates to be different from the norm. This tells me that the rest of the world is doing it wrong and there is need for me to explain some basic principles for the benefit of all those less enlightened than myself (for those who are humor impaired, just ignore the completely insincere self-aggrandizement in the previous sentence and move on).

I remember being interviewed for a position once where the interviewer asked questions straight out of What Color is Your Whatever that Silly Book Was? One of the questions was, “What would you say is your greatest weakness?” I decided this would be a bad time to mention my disrespect for people who ask questions like that. Instead, I made up a line about not thinking in terms of weakness, instead playing to my strengths. He liked that answer but didn’t hire me anyway. Maybe he thought I was trying to hide a deep disrespect for authority. More likely he found someone he could get for less money.

Anyway, this is lesson one: Don’t ask questions that encourage people to be less than completely forthcoming or honest. Sometimes that may be hard to avoid. “Why is there a 2 year gap in your education?” If the answer is, “I was on trial for murdering a professor but got off because he deserved it,” it is very unlikely the interviewee will actually explain this. On the other hand, who cares about a gap in education, or even in employment? You can read a lot of programming stuff while waiting for the jury to bring back a verdict.

So what kinds of questions do I think are worth asking? I always ask programmers about the tools they use. What kind of IDE (for those readers who are not programmers, that’s a sort of programmer’s word processor), what version control. what favorite testing framework? I ask these things because a really great programmer doesn’t like to do extra work and good tools save work.

More importantly, I ask these questions because in ANY field, someone who has done it for a while and faced many different problems and types of conditions will develop opinions. A car mechanic might develop a preference for Chevys over Fords because the failure rate of some part, and the difficulty of replacing it, is unacceptable. Someone involved in developing commercial real estate might prefer working with a particular contractor over another because of the quality and timeliness of the work. The preferred contractor might prefer a particular building material over another for longevity or ease of installation or even for some completely irrational reason, like having once used that material on the same day the Yankees lost the series (it happens, trust me).

When you work with stuff, you naturally develop opinions about it. This may seem like a radical idea but I’ve found it to be very dependable. Humans are good at having opinions. In fact, people often have opinions without working with stuff. You can usually figure out who those are when you ask them why they hold an opinion. Someone who has worked with a language or an IDE or some software, will tell you horror stories about what they went through with other languages or packages. That is, they’ll describe their experience. Someone without experience will rarely be that specific, or that passionate. Worse, they might try to be fair and thoughtful.

I have a stock question that goes something like this: “Suppose I assigned you to develop a social networking type website. You own the project. You have complete control over the tools you use. Programming language. Operating system. Version control. Data structures. Everything. tell me a little about the things you’ll choose and why you choose them.”

My theory is that, even if the person makes choices I would not, if they have reasons for those choices, I can respect their opinion. So far, this theory has not been proved. I have heard some pretty bad answers to the question. The worst one is the one where they try to seem professional and thoughtful. “I would choose whatever tools were appropriate for the client’s needs.” To me, this is another way of saying, “I have no idea and I’ll be damned if I’m going to commit myself to anything that you could maybe use against me.” This person will probably never be a good programmer. Programmers make decisions every day. Choosing to use some form of internal caching over a database is a decision that has far reaching consequences. if you don’t have the courage to make the decision, you’re going to hold up development while you try to get someone else to take time away from their own job to decide for you. [Note: I'm not claiming this is a perfect example of the idea. It's just an illustration]. Consultation is fine but you should have a preference and be able to express it or what good are you?

My questions seem to be better at getting bad answers than good ones but I find the bad answers very illuminating. If I ask what kind of IDE someone prefers and the answer is, “What’s an IDE?” That tells me I’m not dealing with a professional programmer. NEXT!

Try the alternative. If I ask, “How would you solve the n+1 query problem in Ruby on Rails?” It sounds like a good, solid, technical question. The trouble is that it can be answered after spending about 2 seconds with Google. (The answer is eager loading … usually. But it’s a job interview. If you give me a 20 minute answer going over all possible special cases I may worry that you’ve given it too much thought and really need a hobby). It’s also in all the books about Rails. It doesn’t tell me much about your skill level. (Though, again, someone who answers, “What’s that?” Has just flunked computer science 101 and might not get a lot more of my attention)

On the other hand, if I ask, “What do you use for version control” and the answer is, “At my last job we used SourceSafe” that tells me that you haven’t given a lot of thought to the question of version control but at least you know what it is. If, on the other hand, the answer is, “At my last job they used SourceSafe but I hate the locking model. For my own projects I use Git because there’s no problem with locks and branching and merging are almost effortless. Plus I can use it on the road when network connections are spotty” – this tells me that I’m talking to someone who has given actual thought to productivity. (Okay, actually you can get this answer from 5 minutes with Google. But you have to want to).

I guess the bottom line is that when I ask a question of a job candidate, I don’t want answers from a textbook. I’ve been interviewed myself when this was avoided by asking for a specific example of something I did on the job. I’ve usually been able to come up with answers. It’s not always easy. In  an interview situation where people may be nervous and even exhausted (ever been the 12th person to interview somebody who has been doing serial interviews all day long? Don’t expect coherent answers) that may be asking a bit much.

It’s also possible that I just like to torture people with unexpected questions. But they’re questions a pro should be able not just to answer but argue about. Arguing for your ideas is one of the basic skills needed for good teamwork. Hey! I never thought of that angle before. Maybe I’m on to something more interesting than torturing candidates after all.

I learned an interesting lesson at my job today.

Our team recently gained a member who is trained in user experience stuff, actual testing and measuring it, not just eyeballing it like me. During a couple meetings lately, we’ve discussed the language used on the web site. We’ve changed the terminology a couple times during the course of development as we thought of new implications and also as we struggled to describe the technology in ways that people who are new to it can understand. When you’ve been working on a project for a couple years, learning how to talk about it to people who are brand new to it can be a challenge.

What do you mean you don’t understand what a child node is? It’s a node directly linked by a default or alternate path from a parent! (Note: Never end this type of sentence with words like “dummy,” “idiot,” “moron” or anything similar. For some reason it doesn’t go over well.) (See here for a partial explanation of child node)

One result of the changes in terminology is that the web site is inconsistent. Sometimes it uses one term, sometimes an older one that is no longer approved. This might be because we forgot to change it or it might be because someone was writing stuff and forgot that we had changed the term. An attentive reader might be thinking, “Ah! So you learned you should thoroughly edit everything when you make changes, maybe even have copy written by a professional who will be focused on the words and not think of them as a distraction from the real job of hacking code!” This would be wrong. Nice try though.

We figured out how to get to a better system, starting with having our new usability expert compile an approved dictionary for the web site and all the training materials. She’s not a technical person like the rest of us (mostly programmers. The boss is not a programmer, but he has a PhD in aeronautical engineering. He understands what a child node is) so she’s a good choice to repair some of the damage us tech geeks have done to the message.

No, that’s not the lesson either. It is VERY common for business development experts and all-wise columnists to explain that it is incredibly important for technical people to be able to “speak to non-technical business managers” or something like that. The conventional wisdom is that geeks only speak geek and if you can find one who can talk to regular people, you’ve struck gold. When I read this argument, I usually see Dilbert’s boss (in my head. I have not starting having such horrifying hallucinations yet) yelling, “Stop talking to me as if I have a brain! Use smaller words even if they don’t mean anything!”

Note to Scott Adams: I don’t remember if you’ve written the particular exchange just described or not. There was a time when, if I laughed at it, I would have been sad at the same time because it was so close to my real life job. Now that I work for a genuine rocket scientist (see above), would you consider having another boss who actually tops Dilbert’s big words with even bigger and more incomprehensible ones (while still technically accurate) until one of their heads explodes? Just a thought.

Where was I? Oh yes! Today’s lesson was not about the difficulty of finding technical people who can communicate with the non-technical. That problem will go away by itself when the day comes that the non-technical can drink a potion or take a shot and finally learn some minimal amount of real math (a minimal amount being about how much I know. Real math knowledge would be more like what my boss knows).

There was a real lesson that came out of the language discussion, though. It was that, as we discussed terms that users of our web site should not be exposed to (such as “node”) I realized that we could not simply banish those words from out vocabulary because we still needed them. “Node” has a meaning. The day one of my colleagues on the project first declared “everything is a node” it was a breakthrough that made several developments since possible. Even easy. “Everything is a unit abstracting all types of structural elements” or “everything is one of those web page type thingies and other stuff that we work with” would not have had the same value.

Sometimes we look at technical language as being like a secret handshake; it’s just something the in crowd uses to distinguish themselves from the rest of the world. When doctor’s say “myocardial infarction” or when computer science students say, “It’s not a hacker. Hacker is an honorable term for someone who likes to fix broken code in creative and efficient ways. The correct term for someone who invades networked systems is cracker” it seems more like melodrama than technical accuracy.

But there still needs to be technical accuracy somewhere, doesn’t it? We figured out today that it isn’t just us. We have plans to open up at least some portion of our code to outside developers. Part of the project is already out there as open source for anyone who wants to get work with it. That was the lesson, or at least part of it. After we have a complete dictionary for how to communicate our ideas to end users, we will probably need another one for when we’re communicating to other technical people. Those outside developers need to understand that everything is a node. (For some reason that phrase always reminds me of the song “Everything is Food” from the Popeye movie that starred Robin Williams in possibly his last really funny role. Maybe it’s just me.)

Our lesson today was something along the lines of how technical accuracy has to be preserved, even though it doesn’t help us communicate with end users. We also talked about creating a mapping of one set of terms to the other (a geek to English dictionary, more or less). A way to communicate with the people who aren’t inside without losing the information we need. It’s surprisingly hard. I’ve never heard of a project having that sort of translation layer before, though it seems obvious once you think of it.

But how many centuries have doctors been doing without anything like that either? If I knew some medical terminology, I’ll bet I could make some money selling a dictionary like that.

• Myocardial: heart thing.
• Infarction: ouchie.

Note: If you’re wondering what I do on my job that inspired this brilliant post, click the “trails” tab at the top of this page, or go to trailmeme.com. There’s some cool web tech here.

In my current employment I’m a website programmer. And a technology researcher and system administrator and probably a couple other things. But that’s not important right now. It’s the programming stuff that matters tonight. I have a big deadline coming up in a couple days and I’ve been putting in some extra hours and I’ve had something of an epiphany. It’s probably nothing new to other programmers but it is to me.

We need more comment labels.

It’s like this: Programmer’s make notes in the code we write. They’re called comments. There are certain commonly accepted prefixes that can start a comment – so commonly accepted that certain IDEs (for people who don’t know what that means, think of it as a window you type programs into) recognize them. Some IDEs will apply special highlighting to the labels so they are easy to see. This makes it simple to look at a file and find places where improvements need to be made.

The most common of these labels are TODO and FIXME. Here’s an example from one of my current projects:

#TODO: Move this function to the observer

For the record, I use TODO  a lot more often than FIXME. It would be nice to never use FIXME but sometimes there are other considerations than making every piece of code perfect. Like lunch. Or the demo that’s coming up in 15 minutes and the code had better be working (even if it’s not very pretty).

One of the things I like about web developing with Ruby on Rails is that it comes with rake tasks that will go through the code and show you all of those notes. It recognizes the two I mentioned above, plus optimize (which I should use but I keep putting that stuff in as TODO. Bad habit) and even has an ability to look for custom ones.

That’s wonderful but not portable enough. The whole world recognizes TODO and FIXME. (At least, the whole English speaking world of programmers who read the same kind of reference materials I do). Custom tags, by definition, will be mostly only recognized by the individual or team that uses them. Especially for very large or distributed projects (like a lot of open source stuff), it would be better for the world to agree on an expanded vocabulary of meaningful tags.

I would humbly (or not) propose a few for consideration by the programming community.

• SEC or SECURITY — meaning, there’s a hole here and if don’t fill it, you’ll have no one else but yourself to blame when you get hacked.
• REMEMBER — Use this for reasons why things are done in a particular way. Like REMEMBER: The user’s are only allowed to do this on alternate Tuesdays. It was trying to use this one that made me think we needed more.
• DTU (DRY This Up. Dry stands for “Don’t Repeat Yourself.” It’s a principle that makes code more efficient and easier to figure out and maintain. It can be carried too far but so can beer drinking. No, really! Trust me on this one.
• REQ or REQUIRED — As in “Don’t blame me. The boss  insisted I do it this way.”
• LEAVE — Use this for things people will be tempted to change or remove but something will break if they do.
• IDIOT — May be a comment directed at yourself or the person who wrote the code. Exclamation point optional. No further explanation is necessary.
• OHNO — Interchangeable with “I wish I hadn’t done it this way.”
• SMITW — “Shoot Me If This Works.” Counting how many times this one shows up per program (or per 1,000 lines of code) might give some interesting or even scary results. Guaranteed not to correlate in any meaningful way with bug reports.

There. That’s a good start. I hope the programmers of the world find them useful. Oh! There’s one more that should probably go at the bottom of some blog posts, as well as in many programs:

• WWT — “Written While Tired.” Not to be confused with WWD (Written While Drunk) which is assumed for anything written in Java and all college programming courses and it still isn’t a good enough excuse.

Thanks for considering my suggestions. Pass them on and have a nice evening.

WWT.