Bits of Bytes

The 'intelligent question-intelligent answer' syndrome

2011-02-06T01:54:00.000-05:00

Recently, I had the chance to read an interesting piece of information. It was about an actual question asked in an interview for a project manager in a IT company and how prospective candidates answered. The following is the question.

You are the manager/lead of a team. Management wants to promote your top performer and move him/her to another position in another department. You have two top performers who are equals in all respects. Whom do you pick and why?

The following are the actual responses.

1. How am I going to manage my project if I am one member short?
2. I will ask for both of them to be promoted by dividing the budget.
3. I don't want to lose my best performers. So, may be release some other member by projecting him/her as the best performer.
4. Promote one of them to your position, release the other for the open position and ask for a promotion for yourself.
5. If the open position is lucrative, present myself for it.
6. I will flip a coin and decide.

First of all, this is a typical example of what I call the 'intelligent question-intelligent answer' syndrome. The interviewer asks a question which s/he thinks is an intelligent question because the candidate is forced to choose between two identical options. The candidate should further defend the decision and the interviewer will be ready to challenge the choice either way. The candidate on the other hand assumes it to be an intelligent question and tries to provide an intelligent answer. The answers listed above are the result of such pursuit. There are a lot of such 'intelligent' questions which are being asked in interviews nowadays which are irrelevant and misleading.

Let's try and understand the issues with these answers.

1. How am I going to manage my project if I am one member short?
- This is in no way related to the problem statement. It can be assumed that if the management asks you to release a team member, they are ready to supply a replacement. So this answer is so way off and doesn't provide your choice between the two team members.
2. I will ask for both of them to be promoted by dividing the budget.
- This answer looks completely amateurish. If the manager takes decisions like this, all the employees in the company will end up as managers in no time. Moreover, this answer also doesn't provide a solution to the question.
3. I don't want to lose my best performers. So, may be release some other member by projecting him/her as the best performer.
- This possibly is the worst answer a candidate could give. If this was the decision the manager would take in an actual situation, it clearly indicates that he is not afraid to create obstacles in the growth of his team members. It also implies that the team member is being denied an opportunity just because they performed very well. This would be the ultimate team spirit killer. We don't want this manager anywhere near the team.
4. Promote one of them to your position, release the other for the open position and ask for a promotion for yourself.
- This is typical example of the candidate trying to provide an intelligent answer and thereby missing the point entirely. This answer creates more problems then it solves because the management is forced to provide three promotions in the place of one which is absolutely unnecessary.
5. If the open position is lucrative, present myself for it.
- This is an answer which can be interpreted either way. On one hand, it seems to be an intelligent answer but some would argue that it seems unethical and it isn't unfair on the manager's part to grab a team member's opportunity.
6. I will flip a coin and decide.
- I would agree that this is the best answer if the answer is said in a sarcastic way. If this was a serious reply, this could be the stupidest answer for this stupidest question.

Now, let's try to answer this question in a 'non-intelligent' and simple way. Remove all the unnecessary distractions from the equation. The problem before us is that there is an open position in the company which has to be filled with the best possible candidate. Now, what do I have to do with any of this as a manager? What if my two best team members are not interested in the open position. The position has to be advertised to everybody who is interested and the best candidate picked after interviews. And a true talented manager should never have issues with losing a team member. Managers have to understand that anybody can be replaced in a team including themselves. It just takes a little time and effort to train a new member to take up the tasks of the previous member. And, in no circumstance, the manager should stand in between team members and their opportunities.

What is the color of the bear? Seriously?

2010-11-14T13:19:00.001-05:00

I remember a time when I felt frustrated when asked to solve puzzles in technical interviews. I simply didn't understand how solving puzzles can showcase my technical knowledge. Moreover, I didn't see any connection between puzzles and the daily work I am about to do in my role as a software developer. But as I gained experience through the years in various roles, I came to understand how puzzles relate to software development. A developer should be able to pick the most efficient solution for a problem, deduce constraints in a requirement, and read between the lines and foresee hidden issues. A developer who is able to do this will be able to deliver the best possible software. The same traits are required to solve a puzzle.

But, puzzles have to be used only for appropriate roles. For instance, it may not be relevant for software mainteance support jobs. It is more relevant for people who start afresh in a software job. I personally feel that puzzles have to be a part of the interview for Architects and Project Managers as well. After all they are the people who run the show and I guess they will have to able to think out of the box to be effective.

