pr0g33k

I'm smart and I get things done.

I've been interviewing for a new job over the past several weeks. In the past, I've gotten jobs through contacts and word-of-mouth but now that I'm branching out to other industries, I'm finding the job search to be really tedious.

"That's the trouble with the world today. No one takes the time to do a really sinister interrogation anymore. It's a lost art."
~ James Bond, Goldeneye

Trivial Pursuits

Over the past several weeks, I've been somewhat perplexed about whether I'm being interviewed for a job or participating in an episode of "Jeopardy!". Five of the seven interviews I had last week were solely trivia tests. "What is the MVC pattern?," "What properties would you set when using jQuery to make an AJAX call?," "What is ACID in the context of databases?," and "What is the difference between a primary key and a unique constraint?" were just a few of the questions I was asked. These questions are great for a college pop quiz but do little to determine someone's experience, intelligence, or talent.

For example, at one of my first tech jobs, the CTO hired someone that could answer absolutely every technical trivia question he was asked. The guy was a machine. Without blinking - without even waiting for the interviewer to finish the question - he spat out the answer with textbook accuracy. "This candidate is amazing!," we were told. "You're really going to learn a lot from him." He was fired a few months later because of a total lack of performance on the job. He couldn't write a line of code to save his life. (After the first week, I seriously wanted to put that metaphor to the test, too.)

Interviews disguised as trivia contests give me some insight as to the type of company and employees with whom I would be working. If the interviewer doesn't want to get to know me and discover what makes me tick, then I probably don't want to work for them. I'm at least going to be wary going into the next phase of the interview process or when it comes time to accept an offer.

"Reality is merely an illusion, albeit a very persistent one."
~ Albert Einstein

I've only had one interview so far where I was asked to write some code. I was initially excited when it was explained that the test had three parts: SQL, C#, and UI (HTML5 and jQuery). I anticipated that I would be given a business problem to solve and that I would be designing a simple database schema, writing some data-retrieval code and some business logic, and displaying the data in a Web application. These are simple tasks that I perform every day and would be a great way to show how I organize projects and solve common problems.

If only...

For the SQL portion, I was asked to write two simple queries based on a schema diagram they provided. I nailed both of those without any problem so I was off to a good start!

For the C# part of the test, I was asked to examine code similar to this:

public class Program
{
    static void Main(String[] args)
    {
        Int32[][] array = { new[] { 1, 2, 3 }, new[] { 4, 5, 6 }, new[] { 7, 8, 9 } };
        Console.WriteLine(GetValue(array));
        Console.Read();
    }

    private static Int32 GetValue(Int32[][] array)
    {
        return ProcessValue(array, array.Rank, array.Length - 1, 0, -1) - ProcessValue(array, 0, 1, array.Length - 1, 2);
    }

    private static Int32 ProcessValue(Int32[][] array, Int32 x, Int32 y, Int32 w, Int32 z)
    {
        return array[y - x][w - z];
    }
}
    

Without running the program, I was asked to solve the output. "This is to see if your brain can serve as a compiler," I was told. Thankfully I was given a piece of paper and a pen. I spent an equal amount of time working on the problem as I did debating in my head whether I should politely excuse myself walk out. Ultimately, I didn't get the correct answer; I was off by 1. Based on that, I failed the interview and didn't get the job. Thankfully! If my days there were to be spent "compiling" code in my head and solving inconsequential puzzles, I would have gone insane and quit within a week.

To make matters worse, this particular interviewer stood two feet off my left shoulder and watched every keystroke. I had to wonder if he was going to do that once I was hired. If that isn't their normal work environment, then why test me in such an environment? If a test isn't based on reality, then why administer the test?

Build an atom bomb to prove you can make a firecracker.

I have no problem with being asked to write a little code to show that I have at least some basic understanding of programming. It's important to make sure a candidate knows the fundamentals of looping and conditional logic, for example. One of my favorites is the "FizzBuzz" problem:

Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".

A problem like this is simple, can be solved in at most 10 to 15 minutes and is a good indicator that the candidate isn't faking their understanding of basic programming.

Incidentally, the result could look something like this:

for (Int32 i = 1; i <= 100; i++)
{
    if (i % 3 == 0 && i % 5 == 0)
        Console.WriteLine("FizzBuzz");
    else if (i % 3 == 0)
        Console.WriteLine("Fizz");
    else if (i % 5 == 0)
        Console.WriteLine("Buzz");
    else
        Console.WriteLine(i);
}
    

Anything more complicated than that is superfluous. Asking a programmer to write a complex application for you during an interview is like asking an electrician to build an electrical grid for you before they replace a lightbulb.

We're looking for a developer, just not a resourceful developer.

How many developers do you know that have never had to rely on a resource to solve a problem? None, you say? Then why would you limit a developer you're testing by excluding the use of resources? Every single technical test I've taken during an interview disallowed the use of any resource during the test. Here's a thought: why not blindfold me and and tie my hands behind my back, too?

