Just got back from vacation and read a blog post by Eric with some concerns about developer knowledge on OOP. It reminded me of a similar conversation I've been having on and off with friends for years, so it seemed like an appropriate topic to write a quick post. After that, I'll also toss in a quick synopsis about interviews.
Eric claims that far too many devs don't really know OOP. To some degree he's absolutely right. I see the same thing when I conduct interviews. There's an interesting dynamic when it comes to OOP, and it depends on how you approach the topic. If you ask a lot of people about OOP, you'll most likely get one of two answers - either they feel it's great (whether they really know much about it or not, they feel the industry [read: you the interviewer] thinks it's important, ergo, it's a Good Thing (tm)) or they feel it's a complete waste of time and far too complicated. Since apparently a good chunk of developers can't articulate the pillars of OOP, some people have even written entire papers asking the question "Was OOP a Failure?"
I'm afraid the RIP engraving on the OOP tombstone is entirely premature, but here's what I've discovered: Just about everyone LOVES consuming OO code, but a good chunk of developers don't like writing OO code (or simply don't know how). OO libraries are easy to consume. It's simple to understand MyMainForm.Text, AcceptButton.Enabled, and MyData.Fields["RowID"].Value. Additionally, the data and behaviors are easily discoverable. That is to say, you start with some object, and in most IDEs with most OO-languages, you click "." and you get all the object's fields, properties, and methods. There's a good reason for all this goodness - one of the primary goals of OOP is code organization. This is much easier than having tons of variables strewn in dozens of files, with names like gdwmaxdaysinqueue, CUST1_TEMP_DBID, or even X$. While some devs might even rebel against writing OO code themselves, you'd be hard pressed to find (for example) a .NET dev who would give up the .NET framework classes for winforms in favor of something flat like the Win32 User API.
The problem is that getting all the organization isn't free. Just like living in a house is infinitely easier than building a house, consuming OO code is much simpler than actually writing it. At the same time, most newer languages are making this much easier. Having said that, I also strongly believe that a lot of the "complexity" is in some respects purely perceptual. I often say that when faced with a problem, most programmers simply bang away and try samples until they get something to work. After that point, whatever happened to work becomes "the way to do it". Problem solved, why go back and reinvent the wheel? However, writing good OO code requires a fair bit of upfront thinking rather than the "discover a working solution as I go" approach. A lot of developers, particularly self-taught devs, get passed this experience and don't like to go back and discover a different way to write code to solve the problems they're already solving now, albeit somewhat disorganized. And before I get beat up for saying that, it isn't to say that only OOP code is well organized and everything else is not. In reality, I find that the most resistance to OOP comes from people who have programmed for years without it. Some of the newer bunch simply don't know much about it, but aren't really against it.
To prove the case to myself, I taught several semesters of OOP at USF. The students (most of whom were taking the class as part of a business or accounting curriculum rather than CS, some with no prior programming experience) had absolutely no difficulty at all getting the concepts with a minimal amount of proper guidance. At the end of the 7 week course, they simply couldn't fathom writing code any other way. But unlike the trial-and-error method of most self-learning, not everyone has the patience to get the guidance necessary to get into OOP, even if it comes from a book and not a teacher.
And without further ado or even a good segue, I'll dive into the interview stuff.
Interviews really serve one purpose - to see if the person in front of you can do the job. This has as much to do with technical knowledge as it does with a "fit" in the team. What an interview shouldn't be is a game of trivial pursuit. If your candidate will be writing a lot of OO code, then of course it makes sense for them to have a very good understand of OOP and be able to intelligently articulate the pillars of OOP. In today's environments, OOP is often an extremely relevant topic, which candidates really should be (at the very least) brushing up on.
However, should a candidate be able to explain how to correctly write a custom WCF transport off the top of his or her head? In 99.5% of the cases, I'd wager the day-to-day tasks the dev will be performing has nothing to do with that. Some interviewers use the interview as a vehicle for conveying Alpha developer dominance (i.e. showing off who is more intelligent or technically savvy and making sure the candidate knows he is at the bottom of the totem pole should he get the job). The questions are about things the candidate won't be experiencing on the job and any answer wouldn't necessarily qualify or disqualify the candidate from the real duties they would have to perform. That's just bad form, and if I caught anyone on my team doing that, they would really be in for it.
The same goes for that incredibly stupid bucket of trivia puzzle questions concerning light bulbs, coins, minimum distances, and trains. A lot of people claim they use these to gauge "problem solving skills". I claim BS. In fact, most of the people asking these ridiculous questions didn't know the answers themselves until they were told or found them in a trivia puzzle interview questions book. If you are asking these questions, chances are that you (a) don't know relevant questions to ask and are using these as fillers, or (b) are just trying to show off. Knock it off; you're not impressing anyone (and if you're impressing yourself, seek professional help as soon as possible). A lot of candidates are nervous enough as it is. Ask questions relevant to what they will actually be doing (and no, it's not trying to figure out how to find defective pills in the minimum number of weighings). If the open position was about Mensa Puzzle Solving Punditry, it would be called "Mensa Puzzle Solving Pundit" instead of "Sr. .NET Developer".
Then what should you be asking? Well, I'm not going to be presumptuous enough to tell you what is the best way for you to interview. In the end, that's really for you to decide. My approach is simply this: talk to the candidate. Anyone who can do the job can hold a very engaging conversation about the relevant topics. I avoid the trivial pursuit approach at all costs. Typically what I do is start vague and steer the conversation into more and more specifics as it goes. For example, find a previous project on the resume that claims to have incorporated some of the relevant techniques or technologies. I start by simply asking the candidate to talk about that project.
I look for a few tell-tale warning signs. For example, I don't want to hear "we did X" and "we implemented Y". I'm not hiring your entire team. I'm trying to hire you. I want to hear what you did specifically, not what your team did. I want to know what you know, not what your team knows. Sometimes people who (involuntarily) get off a project hide behind the accomplishments of others and don't understand the relevant topics at all. If I hear too many "we"s, I immediately start asking specifically about what the candidate himself did and understands about the project.
Also, if (as a candidate or interviewer) you don't understand a topic, don't talk about it. Nothing bothers me more than BS during an interview. I'm not looking for perfect knowledge. I'm looking to see if someone is qualified enough to do the job. Don't make things up. Don't throw around acronyms or buzz words you don't understand. If you get caught (and particularly pray I'm not the one who catches you ;-)) you will look 10 times dumber than you probably are. It's OK to say you don't know, or don't know off the top of your head. I will then try to assess how you would solve such a problem involving that topic, and that's more important to me than knowing every answer from memory. If you can figure out something after reading a help doc for 15 minutes, that says a lot about your ability to perform and produce given something you didn't already know from the start. If you are an interviewer and you do this, and the candidate catches you, you will also look 10 times dumber than you probably are. That's not going to help you fill the position.
So as the candidate begins to discuss the project (and particularly with me homing in on certain technologies or techniques), I begin to ask more and more specific, and deeper questions. A proficient person will be able to keep up and go along with the conversation. When the candidate can no longer keep up, I've discovered the limit of their knowledge on the given topic. If they can keep up until I no longer have questions, then welcome aboard! I know I can do the job, so if you know as much or more than I do, I can't ask for more. This more "natural" style of communication (as opposed to simple question and answer sessions) also relaxes the candidates a bit more. That helps me filter out any noise caused by nervousness.
Do you have any good interview techniques or pet peeves? Let's hear about it! :-)
posted @ Wednesday, January 02, 2008 4:30 PM