Here are some of my favorite puzzles which I came across in some of my interviews.

1. A man starts walking south from his house for 1 mile. He then walks 1 mile east. He sees a bear there and shoots it. He turns and starts walking north for a mile and reaches his house. What is the color of the bear which he shot?

I absolutely love this puzzle because it is simple, straightforward and absolutely mind blowing. The first time I heard this puzzle, I thought it was a ridiculous question to ask in an interview. Without even thinking, I said "Seriously?". The interviewer said "Yes, seriously", as though he was expecting me to say this. Then I calmed down, and started thinking. I just imagined myself as the man in the puzzle and started acting out every statement in the puzzle, in my mind. Then it struck me. Where on earth can somebody start from a place (point A) walk south for a mile (point B), and then east for a mile (point C), and then north to reach the same spot where they started. So if you use a compass in point B and C, its north should always point to point A. Which is the place which is north to any spot on earth? Obviously the north pole. The only bear which lives in north pole is the polar bear which is white. The color of the bear which he shot was white! Simple yet fascinating.

2. I enjoyed the following puzzle very much because it is very unique since it actually gives you the answer and asks you to provide the procedure to arrive at the solution.

There are 8 balls out of which 1 is defective (it weighs less than the other 7). You will have to find the defective ball given a scale.

When I heard the interviewer say this, I was wondering why do they even call this a puzzle. It was straightforward. You weigh 4 balls on each side of the scale first to find which set contains the defective one. Then weigh 2 balls each from the defective lot to further narrow down to the last two possible balls. Then the next weighing will find the defective ball.

Then the interviewer told me that I will have to find the defective ball in just two rounds of weighings. Now, I was stumped. At once I realised that weighing 4 balls on each scale is not going to work. But I was not able to come up with the correct combination in the 60 seconds given to answer the puzzle. The solution is to weigh 3 balls in each scale with 2 balls in your hand. Now if the scales are equal, then you can weigh the 2 balls in your hand and find the defective ball in 2 weighings. If the scales are not equal, take 1 ball from the defective set into your hand and weigh the other two. If the scales are equal, the ball in your hand is defective. Either way, you arrive at the solution in two weighings.

3. I liked this puzzle because it reminds you to apply all possible solutions to find the best possible answer because jumping into conclusions.

You will have to supply a mathematical notation for the blank in between the following numbers which when evaluated will result in a number greater than 4 and less than 9.

4 _ 9

Addition, subtraction etc don't work. They always result in a number which falls outside 4 and 9. The simple answer to a decimal point.

4.9. It is greater than 4 and less than 9.

10X10 and 11X9 - Always learn by example

2010-11-14T10:02:00.001-05:00

Recently, I had a chance to read the book 'Sink or Float? Thought Problems in Math & Physics' by Keith Kendig. As the author puts it, this book is actually a collection of examples in the guise of problems. The author says that we generally do not try to experiment and explore what we learn. The best way to fully understand what we learn is to learn by examples.

He starts the book with an interesting incident. His dentist asks him why he was attracted to Maths. He asks the doctor to multiply 10 and 10. "100" comes the answer. Now Kendig asks the doctor to add and subtract 1 to change 10x10 as 11x9. Now the answer is 99, one less than the previous answer. He asks the doctor to do that with 8. 8x8 is 64 and 9x7 is 63. Again one less than 64. The doctor is surprised and asks if this will hold good for any number. Kendig replies that this will work every time and even for small numbers. The doctor then tries it for 1x1 and 2x0. The answers 1 and 0 fascinates him. Again it works!

Then Kendig explains how this trick is derived from the following formula which almost everyone knows.

                      2      2
(x+a) (x-a) = x   - a

Most of us would recognize the formula with 'a' substituted with 1.

                      2      2
(x+1) (x-1) = x   - 1

Now, the trick which we discussed above is performed by replacing 'x' with any number. So when you add and subtract 1 to make it (x+1)(x-1), it is always going to return 1 less than the product of 'x' squared. This is a classic example of how experimenting with examples provide a lot of important information which is hidden below the surface.

The million dollar question, in a java interview.

2010-11-07T01:46:00.001-04:00

