Monday, July 13, 2009

Muddled Thinkers Need Not Apply

Lately, I've been doing a fair amount of interviewing (as an interviewer, not a candidate) and have a few thoughts on passing my interview. Yes, that's right, I'm going to give you some advice that just might get you hired by my company.* Here's the best piece of advice I can give you. When asked a question, compose yourself and think clearly about the question before answering. The number one reason I ding people in interviews is because I perceive them to be muddled thinkers.

Muddled thinkers confuse customers when they give unclear answers to tech support questions. Muddled thinkers write muddled code, with comments that are equally incomprehensible. And muddled thinkers have a hard time learning new things, because they don't have a structure or system for applying that new knowledge. This leads to something my friend Duncan calls "programming by accident". Keep randomly permuting the code until it seems to work and then stop. This approach creates bugs and unmaintainable code. If it's your strategy for solving problems, I don't want you on my team.

A specific muddled thinking antipattern we see a lot involves the naming of temporary variables. If I ask you to write code and you need a temporary variable to solve the problem, stop and think clearly about the purpose of that variable. If you name the variable t in an attempt to finish as quickly as possible, you are well on the way to failing your interview. I won't fail you just because you chose a poor variable name, but I will fail you because your failure to choose a good variable name confused you to the point that your solution was incomplete, didn't solve the problem, or you begin randomly permuting your code in hopes that "if I just change this to that, it should work." That smells too much like programming by accident.

Think you have what it takes? Want to work at a growing (yup, even in these economic circumstances) startup? Want to work on a product that makes a difference in other programmers' lives? Smart Bear is hiring software developers and senior QA engineers. Send us a resumé. jobs@smartbear.com.

* Remember when you're in an interview, the interviewer wants you to succeed just as much as you do. We don't do interviews for fun; we do interviews so we can get more people to help with our real work. Ironically, the backlog of real work gets longer the more interviews we do.

2 comments:

  1. I wonder if TDD encourages programming by accident.

    That's typically how it's described: You set up some tests, write code to pass JUST those tests, then you're ready for the next pass. If your increment of change is small enough, you can use your "permute until pass method" for quite a while.

    If you're lucky, you're done. If you're unlucky you code yourself into a corner and end up slapping back and forth between failing one test or failing another because you're really not CLEAR on how this code should work.

    Or maybe you leave it and the next person ends up discovering there's a bug and then can't fix it without rewriting the routine because you didn't think about the problem throughly enough?

    There are good aspects to TDD though -- don't want to throw the baby out with bathwater! For example, one problem with "code, then test" is that you don't REALLY know if the tests are testing something real.

    But to the extent that they allow for "programming by accident," maybe it's a bad thing?

    (Although I'd rather have twisted, crappy code with some tests than no tests at all...)

    ReplyDelete
  2. Funny, I just discovered this comment (Yeah, I haven't been very good at blogging), and in fact, have had a draft companion post about TDD and muddled thinking in my queue since I published this post. I 100% agree that TDD is used in this way by muddled thinkers.

    If you're doing TDD and you find yourself in a continuous regression loop, it's a good sign you need to stop and think about the big picture for a moment.

    ReplyDelete