Fog Creek Software
Discussion Board




Avoiding hiring mistakes

I'd like to bring up the old worn out topic of how to avoid bad hires again. In my limited experience, the most difficult part is to filter out the bad personalities. The hostile ones who just can't work with other people without getting into a fight, or those who are just plain lazy and/or totally careless about their work. These people may be technically capable, too, and might pass any smartness test.

Problems like these don't easily come out during an interview, where the candidate is trying to sell himself. Any ideas on how to reveal the dark side before it is too late?

Something else that relates to the technical side of interviewing. Grokking pointers seems to be one of the things that most people here can agree on shows whether someone will ever understand programming. Has anyone else noticed that many experienced programmers also seem to struggle greatly with even relatively simple boolean expressions. I'm talking about the kind of trouble where they routinely make mistakes such as choosing AND instead of OR. For my next chance for an interview, I'm considering asking candidates to translate a simple business rule with some boolean logic into code.

Big B
Friday, July 25, 2003

---
Has anyone else noticed that many experienced programmers also seem to struggle greatly with even relatively simple boolean expressions. I'm talking about the kind of trouble where they routinely make mistakes such as choosing AND instead of OR.
---

I've never seen an experienced programmer that had trouble with that.  At least not on an understanding level.  I understand typing the wrong thing.  I just fixed a bug in my own code where I wrote <= instead of >=, and it took me 5 minutes to catch it because I thought it correctly, but wrote it wrong.

If they don't understand boolean logic on a fundamental level, then I don't see how you can be a good programmer.  But I fully expect even the best programmers to make mistakes with boolean logic every once in a while.

Andrew Hurst
Friday, July 25, 2003

Big B, I have never encountered a "hostile person" who did not have some reason for that hostility. It is the job of a good manager to understand what's troubling people and help them sort it out.

It's not hard.

Must be a manager
Friday, July 25, 2003

I do know one programmer who has trouble with boolean ARITHMETIC - bitwise and, or, xor, and how that relates to the integer values of those bits.

But he's a SQL genius, so I don't consider that a downside. When I worked with him, he did the hard SQL stuff I couldn't and I did the bit-twiddling. Worked out well.

Chris Tavares
Friday, July 25, 2003

Andrew - I am not talking about typos. Then again, some developers seem to check ten times more "typos" than others into the code repository, which certainly indicates a bad attitude as far as I'm concerned. What I was talking about is developers who have years of knowledge and experience but still fail to fully comprehend how to combine boolean expressions to solve problems.

Must be a manager - being a practical kind of person who would prefer to get work done rather than play psychologist, I'd rather not hire someone who has a bad attitude in the first place. I suppose this is why some companies make candidates take personality tests.

Big B
Friday, July 25, 2003

If they are experienced and competant programmers (in other respects) but can't do boolean logic, then just send them to a logic class.

Everyone runs into something that 90% of their colleagues "just get" but they have a hard time with.  Maybe their first teacher was bad and it poisoned them on the subject.  No amount of critisism is going to change them at that point.  However, a good class with a good teacher (maybe another programmer) can do that.  Just try real hard not to put them on the defensive.  "Mr Jack C. Greybeard, the boss says you must take Remedial Logic for Complete Idiots in 21 days at the local community college."

Richard Ponton
Friday, July 25, 2003

If programmer does not know boolean arithmetic, and can not fimd some slip of the pen in several second, i do not think that he is really good programmer.

Give him to find solution in problem with what he has never stuck, and count time how fast he will find it, that will show class of his knowledge. He has not know how to write standart function, he has to know where take them if he need it fast, and what he can use fron standart list of functions and what has to write by himself.

Also try to ask some unusual but general things, like how to make file delete by itself, or ask him to create about 3 - 8 algorithm of sort by abc (depend on level of knowledge you are finding programmer), for  example i can make 5 without any thinking about it, i need time only for type them.

About working in time, i think that programmer in his bone is alone, and best of all to have project manager who will divide work among programmers and then gether all together.