The human brain is incredible in the way it can store vast amounts of information. However, it is limited. For repetitive things, our brains are awesome at long-term storage. For things we've only done once or twice? Not so much. For those things, I rely extensively on a much more reliable storage mechanism: hard drives. My laptop is filled with code samples I've written over the years. When I encounter a complex problem that I've solved before or a problem similar to one I've solved before, I reach for that code; I adapt it to the current problem. If I had to struggle to reinvent the wheel for each and every problem I encountered, I'd rarely meet any deadline.

There's another resource I use which, for whatever reason, interviewers always want to disallow: the Internet. This makes no sense whatsoever. Searching the Internet for the solution to a problem is, in many ways, an art form and it's a skill that every developer must have in their arsenal. What a developer does to find the solution to a problem should be part of the test!

You should want developers who are resourceful. You should want developers who can learn. If you don't, then I'm not a good fit for your organization.

The Pragmatic Passionate Programmer

The two interviews I had last week that interested me asked questions like:

  • What was the most interesting part of the last project on which you worked?
  • What is the most recent technology you've learned, why did you want to learn it, and how did you learn it?
  • Why did you choose to use technology X over technology Y in your last project?

These questions explore the two most important traits of a good programmer: the ability to learn and a passion for the craft of programming.

That last question, though, really bothered me at the time. You see, I explained to the interviewer that I was the chief architect and lead developer on my most recent project. The project was your standard 3-tier architecture - SQL Server dababase, business layer/ORM, and a Silverlight front end. The ORM I chose to use was my own which is based on Martin Fowler's excellent "Patterns of Enterprise Application Architecture." It has been continually developed, enhanced, and maintained over the past 12 years and has proven to be very successful in every project where I've used it. The interviewer questioned why I used my own ORM instead of a commercially-produced ORM like Entity Framework or an open-source ORM like NHibernate. I explained that I had evaluated those ORM's and had to consider that the team I was tasked to lead had little OOP experience and that my ORM was very direct and simple to use. "Well, I think that was a mistake because if you use a commercial product or something that's community-driven then you get the benefit of a large group's expertise as opposed to just one person and you also have the benefit of regular updates and enhancements from the community," she said. We hotly debated the pro's and con's of my decision and, in the end, agreed to disagree. (Toward the end of the interview, she actually apologized for being so openly hostile toward me.) At the time, I was irritated that she was so quick to dismiss 12 years of hard work without ever having seen it. Now, however (though I don't think it was intentional on her part), I see that it was actually a really good interview technique. She was able to get me to show passion for my work, my love for programming, and an ability and willingness to defend my decisions in spite of the desire to please her just to get the job.

Would you hire a chef without first tasting his food?
Then why would you hire a programmer without first having seen his code?

I have yet to be interviewed for a position where the interviewer has asked to see a sample of my work. This is really disappointing. When I was a hiring manager, I would ask the candidates to bring their laptop (or at least print out some code) so that I could see something that they've written of which they're particularly proud. Once it was in front of us, I would ask what was the business problem that was solved. I would then ask for them to walk me through the code. I could usually get a good sense of the type of developer I was interviewing. I could see the way they formatted code - did they care enough to make it pretty; did they name classes, methods, and variables in such a way that the code was self-documenting; did they organize the project in a way that others could easily pick up the project and work on it, etc. I could get a sense of their thought processes - did they approach the problem in a logical manner, did they think in an object-oriented or procedural manner, etc. Most importantly, though, I could get a sense of their passion for solving the problem. If the candidate became animated and excited about what they were explaining to me, that candidate was a contender.

Smart and Productive? You mean you can have both?

Joel Spolsky has two criteria for hiring a good developer: you're looking for people who 1.) are smart and 2.) get things done.

People who are Smart but don’t Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. They would rather mull over something academic about a problem rather than ship on time. These kind of people can be identified because they love to point out the theoretical similarity between two widely divergent concepts. For example, they will say, “Spreadsheets are really just a special case of programming language,” and then go off for a week and write a thrilling, brilliant whitepaper about the theoretical computational linguistic attributes of a spreadsheet as a programming language. Smart, but not useful. The other way to identify these people is that they have a tendency to show up at your office, coffee mug in hand, and try to start a long conversation about the relative merits of Java introspection vs. COM type libraries, on the day you are trying to ship a beta.

People who Get Things Done but are not Smart will do stupid things, seemingly without thinking about them, and somebody else will have to come clean up their mess later. This makes them net liabilities to the company because not only do they fail to contribute, but they soak up good people’s time. They are the kind of people who decide to refactor your core algorithms to use the Visitor Pattern, which they just read about the night before, and completely misunderstood, and instead of simple loops adding up items in an array you’ve got an AdderVistior class (yes, it’s spelled wrong) and a VisitationArrangingOfficer singleton and none of your code works any more.

Conclusion

So if you're thinking of interviewing me for a position at your company, please take these ideas into consideration. Please ask me questions through which I can demonstrate that I'm smart and that I can get things done. If you only throw "Aha!" questions at me or ask me to solve trivial brainteasers, don't be surprised if I politely excuse myself and never return. You see, I'm interviewing you just as hard as - if not harder than - you're interviewing me. You're looking for a good employee but I'm looking for a good employer.

Posted on 8/25/2013 at 01:08 PM , Edited on 8/26/2013 at 09:08 PM

Comments:

Leave a comment
  1. CAPTCHA