Interviewing coders...

[Dan East]

[Hosed]

[Presto]

[Dan East]

[DillRye]

One thing that I have always hated were the people who pretend to know what they are doing when they have absolutely no idea at all. I witnessed this time and time again when I was a technician at Best Buy. I would give the honest answer, but the customers would often like to talk to the guy who made up some totally off the wall answer. I find this is a common occurrence in anything computer related. Another thing I see that people do all the time is try to talk so fast that you don’t have time to question them when they are wrong. I believe portraying your idea concisely is much better than trying to deliver it as fast as you can.

I propose that you ask a question that is total nonsense and see how they will react. If they make up some total b.s. then you know they are not people you would want to hire.

[fzammetti]

[refractor]

[refractor]

For those interested, of 8 candidates (so far - I might have one more next week):

Only half of them even attempted the OO questions Of those that did, only two made "sensible" comments and structuring. One of them decided that Dan's "OO in C" was a good idea because "it'd be faster than C++"...

The database side was even more depressing. Not one of them answered all of the questions. Of the three straight SQL queries they had to write, nobody got #2 or #3 right, and most got the first wrong.

One only answered the SQL query questions... and got them all horribly wrong.

Thankfully, there was one guy who was good at the OO part, could discuss things well, and had a better stab at the SQL than most of the others.

And now I have to go read some books for when I have my own interview "early next week"

[fzammetti]

Sounds like you haven't had many good candidates. A suggestion...

Can you post your questions here? It might be too late for it now, but that way you could get some answers back from people here and come up with some sort of baseline. It could be that the questions you are asking are unfair in some way, it could be that they don't make sense (and potential employees might be inclined to not admit that) or they may be good questions and you just got a batch of terrible applicants, but you'd have some reference to go by then.

[andyclap]

[fzammetti]

[refractor]

[andyclap]

[refractor]

Sure, if you'd like the test as a Word .doc file (with some hidden answers and comments) then give me a private message with your mail address.

OO
I deliberately left the point class out of the "analysis" because I didn't want them to worry about defining a point class - it was really a "take it as read" approach.

For the "border" question, all but one of them put the border info (type, colour, thickness) into the polygon class, rather than making a new border class - that was a bit disappointing.

SQL
For the SQL side, the second question isn't as obvious as it may at first appear. The key word in the question is "all". Lots of people half-answered it and thought they had it right. If you messed up the first or second, the third wasn't evident.

Error 100 isn't 100% a trick Code 100 is (generally) NO_DATA_FOUND (in Oracle, Sybase, MicroSoft SQL Server at least). If they commented something like "I'd look in the manual", that was fine. Really that was to show whether they'd embedded SQL in procedural languages or made stored procedures (we do both a lot here).

Quite a lot of them commented that if I'd given them a database to access with a GUI/Isql then they'd have done much better. We deal with confidential banking applications and data, and some of the time we have to work without any data because the bank can't give it to us. Sure, we could make it up, but sometimes it's distinctly non-trivial to fudge together some "sensible" data.

[fzammetti]