It is generally agreed that interviewers make a decision, whether to hire a candidate or not, in the first 30 seconds or so of the interview. It is called Thin-Slicing. Everybody in the Java world will agree that if there is one question which is asked in every interview - developer to architect, is how and when to use Abstract classes and Interfaces. Most of the time, it is the first question which the candidate faces in the interview. If we factor in Thin-Slicing, it becomes the million dollar question because the way the candidate answers it may very well decide the result of the interview. And guess what, most of the candidates fumble with the answer regardless of their expertise level.

Even though this is one of the most basic questions when it comes to Java or Object oriented programming for that matter, for some reason people don't find it easy to explain or give proper examples for this question. First of all, this question is asked to check whether the candidate understands the concept, and have them explain how they have used it to develop real time applications. Almost 9 out 10 candidates just come out with the definition of Abstract classes and Interfaces as the answer. I have tried to come up with a simple explanation and an example which may be of help to those candidates who just can't find the right words to answer this question.

First, let's define them.

Abstract Class - As the name suggests, this is an abstract template of a data type. It is a collection of attributes (java properties) and behaviour (java methods) which is common among a family of subclasses. The precise java definition is that it is a class which cannot be instantiated and defers the implementation of some/or none of its methods to its subclasses. It is good to know that classes can be declared abstract even if the do not have abstract methods.

Interfaces - Again, as the name suggests, this is an interface or a contract between the caller and the program which provides the implementation logic. The java definition of an interface is that it is the set of all permissible operations on an instance of a class.

Now lets talk about some examples.

Abstract Class - We all know that object oriented programming is all about code reuse. Abstract classes provide an important way to represent the real world and at the same time reuse code to a great extend. Let's take an example. We see/use/speak about cars almost every day. A car has four wheels, an engine, burns fuel and can move. The word 'Car' is an abstract definition of all the different cars which are out there. There are many makes and models of cars in the world but every car has four wheels, an engine, burns fuel and can move. While designing a system to represent this model, we create a class Car which is extended by a number of subclasses - Ford, Chevy, Honda, Toyota, Tata etc. The class car can have attributes (wheels, engine, fuel type) and behaviour (methods start(), move(), brake(), stop()) which can be inherited by all the subclasses as part of code reuse. Now this is what happens in real world as well. But we see a Honda or a Toyota in our daily life, but you don't see just a car which is of no make or model. Therefore we understand that abstract entities do not exist in the real world. And that's why abstract classes cannot be instantiated. They are meant to be used to define a family of subclasses and provide them with a common identity, an abstract identity. It will be very impressive if the candidate can provide a similar example from their projects with the requirement which prompted this design. Java's InputStream is a good example of abstract classes. It has many subclasses which inherit its behavior but it remains the super class of all input streams.

Interfaces - Interfaces are used to enforce a contract between two programs. The contract basically says that I will always do a particular job as long as you confirm to the rule we agreed upon. How does it relate to the real world? One of the most common interfaces we use in our daily life is the power socket on the walls of our home. We can plug in any device to the power source as long as it's power pins fit the socket. The power socket manufacturer would have never known what devices are going to be connected to it. Therefore it should have been designed on some common protocol which the socket will use to connect with the devices which use it. This common protocol is the contract/interface. So the power socket basically says that my interface is a three pin opening. Any device can connect to it and draw power as long as it has matching pins to insert into the socket. The device or the socket doesn't have to know what happens on the other side of their interface as long as they confirm to it. Java's Collection and JDBC frameworks have been built based on Interfaces. This can be used to bring home the point that the candidate understands how Interfaces are used in Java as well as how they have to be used in designing applications.

The "I have done it all" resume

2010-11-03T00:27:00.002-04:00

I have always thought interviews as a great learning experience for both the interviewer and the candidate. It proves to be the basis for one of the most important decisions the interview or the candidate may take in their career. It proves to be the window for both the parties to explore the other's world and base their decision on their experience.

I have had the opportunity to conduct numerous interviews for various software engineering positions. If there is one thing which stands out through out my interviewing experiences, it is the "I have done it all" resume. Almost everybody with experience ranging from 3 years onwards have a common statement in their resumes which goes 'Was involved in requirements gathering, analysis, design, coding, testing, implementation and support'. So, I generally ask them to tell me what they actually did during each of these phases. And, 2 out of 3 candidates don't have experience in atleast some of these tasks.

