Not like me?

posted Friday, August 20, 2004 12:45 PM
Today I interviewed our first candidate under our new process.  We started with a quick 30 minute written test covering some basics and then dove into a hands on programming test.  During the hands on test it was apparent that the candidate had a different development methodology then myself.  He preferred using dataset/typed dataset, where my preference is with custom business objects.  He seemed to have a decent grasp on many of the topics covered but the whole dataset thing made it difficult for me to get sold on him, after all he was not "like me".  It seems appropriate to separate my personal development preferences from the interviewing process since every organization does things differently.  When you interview candidates do you look for people "like you"?
16 Comments

# re: Not like me?

Friday, August 20, 2004 2:51 AM by Lorenzo Barbieri    
I look for brilliant and capable people, and if they're not like me... it's better, because we can evolve by comparing our different views.
Of course it depends on how much he/she is different, because I also want to avoid religious wars...

# re: Not like me?

Friday, August 20, 2004 3:04 AM by Rob    

When evaluating technical skills like programming I typically hire people that are BETTER than me in some way. They know something I don't they have a deeper experience base with a particular technology or they are just plain smarter than I am.

Avoiding the religious wars are important as mentioned above but if you are on the same team, why have 2 first basemen?

The other thing that gets people above the bar for me is their passion for what they do. I eat, live, breath (and rarely sleep) this stuff and if you wanna play on my team boy you better be like minded or we will eventually piss each other off...and since I am the boss... 8-)

# re: Not like me?

Friday, August 20, 2004 3:08 AM by Darrell    
Depends on what you mean by "like me." If you mean approaches technical problems in the same way, programs the same way, has skills in the same area, then NO!

If you mean is self-motivated, willing to learn, is a good team player, etc., then YES!

Just like a good consultant, my answer comes down to "it depends." :)

# re: Not like me?

Friday, August 20, 2004 3:13 AM by Paul Wilson    
I agree with all the above, but you also must find someone that will fit into your team.

# RE: Not like me?

Friday, August 20, 2004 3:17 AM by Eric Wise    
Just remember, someone like you will have the same blindspots as you. =)

Also, I'm not sure how long your test was, but if I'm trying to prove to someone quick and dirty that I can get data out of a database in Visual Studio, you better believe I'm gonna slap it in a dataset and move on to the next question. I do favor to use custom business objects though.

I generally like people who do things a bit different than me, but who have the social skills to know which battles to fight. As a developer you can shape those around you with convincing arguments, however you need someone with the sense and maturity to know what battles are a waste of time and which are actually relevant.

That's one of the reasons why I agree with Erik Sink about not hiring 'hackers'. Prima Donna coders tend to be obsessed with just being "right" by implementing whatever changes they want no matter what the impact on the team and organization. That's a bad hire.

# re: Not like me?

Friday, August 20, 2004 3:40 AM by Scott Galloway    
It depends, if their use of objects differs then I'd ask them to justify what they're doing - Typed DataSets versus custom business objects is actually a great example - why do they prefer one way over the other. There's other areas where the difference does become problematic for me, using in-page code for example would be a problem, as would machine-gun-debugging (so development through debug where a developer would reather try to recompile rather than understand the problem through parsing the code themselves). I always try to look for prople with something to bring to our team if I'm looking for a senior, juniors can be forgiven having sloppier methods...

# re: Not like me?

Friday, August 20, 2004 3:40 AM by Jeff Lewis    
Finding someone that is not like you is ok, but just make certain that they will conform when required.

There is nothing worse than a brilliant developer that goes off on his own and then makes the rest of the company pay for his changes...

# re: Not like me?

Friday, August 20, 2004 3:52 AM by Steve Hebert    
Not like me is fine, as long as their approach to the differences is positive.

Was he/she open to the alternate method of using business objects? Did the person ask for materials to explore the approach. When you explained your approach was the person defensive or eager? Did the person grasp the benefit/cost discussion you had with them on each approach?

These are the discussions that tell you a lot more about a developer than the coding test itself. Programming philosophy reveals more about a coder than one solution to one problem. Do they push themselves or do they requiring pushing? There's a world of difference betweent the two - hire the pusher and skip the pushee.


# re: Not like me?

Friday, August 20, 2004 3:54 AM by Mark    
A follow-up to the programming test would be a good idea. Ask the candidate to explain their design choices and programming decisions. The candidate should be able to justify their choices.

