Tales from the Interview

I enjoy reading about interviews. Especially the bad ones.  Luckily The Daily WTF keeps me stocked with stories that would chill your bones:



A Doomed Interview (from John) 
Times have been tough, so I’ve been looking just about evernwhere for work. Buried in the last page of the local newspaper, I found a tiny job ad seeking a candidate with several technologies I had experience with. Against my better judgment, I called the number and, after a few minutes of small talk, was invited to an interview. Not the next day, not the next week, but right then and there. Within hours, I found myself on a backwater industrial parkway, standing in front of a non-descript building.

Stepping through the front door was like entering a DooM level: dark as hell, a creepy bad atmosphere, and a slight fear that a giant spider was lurking around the corner. As my eyes adjusted to the gloom, it took all of three seconds to realize that I didn’t want to work there. Against my better judgment, I headed in and up a dimly lit staircase.


The office was decrepit, devoid of people, and looked like a dingy basement with clutter, files, and junk strewn everywhere.What kind of a person would work here, I asked myself. Against my better judgment, I tapped on the door and called out “Hello?”. 

You’ll just have to visit The Daily WTF to see how it ends, for my part; I’ve only had one really weird interviewing experience:

The year was 2007, the bubble was bursting but no one in the banking industry realized it yet; especially not the two floor trading specialists that needed a software developer who could troubleshoot application problems on the ‘trading floor’. I sent in my resume and was called for an interview.  At the time Wachovia was building a skyscraper in Charlotte; it was the topic of conversation by every recruiter or interviewer I talked to that day.  Except for one fateful conversation.

Two of the members of the application development team started taking me through the interview process, and let me know that they were going to stress me out while requiring me to solve brain teasers on a whiteboard. Somewhat confused, I replied, “You know I was in the Army, right?”  I guess that didn’t meet their definition of stress. They continued to ask me rather hurried questions about various programming ideas while wondering why I hadn’t solved their problem about the snail going up the well wall. 

Fast forward six months, and their division was cut (due to the recession), and my job would have undergone a cut as well. Their skyscraper is now owned by Duke, and they were bought out by Wells Fargo. I went on to a contract as a Web Application Developer using Perl.


The Ties that Bind

Same Shiny Boots

In the Army, I spent hours shining my boots. On days where I wore my dress uniform (very few), every part of my uniform looked amazing. If I didn’t have the time to shine my boots, I took them to a retired Sergeant Major that made a living shining other peoples’ boots.

My obsessive behavior over my uniform is the only thing that differentiated me from other soldiers.  We were all the same; same haircut, same uniform, same shiny boots. 

Many soldiers complained about shining boots or having to prepare their uniforms, but we all understood the reason behind it. If you didn’t have the discipline in your daily life, you wouldn’t have that discipline when other people depended on you in combat.

Behold, the Tie

When I left the Army, I worked at a variety of places; some with a flip-flop and T-shirt dress code, and others that required ‘Business Casual’. None of them ever broached the line that required developers to wear a tie.

Ties are a long standing symbol of professionalism in the civilian world. If you are wearing ‘Business Professional’ attire, people take you more seriously and think you know what you’re doing (newsflash: All of Wall street wears ties).  They’re more likely to trust you, and if you’re especially smart about your attire, it can be the difference in choosing who to promote. There’s even an unwritten rule: Dress for the position you want, not the one you have. 

None of which applies to software development.

Shaken, not Stirred

It’s because software development is 1 part common sense, 1 part counter-culture, and 1 part fledgling industry. 

If you aren’t interacting with a client, wearing a Tie doesn’t make sense. It is doubly so when your job depends so much on getting into a mental groove; a groove that’s much harder to attain if you’re constantly thinking about the lack of blood flow to your brain.  There’s also the time aspect. If I’m spending an hour a night worrying about my attire for the next day (I’m colorblind, give me a break), then that’s an hour I’m not spending researching Windows Communication Foundation, playing with Ruby, or helping out on Stack Overflow. All of these make me more valuable to my employer. Wearing a tie does not. 

There’s also the talent cost. If you have a great developer that can choose his company, all else being equal, he will choose the company without the tie. 

Third, our industry is young, and its roots are predicated on rebellion against the status-quo

Tie it up

If you don’t have face-to-face time with a customer, you shouldn’t be scruffy looking, but a tie isn’t necessary either. If you’re a business owner, your programmers will be more productive, happier, and more likely to stay around if you relax your dress code.  Think about it, it’s cheaper than a raise.

Think Before You Measure

I like Target. That probably has as much to do with a lack of alternatives as it does their appeal. Normally I’d go to Wal-mart. However, there are no Wal-mart stores in Northern Virginia. I think there’s one, but it’s rather sketchy. Coming from the south where Walmart is a local hangout, it’s strange not to see one for miles. Not that I’d ever ‘hang out’ in one. But it happens, or so I’m told.

It is, as they say, what it is. I’m not really sure *what* it is though.

Back to the matter at hand.

Target uses a system of measurement to ensure that the cashier is speedily checking customers through the line.  This measuring device uses one criteria to measure a cashier’s worth: How long it takes them to check a person out. From red-bar-of-doom to red-bar-of-doom.  there are two options “R” (for “Red” i guess), and “G” (which probably means “Green”, which is a good thing. I think.) it looks like this:


