prompt> grep friend *
facade.h: friend class Design;
facade.h: friend class DesignData;
facade.h: friend class FacadeData;
facade.h: friend class Facade;
facade.h: friend class BrickData;
facade.h: friend class Brick;
facade.h: friend class Saver;
facade.h: friend class BrickData;
facade.h: friend class Design;
facade.h: friend class DesignData;
facade.h: friend class Facade;
facade.h: friend class ParameterData;
facade.h: friend class FileIO2;
facade.h: friend class Saver;
facade.h: friend class Loader;
facade.h: friend class UpdateParameterEvent;
facade.h: friend class ColorParameter;
facade.h: friend class FloatParameter;
facade.h: friend class InfileParameter;
facade.h: friend class IntegerParameter;
facade.h: friend class ItemParameter;
facade.h: friend class StringParameter;
intern.h: friend class BrickData;
intern.h: friend class BrickData;
intern.h: friend class BrickData;
intern.h: friend class BrickData;
intern.h: friend class BrickData;
intern.h: friend class BrickData;
intern.h: friend class BrickData;
parameter.h: friend class Brick;
parameter.h: friend class BrickData;
parameter.h: friend class Saver;
parameter.h: friend class ParamToXML;
parameter.h: friend class XMLToParam;
parameter.h: friend class ParamDecode;
parameter.h: friend class Design;
parameter.h: friend class ParameterData;
parameter.h: friend class Brick;
parameter.h: friend class BrickData;
parameter.h: friend class XMLToParam;
parameter.h: friend class ParamDecode;
parameter.h: friend class FloatParameterData;
parameter.h: friend class Brick;
parameter.h: friend class BrickData;
parameter.h: friend class XMLToParam;
parameter.h: friend class ParamDecode;
parameter.h: friend class IntegerParameterData;
parameter.h: friend class Brick;
parameter.h: friend class BrickData;
parameter.h: friend class XMLToParam;
parameter.h: friend class ParamDecode;
parameter.h: friend class ParamEncode;
parameter.h: friend class ItemParameterData;
parameter.h: friend class Brick;
parameter.h: friend class BrickData;
parameter.h: friend class XMLToParam;
parameter.h: friend class ParamDecode;
parameter.h: friend class ColorParameterData;
parameter.h: friend class Brick;
parameter.h: friend class BrickData;
parameter.h: friend class XMLToParam;
parameter.h: friend class ParamDecode;
parameter.h: friend class InfileParameterData;
parameter.h: friend class Brick;
parameter.h: friend class BrickData;
parameter.h: friend class XMLToParam;
parameter.h: friend class ParamDecode;
parameter.h: friend class StringParameterData;
prompt>

People have different skills, some has good understanding of the language, others are architects, others has collaboration skills, and yet other are multitalented. Tests for a specific thing may rule out good people.

If you expecting candidates to be experts on aspects of a language that they never use, then you’re looking for people who spend a lot of their research time on things that aren’t usually valuable and you can expect them to spend their programming time the same way.

I’d like to toss in another bit about trick questions. There are many things that are called “trick questions”, including those for which there are no right answer (e.g. “what’s your worst trait?”). I think that what he’s talking about are the questions for which the answer is either completely non-intuitive, or for which the intuitive answer is the wrong one.

Of the three, the first is somewhat useful because it can tell you how many interviews the person’s been through. If they have good answers for numerous of that type, then they’ve been doing a lot of interviewing. Not that this is meaningful, but it does tell you something. Also, you get the occasional idiot that lets slip that they have their dead mother in their basement.

The second type is sometimes useful to see how people approach a difficult or insoluable problem, or again to see if they interview a lot or regularly read Mensa magazines. Lots of time for little benefit, as the author says.

The third type should always be avoided because they’re usually presented as a way of allowing the interviewer to seem smarter than the interviewee. While we’re at it, any problem presented to the interviewee is bad if it’s geared towards making them look or feel stupid. You don’t want to create a combative relationship with all of your employees before they get in the door.

Good job, Doolwind.

Thanks again for your thoughts. You don’t need to concede your points though .

I really like to have someone explain the way they are solving a problem, and I enjoy doing it just for myself. It can be quite interesting to see how different approaches can come to the same conclusion/code.

“I’ll probably be given a task, complete it, and report about how things were done.”

That’s actually a really good idea. I think that reporting how tasks were completed to other members (particularly senior ones) is a good way of making sure the problems are solved in their most optimal way. This also encourages the seniors to share some of their knowledge if they’ve solved the same problem slightly differently.

#1 – Marking things as friend is sorta important, our libraries would expose a lot of functions then. As a matter of fact, C# even the notion of Friend Assemblies (which is fantastic for writing Unit tests).

But, as you’re basing this post of your experience, we’re just going to be arguing in circles so I’ll concede the point.

#6 – In terms of this, some of my interviews had lengthy exams. But few of them actually had me explain my answers. Explaining what I wrote imo is a great interview approach, because it mirrors how I’ll be coding at work. I’ll probably be given a task, complete it, and report about how things were done. But once again, this can vary greatly from job to job, so I’ll concede this as well.

Thanks for you thoughts.

#1 – I’d like to be proven incorrect on this. It just seems strange that most people I know haven’t used friends before. If you do use friends, are they one of the most important things you use? If not, would it be better to use a different subject to focus questions on?

#2 – I totally agree that you need programmers to understand code, and that they shouldn’t always rely on the compiler. Having said that, I don’t think that making a programmer sift through 10-50 lines of code to find an error is the best way to find out if they are a good programmer.

#6 – The main point here is that it’s far easier to figure out thought processes in an interview rather than simply what their answer is to a test. You can certainly make assumptions about their thought process based on an answer, however trying to gain too much insight into this through a test can be an issue.

I don’t disagree with your point, just your example

#2 I do disagree with, especially for projects which have massive build times…like 20+ minutes, then its great to have coders that know what compiling code looks like But yea, the trick questions / trivia about the language is usually worthless, but it can indicate how much time the canidate has put into learning the language.

#3,4,5 I think its a great points, especially #4 thanks for the tip!

#6 – That’s what the test is supposed to show anyways right? How the candidate thinks, and I think your suggestions of using a white-board and having the canidate think out loud are spot on.

Nice post!