Interview*ER* styles, techniques, and questions

[Stuxnet]

I do, on average, 5 - 10 interviews per week. I actually don't mind it since I get to meet a lot of different people and I have a very direct and and substantial impact on the quality of developer that works at our company.

However, because I do so many interviews it's really easy for me to fall into the "rapid fire Q&A" pattern, which robs the situation of the personal touch necessary for both parties to make an informed decision.

Given that, I was just curious what techniques, styles, and questions you guys use to interview candidates... maybe I can use ideas here to change things up a bit.

Here's my typical flow:

- Ask candidate about recent background, favorite project(s) (looking for enthusiasm and challenging projects)

- Ask a number of OOA/D questions that escalate from simple (what's polymorphism?) to more advanced (design patterns and how they relate to OO) if the candidate is applying for a senior role

- Ask candidate to solve the design and implementation of a few short problems. Looking for good thought process, asks questions about design, and uses optimal/up-to-date language features.

I try to keep the conversation fluid and allow the candidate to express themselves, while subtly challenging the claims on their resumes. For instance, if you say you're an XYZ guru, I'll tailor the last bit of the interview to hammer that pretty hard.

 

[EagleKeeper]

Design patterns is a subjective issue. It demonstrates that you have had classes on what design patterns are and how someone thinks it should be used. Many decent engineers, and I may be wrong/biased, will choose an implimentation method to a project/problem based on what has worked well in the past and adapt the design as needed.

/rant

I would be curious as to when this "design pattern concept" ideology" came about, from what functional area and/or industry/school.

I have worked for 4 large companies in my career in Defense/gov projects and a multitude of small companies. Until this year, I never heard of "design patterns" until a lead came back from a training course and hung up a poster with 20+ block diagrams that define a new holy grail.

 

[Ken g6]

Relevant Slashdot story. At least it might tell you what not to do.

 

[Stuxnet]

Design patterns is a subjective issue. It demonstrates that you have had classes on what design patterns are and how someone thinks it should be used. Many decent engineers, and I may be wrong/biased, will choose an implimentation method to a project/problem based on what has worked well in the past and adapt the design as needed.

/rant

I would be curious as to when this "design pattern concept" ideology" came about, from what functional area and/or industry/school.

I have worked for 4 large companies in my career in Defense/gov projects and a multitude of small companies. Until this year, I never heard of "design patterns" until a lead came back from a training course and hung up a poster with 20+ block diagrams that define a new holy grail.

Well since you have so little experience with them or knowledge of them, they must be useless.

 

[Markbnj]

I would be curious as to when this "design pattern concept" ideology" came about, from what functional area and/or industry/school.

See the book "Design Patterns" by Vlissides, Gamma, et al. I believe it's an Addison-Wesley title, and came out around the early-to-mid 90's. The book was an attempt to capture and codify common patterns that arise in the relationships between objects. It's sort of a best practices manual for solutions to common architectural questions.

Since the 90's Design Patterns have subsided into the background a little bit, but that's probably just because we all use them every day without having to think about them as such. Patterns like model-view-controller, and factory, and provider-consumer have just become part of the vernacular of the business.

 

[DaveSimmons]

It earns you geek points to be able to name the pattern that you are using instead of just using it

IMHO:

I can see some value in things like design documents to be able to say "visitor pattern" as a shorthand and hopefully more precise way of stating that you're going to create secondary, swappable accessory classes to implement algorithms instead of adding them to an existing class or creating a subclass.

On the other hand, you can spend a lot of time memorizing patterns, or trying to pound a square peg into the round hole of an existing pattern. Like most techniques patterns are subject to zealotry and silver bullet mentality.

 

[Stuxnet]

Relevant Slashdot story. At least it might tell you what not to do.

Agreed. I've seen this type of questioning flare up whenever I bring in a newly appointed architect / tech lead and they feel like getting clever in their first outing as an interviewer. Obviously I derail such questioning ASAP because it's a total waste of time (relying on a mental leap by the interviewee) and puts unnecessary pressure on them. It's hard enough getting them to relax, so asking for some mental gymnastics that have no application to the position has all kinds of nasty side effects.

That's why I like small design problems or implementation problems. If you have the applicable background, you'll do fine. If not, you won't. If the candidate gets it or doesn't, your question is answered with a fairly high degree of reliability... Versus wondering if they happened across your uber brain puzzle on google (if they get it) or are having a panic block (if they didn't).

As for patterns, you had better be familiar with the more common ones. I personally don't care if you don't know the terminology, but if I pose a design problem that virtually requires dependency injection but your solution boxes us into a corner and can't scale because you aren't familiar with the underlying concept, see ya.

Other patterns (or simply broad design concepts) such as SOA, MVC, and MVVM are so common and pervasive that if you DON'T know them AND their formal terms, it shows that you're grossly out of touch with your craft.

Trust me, I detest design fads and such (I've posted about it before), but there's some shit you had just better know if you're to be taken seriously.

 

[sourceninja]

I just talk with the guy. About whatever. I can get a feel for someone who is smart and knows what they are talking about compared to someone who is faking it.

I care that they are smart more than I care if they answer some detailed problem in my office with no prep time. In the end, if they are really smart I can teach them technical skills. What I can't teach is being a great person who can communicate with the rest of the staff.

 

[Cogman]

Honestly, probably the best way to find someone that can develop is to make them write code and explain it to you. Given them a day or whatever, have them solve a problem that is semi related to what you do, and then when they come in for the interview, dedicate a significant portion of the interview to having them explain the code, what it does, and why they did what they did.

This will filter out 99% of the crappy developers. The other 1% will be easily caught by just having a chat with the person and seeing what they think about current tech trends.

 

[EagleKeeper]

Well since you have so little experience with them or knowledge of them, they must be useless.

I do not believe that useless is what I was implying.

They may not be useless, they may have already been known under different concepts.

The below two quotes seem to bear this out.

It earns you geek points to be able to name the pattern that you are using instead of just using it

IMHO:

I can see some value in things like design documents to be able to say "visitor pattern" as a shorthand and hopefully more precise way of stating that you're going to create secondary, swappable accessory classes to implement algorithms instead of adding them to an existing class or creating a subclass.

On the other hand, you can spend a lot of time memorizing patterns, or trying to pound a square peg into the round hole of an existing pattern. Like most techniques patterns are subject to zealotry and silver bullet mentality.

I would be curious as to when this "design pattern concept" ideology" came about, from what functional area and/or industry/school.

...

See the book "Design Patterns" by Vlissides, Gamma, et al. I believe it's an Addison-Wesley title, and came out around the early-to-mid 90's. The book was an attempt to capture and codify common patterns that arise in the relationships between objects. It's sort of a best practices manual for solutions to common architectural questions.

Since the 90's Design Patterns have subsided into the background a little bit, but that's probably just because we all use them every day without having to think about them as such. Patterns like model-view-controller, and factory, and provider-consumer have just become part of the vernacular of the business.

Since the 90's Design Patterns have subsided into the background a little bit, but that's probably just because we all use them every day without having to think about them as such. Patterns like model-view-controller, and factory, and provider-consumer have just become part of the vernacular of the business.

XP and Agile type concepts started entering the verbiage 5-10 years ago, even though such concepts were being used 20 years previously; they just were never formally tagged as such

 

[Bulldog13]

<3 the repository pattern

 

[homercles337]

I just talk with the guy. About whatever. I can get a feel for someone who is smart and knows what they are talking about compared to someone who is faking it.

I care that they are smart more than I care if they answer some detailed problem in my office with no prep time. In the end, if they are really smart I can teach them technical skills. What I can't teach is being a great person who can communicate with the rest of the staff.

This is what i do too. Except that i just talk with them about what they have and done in their past/current positions (as opposed to what they did over the weekend), then interject with questions, informal conversation style. You get way from this, than saying, "solve this problem."

 

[sourceninja]

This is what i do too. Except that i just talk with them about what they have and done in their past/current positions (as opposed to what they did over the weekend), then interject with questions, informal conversation style. You get way from this, than saying, "solve this problem."

Yea, I'm always trying to stay on topic. I like to talk about their jobs, they favorite projects, hobbies, thoughts on trends in the tech industry. Anywhere the conversation tends to flow really.

I get side tracked sometimes and talk about something way off topic, but even there you can sometimes learn a lot about a person (20 minute conversation mid-interview on minecraft logic gates).

 

[Gibson486]

I got a question for you interviewers....when someone answers a question wrong, do you automatically disqualify them? Obviously it depends on the question (like if they did not know how to explain a pointer, red flag).

 

[Markbnj]

I got a question for you interviewers....when someone answers a question wrong, do you automatically disqualify them? Obviously it depends on the question (like if they did not know how to explain a pointer, red flag).

You answered your own question .

 

[Stuxnet]

I got a question for you interviewers....when someone answers a question wrong, do you automatically disqualify them? Obviously it depends on the question (like if they did not know how to explain a pointer, red flag).

Generally speaking, no. But then again, the nature of the interviews I conduct tend toward a fluid conversation style where you're asked how you approached various problems in the past and how you'd approach a few theoretical problems. This type of discussion is good at revealing how comfortable you are with yourself as a developer, which itself is usually directly correlated to your ability. I say "usually" because you occasionally get someone who has a fair amount of false confidence in their ability because they're either oblivious to negative feedback they've received in the past or because they've worked in hack shops and no one "better" was around to mentor them and "bring them up."

HOWEVER... I will most certainly "validate" your resume, especially the pieces that correspond directly to the position for which you're interviewing. If your resume specifically states that you know .NET 4.0 inside and out, I'm going to ask you which features of the 4.0 framework you implemented. In this particular case, a lot of people list ".NET 1.0/1.1/2.0/3.0/3.5/4.0," but really what they mean is that they've compiled against those frameworks. Yeah... I don't care if you can click a drop-down and target a different framework. If you can't demonstrate any real tangible knowledge of the 4.0 framework, I'm going to get suspicious and begin to press you on other areas as well. In those situations, the interview tends to get very uncomfortable very quickly... not by design, but just because things usually unravel fairly quickly from that point. I don't necessarily care that you're a 4.0 expert, I just want to be able to trust what's on your resume. I'll remain neutral on the matter until you sway me one way or the other.

Like I said earlier, I don't like to just fire off a bunch of Q&A, but it has its place. We're a heavy OO shop. I'm not saying our approach is 100&#37; awesome and that the rigid OO approach we took was the best choice all around, but the fact remains that we're a heavy OO shop and you need a "second nature" grasp of it. Now, frankly, I've never found OO to be particularly difficult and I probably sound like an OO snob, but it never ceases to amaze me how many people claim "OOA/D expert with n years writing n-tiered applications" who can't demonstrate an understanding of encapsulation, let alone whip up a quick object graph of a theoretical 2D imaging API that evolves as we add requirements during the discussion.

So in a nutshell, if you can't explain a rudimentary concept, yes, you'll be disqualified immediately. If you can get through the API talk above with a fair amount of competence, then no problem. I honestly don't care if you come up with the leetest arrangement possible. In fact, I'll be a little discouraged if you blow 10 minutes agonizing over trivial organization. I'm far more interested in your thought process, whether or not you seek design clarification, etc.

One last thing: I always ask about a basic utility method implementation (usually to test knowledge of recent language features). After that, I ask you how you'd test it. Believe it or not, this is actually one of the most important pieces of the entire interview. The method itself is so basic that testing it ought to be mindless... but if you leave out boundary testing or flat out ask what unit testing is... SIZZLE. People who arrive with no formal unit testing under their belt are usually coming from a 2 - 3 man "attack force" development team where everyone's flying by the seat of their pants. These people usually don't adjust well to a structured development process and, more obviously, lack many of the skills that would otherwise get them up and running quickly.