Puzzles in iterviews fall into two categories: "logical puzzles"(like the one you were asked) and "think differently" category. The think differently category(I not sure are they also called lateral puzzles?) are usually this type: How many leaves are there in that tree? or How many tailors are present in your city.

I am fine with "Logical puzzles" becuase they have one or mayby two solutions at most and can be arrive at by straightforward logic. And I believe that logical puzzles are good to an extent because the process needed to solve them is very much the way a coder needs to think in real life.

The "think differently" kind bugs me no end because they force you to make assumptions, and then, make some calculations based on the assumptions. Simply put, if your interviewer agree with your logic but not with your assumptions, or vice-versa  , you've lost. There is too much room for the interviewer to disagree with your solution.

When I take interviews I dont ask logical puzzles. Reason: Most candidates even those with 3-4 years of experience  , fail or give up when I ask them to code simple textbook problems such as Fibonacci series or palindromes.

The problem with puzzles, either way is that the not-so-good programmers know that just by looking up solutions to such common puzzles on the net they can inpress interviewers. Very few people will be honest enough to tell that they already know the solution.

Puzzles in interviews fall into two categories: "logical puzzles"  (like the one you were asked) and "think differently" category. The think differently category  (I not sure are they also called lateral puzzles?) are usually this type: How many leaves are there in that tree? or How many tailors are present in your city?

I am fine with "Logical puzzles" because they have one or maybe two solutions at most and can be arrive at by straightforward logic. And I believe that logical puzzles are good to an extent because the process needed to solve them is very much the way a coder needs to think in real life.

The "think differently" kind bugs me no end because they force you to make assumptions, and then, make some calculations based on the assumptions. Simply put, if your interviewer agrees with your logic but not with your assumptions, or vice-versa, you've lost. There is too much room for the interviewer to disagree with your solution.

When I take interviews I don't ask logical puzzles. Reason: Most candidates even those with 3-4 years of experience, fail or give up when I ask them to code simple textbook problems such as Fibonacci series or palindromes.

The problem with puzzles, either way is that the not-so-good programmers know that just by looking up solutions to such common puzzles on the net they can impress interviewers. Very few people will be honest enough to tell that they already know the solution.

Puzzles in iterviews fall into two categories: "logical puzzles"(like the one you were asked) and "think differently" category. The think differently category(I not sure but I guess thy are also called lateral puzzles?) are usually this type: How many leaves are there in that tree? or How many tailors are present in your city.

I am fine with "Logical puzzles" becuase they have one or mayby two solutions at most and can be arrive at by straightforward logic. The "think differently" kind bugs me no end because they force you to make assumptions before you make some calculations based on the assumptions. Simply put, if your interviewer agree with your logic but not with your assumptions, or vice-versa , you've lost. There is too much room for the interviewer to disagree with your solution.

When I take interviews I dont ask logical puzzles. Reason: Most candidates even those with 3-4 years of experience , fail or give up when I ask them to code simple textbook problems such as Fibonacci series or palindromes.

Puzzles in iterviews fall into two categories: "logical puzzles"(like the one you were asked) and "think differently" category. The think differently category(I not sure are they also called lateral puzzles?) are usually this type: How many leaves are there in that tree? or How many tailors are present in your city.

I am fine with "Logical puzzles" becuase they have one or mayby two solutions at most and can be arrive at by straightforward logic. And I believe that logical puzzles are good to an extent because the process needed to solve them is very much the way a coder needs to think in real life. 

The "think differently" kind bugs me no end because they force you to make assumptions, and then, make some calculations based on the assumptions. Simply put, if your interviewer agree with your logic but not with your assumptions, or vice-versa , you've lost. There is too much room for the interviewer to disagree with your solution.

When I take interviews I dont ask logical puzzles. Reason: Most candidates even those with 3-4 years of experience , fail or give up when I ask them to code simple textbook problems such as Fibonacci series or palindromes.

The problem with puzzles, either way is that the not-so-good programmers know that just by looking up solutions to such common puzzles on the net they can inpress interviewers. Very few people will be honest enough to tell that they already know the solution.