I wonder how so many people started to include this statement in every project they have in their resume. And for what? Does this statement really add anything of value to the resume? Do recruiters encourage candidates to include these tasks regardless of their experience? I had some candidates who had this statement even for the very first project they did. People who are familiar with the offshore software development model will know that it is next to impossible for a fresher to do requirements gathering. Even projects developed at the client's business location have dedicated business analysts to do the requirements gathering.

Even though this may seem too trivial an issue, I see these resumes as misleading and providing misinformation. Is this something recruiters and interviewers will have to ignore and just let go? Will people one day understand that these "I have done it all" statements do not and will never add any value to their resumes?

A Layman's guide to Object Oriented Programming concepts

2010-11-02T01:08:00.000-04:00

The following text is intended for people who are new to object oriented programming, and people who find it hard to understand where all the OOP concepts fit in the real world. This blog is different from other OOP sources because it does not define the OOP concepts. It is more of a briefing, may be an introduction to the OOP world. This is supposed to open your mind to the very concept of object oriented programming and thus helping you to understand the technical definition of these terms much better at a latter stage.

What is Object Oriented Programming? Before we answer this question, we must answer why we need it. OOP is just one of the many available methods to write programs. So, what makes it so attractive among the programmers? It is it's ability to represent the problem, which you are trying to solve, exactly as it exists in real world. So how will you be able represent the real world in your program? For that, the programming language should have the provision to represent the behavior and relationships of entities in the real world. Even though it seems that there could be an infinite list of rules which may be required to represent the real world, it is surprisingly only a hand full. They are Inheritance, Polymorphism, Abstraction and Encapsulation. Any program which incorporates these concepts to solve a problem is Object Oriented Programming.

Now, let's see what these rules really mean.

Inheritance - This is probably the easiest OOP concept which everybody understands. We see different kinds of this phenomenon in our everyday life. A child inheriting features and manners (lucky few inherit wealth as well) from its parent. A dog can run and bark. It has four legs and a tail. All types of dogs inherit these features. In the real world, entities have the ability to create copies of themselves with all their attributes. They are able to pass on their qualities to those who inherit from them. Inheritance provides the capability to represent this relationship in programming.

Polymorphism - This is the OOP concept which we almost use everyday without even being aware of it. For example my IPod can play music, video, display photos etc based on the file type. In the real world, the same entity can do different things based on different circumstances. Another variant of this feature is the fact that two entities may do the same job in different ways. For example, diesel and gas engines provide power for the vehicle but in different ways. Polymorphism provides the capability to represent this behavior in the programming language, to do different things at runtime based on different conditions.

Abstraction - We see, talk about, and perceive things differently based on different contexts in the real world. A chicken can be considered a bird, living thing or even food based on the context in which we speak. This ability to treat entities at an abstract level based on the context is prevalent in the real world. This remains the single most important difference between human beings and machines when it comes to interacting with the outside world. Human beings can attach different meanings to the same thing whereas it very difficult for a machine to make this distinction. So to represent real world entities, any object oriented programming language should support this feature.

Encapsulation - This is probably the hardest OOP concept to understand. Even though we see this in our daily life, it may take some time before we understand why this is needed and is so important. Encapsulation means hiding information and providing restricted access to something so that the overall state of the entity is preserved in a consistent state. For example, take the remote control we use for our TV. It has a power switch, can change channels and a volume control. The power switch is simply a single button which turns the TV on and off . Even though it looks so simple, there is a lot more being done inside when you switch on or off the TV. Some circuits are activated inside the remote and it sends a signal to the TV which decodes the signal and understands that it has to turn on/off. But the user is not allowed to touch the circuit to manipulate the remote into sending the on/off signal to the TV. The user is given a power button which has to be used whenever the TV has to be switched on/off. What is the benefit of this approach? Why can't they teach everybody how to activate the circuits and send a signal to the TV instead of pushing the power button. The simplest reason being that it is very easy to teach people to push buttons rather than to lecture them on electric/electronic circuits. Another important advantage here is that somebody cannot tamper with the circuit knowingly or unknowingly and render the remote useless. The company manufacturing the remote, certainly don't want to find themselves supporting thousands of customers complaining that their remote stopped working after they tried to play with its circuits. So there are some things which have to be provided to others only as a blackbox. The people handling it should not know what is inside and should just follow a set of simple rules to operate them. Most cases, the programming language isn't necessarily needed to be an object oriented programming language to support this. This is more a design consideration rather than the ability of the programming language.