Announcement

Wednesday, July 28, 2004

Body language of the Oraganization

The book 'Art of Innovation' has a interesting chapter on Body Language of Company. As you know verbal communication and communication from your Body Language can be different. Your posture and actions convey more about your thoughts than what you are speaking. In similar fashion, organizations also have Body Language the Verbal/Written communication from Organization may say 'employees are our most important asset' while the actions may give a totally different picture. If you are in the company for 4-5 years slowly you start missing these subtle communications. In this post, I am going to look at Body Language of the Company from the perspective of a candidate appearing for interview. Of course, I am no expert on Body Language, but these are what my interpretations will be.

Assume that you are appearing for a Interview in a Software Company. As the interviewer judges your body language and interest, you also have to judge the body language of the Organization. Ideally, the Organization should worry what its body language is saying to potential new hires. So in a way, this post is beneficial to both (hopefully).

This is what happens in a typical interview
  1. You appear at the company door, security guard checks your interview letter
  2. Security guard tells you to go to reception.
  3. At reception you again tell that you are here for interview and you are asked to sit in the lobby.
  4. The HR person arrives some time later and takes you to a room for some written tests
  5. After the written test is over, you sit in the room for some more time.
  6. HR person comes back and tells you if you are passed test or failed.
  7. If you passed the test, you again wait for some one to interview you.
  8. After the interview is over, you come out.
  9. If the interview is in another city, you find out a way to get back to station/bus stop etc.
Most of interviews are this way. Lets look how to observe the Body Language of Organization.
  1. How was your interview letter ? Did it had detailed instructions, maps etc on how to reach the office/place of interview ? Did the letter contains process of interview, approximate time it takes ? Does it say anything about transportation if the office is out of main city area ?
  2. How the Security guard treated you ? - Like a Person or a transaction.
  3. How the Receptionist treated you ? - Like a Person or a transaction.
  4. How was the atmosphere in lobby ? (e.g. Like a dentists office, Alive, throbbing, uninterested)
  5. Are there any books, magazines, news papers available in lobby ? Are there any technical magazines available ?
  6. How much time you have to wait in Lobby ?
  7. How much time you have to wait to hear the written test result ?
  8. How much time you have to wait for interview to start ?
  9. What are the questions asked in interview ? Is interviewer judging your knowledge of arcane language syntax, your memory for API names etc. ? Did they ask you to write code ?
  10. How was the furniture in waiting room ? (e.g. Fancy, comfortable, utilatarian, etc)
  11. Did company give you lunch in company canteen ?
  12. What was talk/discussion topics the during lunch on your and other tables ?
  13. Did company offer you any transportation to go back from office ?
  14. How are the cubicles ? Did you see any speakers, books, novels, soft toys, loved one photographs, in cubicles ?
  15. Did all the computers have same wallpaper and screen saver ?
  16. How much you spent in total compared to what was general time stated in interview letter ?
Each of this question is important. I will give my interpretations in next installment. Mean while feel free to add your experiences and your interpretations.

Monday, July 12, 2004

Implementing a Well behaved Singleton - 3

Last time I showed an singleton implementation where 'User has to manage the destruction of Singleton object'. (the part-2 is here). In this part, lets see how to improve on that.

class FooSingleton
{
public:
~FooSingleton(void);
static FooSingleton& GetFooObj(void);

private :
FooSingleton(void);
private :
int m_var;
};

FooSingleton&
FooSingleton::GetFooObj(void)
{
static FooSingleton fooObj;

return(fooObj);
}


If you compare the code from the Part 2 and this code, there are small difference.
1. GetFooObj function is now returning a Reference to FooSingleton and not a pointer. So chances of user, copying and deleting this pointer are less.
2. There is no global FooSingleton pointer. The GetFooObj function is now using a function static instance of FooSingleton (fooObj)


The result is
1. when fooObj is created on the first call to GetFooObj().
2. Every subsequent calls same instance is returned.
3. Since this is a static object, compiler manages the destruction of the object. User don't have to worry about destructing the singleton.
4. Singleton object creation sequence is now predictable. So if some other global/static object is dependent on existence of FooSingleton instance, GetFooObj() function will create it at appropriate time.


THIS IS GOOD. Most the problems with previous implementations are taken care off. However, the destruction sequence is still not predictable. And that is topic of next entry in the series.

Tuesday, July 06, 2004

From Ward Cunningham's interview : Simplicity in programming

Someone says, "You should always check your arguments to see if they're in range." Someone else says, "Half the statements in this program are checking arguments that are intrinsically in range." Have they made the program better or worse? No, I think they've made it worse. I'm not a fan of checking arguments. On the other hand, there ought to be a fail fast. If you make a mistake, the program ought to stop. So there is an art to knowing where things should be checked and making sure that the program fails fast if you make a mistake. That kind of choosing is part of the art of simplification.


Very true. Argument checks are difficult. Personally for low level utility function I prefer to use ASSERT macros to check arguments. They are there in Debug Version to track bugs faster and no performance penalty in Release version. It has happened many times that testing team reports a bug and I start the application in Debug mode. Out pops a 'assertion failure' message. Nearly Zero efforts to locate the cause of bug. In my experience time to find the location bug is usually large percentage of total bug fixing time. If I can reduce that time, then it greatly helps in reducing the total development time and improving the project code quality.

Also it has another benefit that if you wrote a module with asserts and other developer makes a mistake in using those functions, he will get assertion failure during the development/unit testing phase itself. As you know, a bug is detected and correct early, has low cost.