More Good Interview Questions

I was reading Good Interview Questions. I was a bit surprised by the first question:

State, Strategy, Bridge, and Adapter are all similar patterns. How are they similar, and how are they different?

But I suspect I was surprised because I’m no longer a developer and am not familiar with the patterns. I suspect I would keep a paper copy of the patterns and ask a candidate to read them first if the candidate was unfamiliar with the patterns. I don’t want to make a test out of attempting to remember the pattern; I want to hear the candidate’s perspective on the patterns.I loved the second question:

What makes good, maintainable code?

What an opportunity to ask followup questions such as “When have you not written maintainable code? Why?”I like meta questions, such as the third one:

What questions should we be asking you?

I’m not sure I would ask every candidate how to improve the interview, but meta questions are more illuminating (for me) than hypothetical questions if I want to understand how the candidate thinks.

3 Replies to “More Good Interview Questions”

  1. Patterns are by no means mainstream. Go to Borders, Barnes and Noble and Amazon and count the number of books on patterns.
    More importantly, the number of companies who know about, much less care about, patterns, is probably miniscule. I’m sure they’re more popular in certain clusters, like Silicon Valley, Silicon Alley and maybe Route 128. But the rest of the country thinks patterns are something you get from Butterick.
    And even more importantly, how many years have patterns been around – and by extension, how much experience in using them could anyone realistically have? Not many. Patterns is something that can be learned – an expert wouldn’t have that much of a head start on a novice.
    Here’s a tutorial on patterns:
    Lastly, if you concentrate on technical arcana, it is my belief you will get inferior results to someone who has a grounding in the business you serve.

  2. I’ve gotten questions on patterns, like “name as many patterns as you can remember that exist in framework X. What were the benefits and drawbacks of the patterns used? What other patterns could they have used instead?” (very hard questions, BTW.)
    Of course, the same company asked puzzle questions.
    Some of the companies I considered joining required expert-level knowledge of design patterns, because they teach classes on that subject.
    I myself, when interviewing candidates, ask a candidate if they’ve read Design Patterns, Refactoring, and some other books. If they say yes, I ask them to describe what patterns or refactorings they’ve used. (And I have the books there for them to refer to.)

  3. Understanding and knowing patterns helps you to not only write code that others will understand easier, but also to apply a standard naming convention that tohers will recognize. Part of knowing about patterns is knowing their name — when you have new people come and look at code (new developers, contractors, etc.), if they’re familiar with patterns (many people have the Design Patterns book by Erich Gamma et al.), and they see a class that’s called somethingSomethingState or somethingSomethingAdapter, then they immediately know what the role of that class is.

Leave a Reply