Confessions of a Code Addict

Hello. My name is Ross, and I’m a code addict.

Code addiction is a very serious ailment, affecting one out of every hundred software developers living today. Until recently, it was thought that code addiction was simply being good at programming, but there is a darker side; the ghosts of long-dead bugs have come back to addle the brain and corrupt the spirits of the unfortunate few. Some may delude themselves into thinking that this deviant behavior is merely attention to detail, or a dedication to our craft, however the cold hard truth is that it is an affliction.

If you fear that a friend or loved one may be a code addict, please, seek help immediately.

Signs of a compulsive coder include:

  • Never admitting to having a problem, but rather constantly decomposing problems into several smaller problems.
  • Kerning Dyslexia. The inability to read fonts which are not monospace.
  • White-space obsession. Code-addicts like myself cannot read code which is considered “sloppy” by our own standards. His or her format-document key bindings will be worn smooth from overuse, and you will often find whole swaths of your code re-indented for “readability reasons”.
  • Editor envy. Questions such as “Does your editor support macros?” and “Can I change the font and color settings?” will be commonplace. Resist the urge to let them install EMACS on your computer. It is almost certainly a mistake.

Sadly, there is no known cure for code addiction. To avoid inducing a fit of nerd-rage, ensure that your variables are named correctly, and that you follow best practices. The best we poor addicts can do is echo the following string to stdout, and hope for the best.

Compiler, grant me the serenity to accept the code I cannot change,  Courage to change the lines I can, and the wisdom to know the difference. Writing one function at a time; Enjoying one cycle at a time;  Accepting bugs as the pathway to production.

Nailing the Interview

[ understand your audience ]

Disclaimer: This is taken from my personal experience interviewing candidates. I am by no means an interviewing expert, well-studied as a human lie detector, nor have I ever dedicated an ounce of time or energy into reading a book about the art of the interview. Luckily for you, neither has your interviewer. Most likely, the person sitting across from you (the candidate) is a normal human being of average intelligence who merely wants to see if you’re the type of person they could see themselves working with for an extended period of time without wanting to pull their hair out.

Note: If this is a consulting firm, then they just want to ensure that they can use you to extract the maximum amount of dollars from clients without them growing suspicious. Your actual personality probably doesn’t matter at all.

[ don’t panic ]
That’s easy, right? Don’t sweat profusely and make the interviewer feel weird you big dummy. Just plug your glands and remember to smile, but not too much… oh god, what do you do with your hands? Are you talking too fast? Too slow? This is how humans stand right? I think so.

Seriously, just relax. It’s already a really tense situation for everyone. Just be cool, okay? The interviewer will sense your anxiety, and will respond to it by asking you really easy questions. This might seem good, but really it’s like letting a kid win at basketball to make him feel better about being adopted. You want to prove that you are a smart, confident individual, and looking nervous until you get a few pity questions lobbed your way isn’t going to do anything to help your case.

[ know the bare minimum ]
If I ask you about design patterns, and all you can talk about is Singleton, the interview is fucking over. You should be able to explain language and technology agnostic concepts such as:

  • Basic Control Flow
  • Object Oriented Design Patterns
  • Data-Structures
  • Static vs. Dynamic Typing

There is a lot to know in the world of computer science, and often there is so much that we tend to forget the core topics. Know the basics inside and out so that you and the interviewer are speaking the same language. This is not to be confused with buzz-wording. These are not merely words you say and the interviewer quietly nods approvingly. You’ll be expected to know enough about any of these to talk about them in detail. If you don’t, I suggest you read up on them now and save yourself from getting in to trouble with the next piece of advice.

[ don’t bullshit me ]
There is nothing more repugnant than an interviewee who tries to bluff. It oozes out of them like a lanced boil:

“Oh yeah, polymorphism. It’s been a while, but I can do it. I just don’t remember the specifics. I would just google it. <sheepish grin>”

What was your plan here? Did you think I didn’t know enough about the topic I just asked about to call you on your obvious bullshit? Just own up about your lack of knowledge. The risk of outing yourself as an obvious charlatan far outweighs the minor inconvenience of admitting “I don’t know”. There are plenty of things I don’t know, and when people ask me about them, I try to be honest. Not knowing something doesn’t make you seem incompetent, but being a phony makes you seem like a dickhead who is wasting my time. In my head, the interview is over. I might explain how wrong you are, but there is no real way of clawing your way back from this position, so please, remember what your mommy told you: honesty is the best policy.

[  be smart, or have a plan to get smarter (or both).  ]
If you can’t impress me with your technical prowess today, at least show me some passion and have a plan to improve your skills tomorrow. If you are a “senior” developer and you haven’t learned anything in a while, you may want to reconsider this choice and pick up a book. “Good” in this industry is a moving target. If you are not improving, you are in fact regressing relative to the rest of the industry. Find some useful resources, and have them at the ready. Exclaim proudly: “No! I don’t know what a closure is, but I’m doing some courses on Javascript in my spare time, and I’ll be sure to pay attention when that bit comes up!”

[  be memorable ]
I see a lot of people, and they are all pretty generic. We all tend to do the same sorts of things in our day-to-day, e.g. making the button say this instead of that, or when the user clicks the thing, do some other thing. It’s boring, and repetitive, and not at all entertaining to hear re-told. Talk to me about something awesome you built, or about that time you brought down production, or the hard-to-find bug that saved your coworker hours and sent him into a fit of face-palming. I probably won’t ask, so just blurt it out. The less likely it is to come up in conversation, the better.

[ show me the code ]

Get yourself a github account and put up something, a pet project, an experiment, a few Project Euler solutions. Something with your name on it that is indicative of your coding style. This is equivalent to your artists’ portfolio, and there is really no reason not to have it available.

[ accept defeat gracefully ]
Sometimes, despite your best efforts, things will not go well. There are lots of reasons for this, but generally, it will mean that you are not the candidate the interviewer was looking for, and you know it. Resist the urge to ask “how did I do?”, it just feels desperate. Instead, ask the interviewer if there were specific areas where you are weak. If he or she has lots to tell you, just accept your fate, and try to turn the experience into something positive. Smile, take notes, and learn the things they mention. Your next interview will be better.

Tune in, well, let’s face it, whenever the hell I decide to get off my ass and post something, for an F-bomb filled tirade about passion.

-smugly yours, Ross