comments 2

Do you know design patterns?

Well, do ya punk?

I got asked this today in a telephone interview. It was the second question, after ‘tell me about yourself’. My first instinct in response was sarcasm. “What, there are patterns? It’s not just organised chaos? There are actual principles involved in writing this shit? How could I have missed that these last 11 years? My mind is blown!”

I decided that (probably) wasn’t polite, so I bit my tongue. Still, I couldn’t help a small sigh of disappointment and a quick glance at the clock. I already knew I didn’t want the job.

That might seem like an extreme reaction but I’ve been in this kind of interview before. I’ve seen where it leads. You might think it’s a fair enough question – and yes, it probably is. It’s not a given that any given developer knows much about design patterns. It’s not a given that they have studied anything about their craft at all. I’ve seen some pretty shocking code in my time – I’m mostly over it, though memories of summer ’07 still wakes me up in a cold sweat – and it must come from somewhere, after all.

But at the same time, I’ve been developing for 11 years; for actual technical firms, with large teams of technical people, selling themselves on their technical expertise. They know this because it’s on my CV. I would contend that, if you’ve spent any time at all working in such environments, as opposed to just maintaining a few Visual Basic macros in your capacity as admin assistant at the local surgery, the chances are that you’ll probably be able to identify, say, a factory pattern or a builder pattern if one were to jump up and bite you on the nose.

You might disagree. Fine. But that’s all really besides the point. My gripe isn’t that this is a bad question – on it’s own, it’s fairly inoffensive, it’s not how I would want to conduct an interview, but it’s a reasonable starting point if want to get somebody talking about technical theory and probe their deeper understanding of the concepts.

But that’s not what this was about – and I knew that already. I was already hedging what the next question was. He’s going to ask me about DRY I thought to myself.

“What does the ‘L’ stand for in SOLID”?

Now, before I answer that, let me ask you a question: if I were to say “I promised that I would do it?”, what grammatical tense is that?

Know the answer? Awesome! Particularly if you said “Conditional Perfect”. Well done! Seriously. Have a cookie. You should write a kid’s book. You seem good with this grammar thing, I’m sure you’d be great at it.

The rest of you, don’t worry. I couldn’t have answered that question either. I mean, I use the tense all the time (“I said I would do it and I will do it!” or “I did tell you that I would be going out tonight…”) and I probably would have guessed ‘conditional’ something, just because I’ve studied Spanish and I vaguely remember the corresponding grammar structure. I didn’t know the answer though. If you asked me that in an interview I’d probably have gone “er, wut?” and tried to fudge it.

Yet despite this shocking lack of grammatical expertise, I’ve been known to string multiple sentences together without undue distress. Honestly. It’s on video and everything.

In the context of a technical interview, asking me about DRY and SOLID and threads versus processes (yes, that was in there too) is akin to asking me about the future perfect and split infinitives in the context of an interview to be a journalist or a marketing copywriter. Essentially, you’re asking if I know what the tools of my trade are, rather than whether I know how to use them and when. Or, in other words, you’re testing what I know, rather than what I can do.

Which is fine, I guess. But you do also need to test what I can do.

Many companies do this by providing a technical test. A few interviews I’ve been to have done it by way of a presentation or a coding task, where you present back to a technical interviewer and discuss your understanding of what you’ve done.

This particular company had, to be fair, already provided me with a test. Unfortunately, that test had been far too easy – I finished in 20 minutes what they expected to take an hour.

Now, that’s not because I’m a genius (so kind of you to notice). I judge by comparison. I’ve done some pretty hard tests in the past. I did another one that very same day which I barely finished in the 90 minutes allotted. I actually had to think about many of the questions. Scary, I know.

For me, this is a massive red flag (the too easy part, not the thinking part). First, because I wonder whether the person setting the test thought that it was actually difficult. Secondly, I wonder if they knew it was quite easy. Neither of these are good advertisements for the kind of technical quality already at the company, because you’re either not very good or you’re setting a low bar. If then in the follow up interview you start asking me quiz questions about software concepts that I might have studied at university (had I not done a Geography degree), I quickly lose interest, because I start worrying not only about the technical talent already at the company but also the kind of people you’re hiring.

Because yes, I know design patterns. But I want to work with people who know how to use them.

Which is why, shortly after the interview, I phoned the agent and said I wasn’t interested. I don’t want a third date.

It’s not me, it’s you.

2 Comments

    • mdsomerfield

      Thank you :). Hadn’t seen that strip but yes, pretty much sums it up. I don’t mind whether it’s a test or a puzzle or a pair programming exercise as long as somebody has thought “how are we going to test if they are any good?”.

Leave a Reply

Your email address will not be published. Required fields are marked *