Valentin Semak
Saturday, July 26, 2003

ndrew Hurst:
>If they don't understand boolean logic on a fundamental >level, then I don't see how you can be a good >programmer.  But I fully expect even the best >programmers to make mistakes with boolean logic every once in a while.

I agree with you, if they need boolean logic. However, you should also make the distinction between making a "mistake" and simply not knowing. Granted, all good programmers make mistakes, but they're easy to fix once he or she catches it. What seperates a good from a bad programmer here is if he/she can actually find the boolean error!

Mickey Petersen
Saturday, July 26, 2003

>"If they are experienced and competant programmers (in other respects) but can't do boolean logic, then just send them to a logic class."

If somebody with years of experience doesn't know boolean logic, and they are applying for a job that requires it, it is a sign that they don't have the self-motivation to do what it takes to keep their skills up to standard for this profession.  They are the type who just knows exactly what they need to do on their current job and aren't interested in learning anything else on their own.

The bar has been raised for programmers.  Those who don't have the time or motivation to extend their knowledge beyond a current set of narrowly defined job requirements don't deserve the $55K-$80K salary that would normally be paid for their years of experience.

T. Norman
Saturday, July 26, 2003

This is utterly ridiculous. If someone does not understand boolean algebra they can not possibly be a programmer.

IF ((A AND B) OR C) THEN DO X

Even little old ladies who use search engines know this stuff!

To say that its OK if a programmer doesn't understand it, or taht he should be sent for some night clases to get clear on it, as if it is some obscure and rarely used part of the craft of programmig, is patently absurd.

Dennis Atkins
Saturday, July 26, 2003

I think the poster was referring to bitwise boolean algebra - like ANDing a byte with 128 to find out if the leftmost bit is 1 or 0.

T. Norman
Sunday, July 27, 2003

Ah... Ok. I can see that there would be certain areas one could work in without needing to know about bitwise operators.

Dennis Atkins
Sunday, July 27, 2003

Big B,

On the personality issue, I think it's impossible to know in advance. Look at the field of politics -- the most charming people get elected and then we are shocked to find out they are horrid people. :)

Dennis Atkins
Sunday, July 27, 2003

"Problems like these don't easily come out during an interview, where the candidate is trying to sell himself. Any ideas on how to reveal the dark side before it is too late?"

Not much chance ...
You'll need some real life observations of these people working to figure this out. Give them .5 year contract with the understanding that it can be extended. It is really hard to fully mask the true self for 6 months.

Mr Curiousity
Sunday, July 27, 2003

I don't think this is fool-proof but something I think works well in an interview is to work through a long'ish question step by step (like a database design, or a tricky code bug) and be really nice and reasonable throughout, then pick something that the interviewee says that is 'obviously' correct (my favourite is "Java is slower than C++") and then give them hell about it. I don't mean be rude, I mean be persistent and impossible and hard-headed. Most people eventually get a bit pissed off and then you can see what it would be like to work with them in real life. The key is that they be feeling really comfortable during the rest of the interview, so I save this for candidates who make the grade technically but I just feel a little iffy about their "works well in a team" skills.

I know this is really manipulative, but the best people I have ever hired stood their ground, got a little peeved at my being so unreasonable but didn't lose it. The guys who got condescending or rude I consider a no hire.

Astarte
Monday, July 28, 2003

Computers these days tend to be binary, and are often implemented using logic gates.

However, only a small percentage of business apps need to make decisions, and counting is really only a marketing gimmick.

I'd have to agree that boolean algebra and binary arithmetic are pretty niche skills.

Perhaps this could be useful differentiator in today's tough economic climate? Got any good links, where I can learn this stuff?

Andrew
Monday, July 28, 2003

Apparently, among other things, you should read the company car thread, decide which side of the ethics fence you sit on and then ask potential employees to respond to that situation.

If they have a different answer, you have different ethical world views and they are likely a bad fit for your company...

Phibian
Monday, July 28, 2003

*  Recent Topics

*  Fog Creek Home