As you saw in my previous post, my new company is hiring developers.  Well, we found one so far.  Amazingly, that developer has a similar background to me and my boss.  Hopefully that will make for a easier fit.

But, that’s not the point of this entry.

In creating an interview process, my boss and I had a couple of discussions about how to approach it.  We’ve both had people who interviewed great but they fell apart when they actually started developing.  I had read a blog entry about someone who’s company actually gave the candidate a very simple problem, a computer with a development environment, a time limit, and let them write a program to solve the problem.  I *LOVED* that idea.  One interview I had gone on about a year ago did a similar thing, but they went pretty elaborate where one had to set up a web page, do the database connection, and do a bit with several parts of the framework.  I personally didn’t want to have to set up that environment for someone, so I convinced my boss to do the simpler problem.  He agreed, so I wrote something up.

Now, in writing up the problem, I wanted to present one little twist.  I put an impossible condition into problem.  Why?  Because I wanted to see how the candidate would react.  In fact, I think the company I did MY interview for did the same thing.  They had a faulty database setup.  What I threw out was simpler.  But, it was a flaw in the requirements, not something that would stop someone from coding.

I learned something interesting with this test.  My expectation was that the candidate would see the issue and ASK A QUESTION!  That is my #1 pet peeve.  If one does not understand something, they need to ask questions.  I’ve never been upset with someone who honestly doesn’t understand something.  I *DO* get upset when people don’t at least TRY to figure things out.  It is a very fine line to walk.  There is a point where one must be able to discover answers for themselves.  BUT, in our business world, clarification is important, as what the customer asks for is not always what they say.  It’s far too easy to get into the ‘only do the requirements’ mentality that most big company development seems to have.  When things don’t make sense, it’s best to stop and try to make them make sense, else you’re wasting time.

Speaking of wasting time, it seems that’s what I’m doing.  Time to crash.  More stuff later!

Advertisements

2 thoughts on “Building a better interview for developers

  1. Before starting my own blog, I thought I would first read a new book, “Clear Blogging”.
    The author suggests going to Technorati while reading along.  I did that and clicked on “silverlight” which is in the “Top Searches” list and your posting was near the top.  I read that post and then looked at your most recent postings and saw this one.  After reading it, I felt compelled to post my first ever reply to a blog.
     
    I wanted you to know of all the millions of blogs how I landed on yours.
     
    Regarding your recruiting thoughts:
     
    If I saw a flaw in the requirements I might assume you guys aren’t really that great as a company.  I’ve taken tests where even the questions were wrong.  I usually assume the tester wouldn’t even understand my challenge.
     
    However, writing tests isn’t easy.  When I was studying for a Microsoft certification test, I went through some Microsoft preparation tests and some 3rd party preparation tools.  They all had numerous flaws.  I was worried that the real test would have similar errors, but I was pleasantly surprised to find it had easy questions.  They don’t risk giving vague questions in the certifications.
     
    I don’t like problem exercises either. My son gives exercises and he and I get into arguments about it.  (In fact this reply got delayed because when I told him what I was doing, we got into another long discussion.)  I tell him I might have trouble with the tests he gives because I don’t build web sites on a regular basis.  But if I’m not qualified why does he come to me for technical questions?  There is too much inbreeding in this industry.  There are a lot of really gifted developers that could do a great job for you, but might not pass your test.
     
    Of course my son’s response is that he doesn’t want someone with my skills.  He just wants someone to keep his head down and build websites.  My son has a good long lasting job.  I live in poverty.

  2. First off, thank you for reading my blog, and I’m glad that it was a topic you found interesting enough to comment on.
     
    You bring up a very interesting conclusion.  I had not even thought about that. 
     
    "If these guys can’t even get a basic spec right, what happens on a bigger problem?’
     
    I will definitely re-think our appoach.
     
    But, in response to your comparison between an interview test and a Certification test, my opinion is that these are two completely different types of tests.  On a Certification test, the tester is testing your knowledge of a subject.  They have to be very specific to get specific answers.  And from what I understand about many certifications is that they are multiple choice, right or wrong, black and white answers.
     
    The concept behind our interview test is designed to see how a person reacts.  It is more of a ‘situational’ test.  Real life is not black and white, right or wrong, multiple choice answers.  I, as an employer, want to know what a person is going to do when handed a spec that has conflicting information.  How they react is a critical piece of how I deal with that person.  If I know, before I hire them, that they don’t read spec’s very well, then my options are to either train them, pre-understand the specs given to them so that the specs are right, or not even hire them.
     
    On the other hand, what the people that I  *don’t* want to hire are the ‘mindless coders’.  These are people that only add a short term value to the development process.  They don’t grow.  They just ‘do’.  They don’t think up new ways to do work.  They don’t innovate.  They just code.
     
    And, finally, one other thing about our coding test.  All I asked was for printing out a number sequence on the screen, with a few different things printed at basic flag points.  It is a very simple, non-business related request.  But, it tests to see if a developer understand the basic logic of the computer languages, for loops and if statements.  It’s not that I don’t want people who cannot do the test, but I’d be hard pressed to hire someone who couldn’t.  Those are two very core concepts of how a program works, and if the person doesn’t understand those, they will not be able to contribute in a meaningful way.  Maybe if I was hiring junior level, fresh out of school, low paid developers, I’d think about it.
     
    Last, if you keep asking good questions, continue to talk about the job and the requirements, and continue to learn, you will be far and away ahead of people who just turn out websites.  My personal belief is that I would hire someone who knows how to learn than someone who has been doing the same thing over and over again.
     
     
     

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s