Echoing Darrell, a motivated, teachable, team player is just as important, if not more important than their ability to write good code. I would rather work on a team with a person who has fair coding skills and is teachable, than someone who is the best developer in the world with a bad attitude.

--Mark

# re: Not like me?

Friday, August 20, 2004 4:28 AM by haacked    
A top notch developer shouldn't necessarily be like you, but should be able to compare and contrast different methods of development.

For example, in my opinion, the DataSet method (especially strongly typed generated using tools) is great for certain types of applications. But for others, it has its limitations and that's where custom objects come in. If the developer can explain the difference and why one would choose one method over the other and in which situations, you probably found someone worth keeping around for a second interview. :)

# re: Not like me?

Friday, August 20, 2004 4:47 AM by Steve Hebert    
I would argue that no followup programming tests are needed. Personally, I would not agree to one - unless you paid me. :)

Further testing will just illustrate other differences, it's the discussions about the differences that are important.

Good code is somewhat subjective to the task at hand. Keep in mind that a coding test has a pressure element - namely time and clarity. A talented programmer will adjust their coding style to fit the constraints. This is where the wording on the coding problem becomes important. It's generally implied that coding tests are a test of resourcefulness, not coding standards or robust design. This doesn't mean they're not useful, just keep in mind the results may not live up to the standard you have set in your mind. Or better yet, the person that fulfills your expectations may have an anal-rententive streak that drives the whole team nuts.

I wonder if I would actually build a business object layer on a coding test?

# re: Not like me?

Friday, August 20, 2004 4:50 AM by Steve Hebert    
Here's an idea, give the programming test to developers you know and respect who are not applying for the job (assuming they are friends who will take on this task). Give them the same time constraints to complete the task. If it's takehome, give them the same amount of time you gave your candidate - from the time you send it out until the time they have to submit it.

# re: Not like me?

Friday, August 20, 2004 6:05 AM by Steve    
Wow lots of great feedback here. I already had some thoughts formed on whether I really wanted someone "like me". When I wrote this post. As you guys stated I don't think the fact a dataset was used instead of a business objects should really matter. If the guy "is self-motivated, willing to learn, is a good team player" then it won't really matter if we have differing viewpoints. I guess what when I say "like me" I'm looking for someone who has considered several approaches and made an informed educated decision to go with one method over the other. It seems like a lot of folks just do what they see on MSDN without putting much thought into if its the "right way". In summary I do want someone enough like me that we can have heated discussions about the things that make us "different".

# re: Not like me?

Friday, August 20, 2004 12:02 PM by Anon    
>It seems like a lot of folks just do what they see on MSDN without putting much thought into if its the "right way".

"But of course it's the right way, it says so right there on MSDN!" :-)

I know what you mean, I've recently experienced some difficult working relationships for exactly this reason. Perhaps this would make a good subject for a new post, if you'd like to elaborate on it. I'd be interested to hear how prevalent this attitude is, and how others have learned to work with it (or around it).

Personally, I'm finding it very difficult to work with colleagues who have no real interest in discussing the technical issues that we face. (Why would they, when they've just read "the" answer on MSDN.)

# re: Not like me?

Friday, August 20, 2004 1:13 PM by Sean Chase    
Interesting because I love typed datasets - haha. Personally, I look for someone who I can have talk through how to solve the problem. If I were interviewing you and you were using custom business objects and solving the problem, that would be just fine if the solution worked. Then we'd have a nice little debate at the end about the ease of binding datasets versus collections, sorting, serialization, etc, etc. If that were a good conversation and a solid debate, that to me would be a great interview. Just my $.02.

# re: Not like me?

Saturday, August 21, 2004 7:56 PM by Joe    
This is an interesting question and it really depends on the goal and role of the person.

Let me explain ... consistency amongst code in your team increases the overall manageability of the team. Not necessarily because the code is better, but familiarity with style and approach lead to greater understanding amongst the entire team.

That said, hiring people just like you mean that you loose the ability to work creatively by having different opinions on a solution and therefore driving new ideas into the overall development.

So I didn't answer question ... personally I hire smart individuals that work well in a team environment. No one is an island (and as the boss I can always tell them the way to do it ;)

Post a Comment

 
 
Prove you're not a spammer: 
3 + 3 =