What this says is that the employee has received ‘88%’ green scores for his shift, and in the past ten transactions, has had two ‘R’ (Red, or “Bad”) transactions. 

It says nothing about the accuracy of his work.

My fiancee and I were shopping at Target one evening and a cashier inadvertently gave us an item without ringing it up. It could have been because I was chatting with the cashier or it could have been because he was tired and just ready to go home and spend an hour figuring out Lost. Who knows. 

What good did Target’s (probably expensive) measuring system do them? None.

That’s the problem with measuring in general.  If you measure something, you incentivise it. Target measured the speed at which customers are checked out. That causes the cashiers to pay attention to how quickly it takes them to check customers out, which means they go faster. Pretty soon Target is starting to miss a non-trivial amount of merchandise that is neither caused by internal loss or by shoplifting. 

You’re reading this post right now, and at least one of you is saying, “That’s great, but I can’t change that. I’m just a programmer.” Bull. You aren’t just a programmer, you create substance out of thin air.

 Business people know business — but they don’t have a monopoly on common sense. We deal with common sense every minute of the day (or lack thereof, depending upon our neighbor’s code).  That’s part of our value as programmers. Without that, we’re just glorified code monkeys.


The Perils of Football Pads

I’ve always wondered why rugby players seem to get injured less than Football players. It doesn’t make sense to me. Football players have pads, Rugby players do not. One is protected, the other is not. One gets injured, the other does not. QED. 

So why in the name of Chuck Norris do Football players have more frequent and more extreme injuries than Rugby players?

The answer is in the pads:

[UMKC physics professor Robbert] Riggs believes there would be fewer serious injuries if players didn’t wear pads or helmets.

“As a retired Marine officer,” Riggs said, “I know that when you’re wearing body armor, sometimes you feel invincible and I think there’s some of that. They put on all those pads and they feel invincible.” (emphasis mine)

Sound familiar? (warning, PDF)

The developer does not need to explicitly free memory assigned to an object, which goes a long way toward reducing the amount of time spent debugging memory leaks. (10) There can be no memory leaks in 100% managed code.

Not only is this statement downright false, it’s also dangerous.  

Google currently has 103,000 hits for “Memory Leak C#”, and they all contain a similar tale of woe, programmers telling other programmers how not to make the same mistake they did. Each example boils down to one of three things:

1. Not de-referencing an event handler:

MyType object2 = new MyType();

// …
object1.SomeEvent += object2.myEventHandler;
// …

// Should call this
// object1.SomeEvent -= object2.myEventHandler;


My most recent encounter with a memory leak was much like this: There was a class that dealt with dynamically wiring up events for other objects (as if they couldn’t do it themselves?) and although these references went out of scope, the event handlers were still hanging around, subscribing to references that were now gone. Anything that was being used as a reference couldn’t be garbage-collected, resulting in hundreds of megabytes of memory being retained over the course of an application’s life.

2. Creating global references to objects:

I don’t care what Greenpeace tells you: Think locally, not globally. Objects that don’t have external references are much easier to keep track of than those that do. 

3. Disposing of Forms

If you’re a Winforms or Webforms developer, this one is for you. ASP.NET MVC guys get a pass because they wised up. If you’re using something that isn’t yours, Dispose of it. Period. Database Handles, Filehandles, Controls, Forms, Whatever. Dispose of it. 

Bad decisions have a half-life that rivals uranium. Don’t make bad decisions: Know your code.

On The Subject Of Chewy Cookies

From Roboppy's Flickr Photo Stream

I love cookies. I especially love Chocolate chip cookies. Chewy ones. You know how hard it is to get people who are used to crunchy cookies to make you chewy ones? It’s a religious war. Crunchy cookies are easy. You put them in the oven, you wait for the allotted time, make sure they look brown and take them out.

Chewy cookies? Those are a little tougher. You have to put the cookies in, make sure they stay in just long enough to be cooked, but not long enough to be hard, and you have to take them out at the exact right moment.  This is not something you do distracted.

Building a blog engine is quite a bit like that.  It’s easy to follow the directions everyone else has followed, it’s easier to use the platform everyone else has used, but it just isn’t as good.

Here are some blog engines that out there, by platform:

Name Platform
WordPress PHP
Subtext ASP.NET
Slash Perl
Blog Engine.NET ASP.NET
dasBlog ASP.NET

Notice that none of the ASP.NET blog engines are written in ASP.NET MVC. Phil Haack (the PM for ASP.NET MVC) is currently working on porting subText to MVC, but he’s the only one.

There is nothing wrong with these blog engines — they’re all good blog engines. But they do too much. I’m writing this in Blog Engine.NET, but I find myself constantly working against my editor to get anything done. I’ve talked about this before.  If you split the world into Microsoft stack blogs and everyone else, the Microsoft stack looks pretty bad. ASP.NET (forgive me) is not exactly ‘web 2.0’. Have you seen the junk it produces behind the scenes?

  <input type=”hiddenname=”__VIEWSTATEid=”__VIEWSTATEvalue=”/wEPDwUJMjg0ODM3NzE0ZGSoESYSPiXqs94xPK36e2sP1eds+w==” />

And that’s just one line. It gets worse.  .NET developers have to either choose ASP.NET or PHP. Crunchy cookies or Macadamia Nut Cookies? Chewy Chocolate chip? Not an option.

It’s time to make some chewy chocolate chip cookies.