I'm not surprised with Singapore's kids being smart, but Albert and Bernard really impressed me :)
Here's a solver in python (just an hack, don't unleash hate on me).
import collections
dates = '''may 15 may 16 may 19
jun 17 jun 18
jul 14 jul 16
aug 14 aug 15 aug 17 '''
def dups(xs,pos):
return [k for k,v in collections.Counter(x[pos] for x in xs).items() if v>1]
days = dates.split()[1::2]
months = dates.split()[0::2]
dts = [(d,m) for d,m in zip(days, months)]
# A doesn't know, and knows B doesn't know-- cut days occurring once
dts = [dt for dt in dts if all(not(dt[0]==d or dt[1]==m)
for d,m in zip(days, months) if days.count(d)==1)]
# now B knows-- cut dup days
dts = [dt for dt in dts if dt[0] not in dups(dts,0)]
# A also knows-- cut months with more than 1 day
dts = [dt for dt in dts if dt[1] not in dups(dts,1)]
print dts
At least this article highlights how poorly worded that problem was.
Also, the article correctly points out that Olypiad questions don't necessarily say much about the quality of an education system: if you were to judge the Soutb African education aystem by our Maths Olympiads, you'd probably be quite (incorrectly) impressed.
That said, many private schools here do use "Singapore Maths", so it'd be interesting to see what sorts of problems regular students have to solve.
> At least this article highlights how poorly worded that problem was.
I spent three minutes trying to parse the question before I gave up and reverse engineered the question from the answer. I love logic problems, but the delivery on that one was horrible.
As others have said, this problem is straightforward if you know how to do it.
Here is how to do it.
There is a set of possible dates. Each statement eliminates some of them. Just get rid of all that you can get rid of at each step, and in the end there is just one.
Here is the original set of possible dates:
May 15 — May 16 — May 19
June 17 — June 18
July 14 — July 16
August 14 — August 15 — August 17
First Albert who knows the month says, "I don’t know when your birthday is, but I know Bernard doesn’t know, either." That means that every day in whatever month he heard must be in another month. From this we conclude:
- He can't have heard May because then Bernard could have heard "19" and the statement would be false.
- He can't have heard June because then Bernard could have heard "18" and the statement would be false.
- He might have heard July.
- He might have heard August.
We are now down to these dates:
July 14 — July 16
August 14 — August 15 — August 17
Enter the second statement. Bernard says, "I didn’t know originally, but now I do." That means that knowing the day of the month and knowing it is one of those two months tells him the birthday. This wouldn't happen if Bernard heard 14, but would for the other three. So we're down to:
July 16
August 15 — August 17
Enter the third statement. Albert says, "Well, now I know, too!" This would not be true if Albert had heard August, so by elimination the answer is:
How can Albert - from the fact that Bernard a) has knowledge of the day and b) eliminated May and June as valid options the month value - deduce the correct date himself? I.e. if Bernard was given the day 17, he still would known the correct date (August 17 in this case)
But Albert can't know that. From his point of view, even if Bernard knows the correct date, he still has three valid options to consider: July 16, August 15 and August 17.
Albert was told what month the birthday occurred in. We then learn from Albert that has has enough information to work out the birthday. Which means - he couldn't have been told August, since there were two possible solutions.
Bernard got to rule out two months based on Albert's information. Albert only had to rule out the 14th, which he did based on Bernard's being able to come to a conclusion.
People attempting the Singapore question fall into 2 main groups:
1. August 17: Those who (a) assume Albert made Statement 1 on the assumption that Bernard didn't receive a unique date and thus didn't speak up, or (b) simply eliminated May 19 & June 18 by reasoning forward (as opposed to backward) from Statement 1 alone[1] (a rather common mistake)
2. July 16: Those who don't make the assumption in 1(a) or the mistake in 1(b)
July 16 is the better answer because it doesn't involve making the assumption.
Two crucial skills to get to the answer are (1) keeping perspectives separate among Albert, Bernard & a 3rd-party observer, and (2) enumerating each possible month (i.e. evaluating each premise) and playing out the statements in each case. People who don't take these actions end up saying, "There are 3 dates left at the end - how can you be sure it's July 16?!" They question how Albert can possibly know the date, even though we have to assume he's correctly concluded it. This is a perspective error; one has to put oneself in Albert's shoes, assume a month, and reason from there to see which assumption matches the observed statements.
As a Singaporean, I wish our question-setters had better grammar in general; it's tripped up test-takers before. And it hurts students' language skills by reinforcing grammatical mistakes.
[1] They reason forwards that
"Albert says he knows Bernard doesn't know the date"
==> "Bernard doesn't know the date"
==> "The date isn't May 19 or June 18".
Instead, they should be reasoning backwards:
"Albert says he knows Bernard doesn't know the date"
==> "Albert must have concluded this because of the month he was told"
==> "Albert must have been told a month with a 0% chance of Bernard knowing,
i.e. a month with no unique dates".
--------------
By the way, this problem has floated around for a while. Here's a 2006 occurrence of it:
Date: 01/21/2006 at 00:43:08
From: Eddie
Subject: P -> Q <> ~Q -> ~P
A teacher told the month of her birthday (let's call it M) to Peter,
and the day of her birthday (let's call it D) to John.
Then, the teacher showed a set of dates, and asked Peter
and John which one was her birthday:
4 Mar, 5 Mar, 8 Mar
4 Jun, 7 Jun
1 Sep, 5 Sep
1 Dec, 2 Dec, 8 Dec
Peter said, "If I don't know the answer, John doesn't know, too."
John said, "At first I really didn't know, but now I know."
Peter said, "I know, too."
What is the teacher's birthday?
I don't like problems like this, for me it's just brute forcing: you first eliminate the dates that would have given Albert a chance to know Cheryl's birthday (the dates whose months have a unique day in the list), given that you eliminate the other dates that would allow Bernard to know the birthday, and finally you keep the date that allow Albert to know. It doesn't require any smart thinking at all.
And because it can't be May or June because then Albert would not have said that he knows Bernard doesn't know, because if Albert had May or June then Bernard may have had 19 or 18, and because those are unique, Bernard would have known the birthday. Albert saying Bernard doesn't know, therefore means Albert has July or August.
With him having 16, and 16 only being in July, and May, and Bernard knowing it's definitely not May (see above), it's July 16.
And we can find out that he has 16, from the statement after:
If Bernard had 14, then he could not have known the correct date, because it could have been July or August. So he could not have made statement 2.
If he had 15 or 17, then Albert would have 'August', but Albert could not know whether the date was the 15th or 17th of August. Thus he could not have made statement 3.
Only July 16th is compatible with all statements. And Bernard knows (as he has 16 from the start), as soon as May is out.
Slight correction, at the time that Bernard has determined the date, the set has been reduced to 5 options, which are the July and August dates. Since Bernard knows the day of the month is 16, and the only date in the remaining possibilities that is consistent with that information is July 16, he knows that must be the birthday.
From Albert's point of view, he only knows the month and that the list is limited to the three possible dates you mentioned before. But Albert also knows that the birthday occurs in July, and the only possible remaining date of the three that would allow Bernard to figure out the birthday that is consistent with Albert's knowledge of the month is July 16.
At that time, there are 5 possible month/day combinations. Bernard would know the full solution if it were the 15th, 16th, or 17th. He would not know if it were on the 14th. Because he does know, Albert is able to rule out the 14th.
Now if it were the 15th or the 17th Albert would not be able to reach a conclusion, but he does. So we are left with only the 16th.
The number of layers to this is more than it seems.
That is not true, Bernard does not know the birthday is in July. He knows it can't be in May or June, and he knows that the day of the month is the 16th. The only remaining option is July 16.
Eh I still dont understand how you can arrive at july 16. Albert knows the month and bernard knows the answer. How would the outside observer know for sure?
That is a terrible interview question. First, it's likely to make candidates more nervous, rather than set them at ease. Second, it tells you very little if they can't solve it, or if they solve it immediately.
My rule is that you should stay away from aha! type questions that really only tell you one bit of information.
Designing a program to solve this kind of problem might be more of an interesting conversation…
Logic questions are about as far from aha! as you can get. Next you'll be telling me that FizzBuzz is an aha! question. Sure, for some people it is, because they don't have a clue. Others are able to solve it systematically, and these are the candidates you're looking for.
The same holds for the logic puzzle in the OP. You can solve it step by step, without any leaps. The main difficulty is getting over the initial intellectual "flinch", and making yourself actually engage with the problem. IMO that's an important skill for developers to have.
I agree, although I probably wouldn't ask this in an interview just because of the risk of them seeing it before. At least when I was solving it it felt very much like debugging; you have a few snapshots of the variables and you have to reconstruct the whole logic flow.
I'm not sure that a good rule of interviewing is that you should only ask questions that put the candidate at ease. It's a job interview, not some soft-ball celebrity talk show interview. I don't think it's a bad idea to include a few tough questions. I agree it doesn't tell you as much if they solve it immediately. I think it might tell you something if they can't even get started on it.
How do you figure this to be an aha question? To me, It's a simple problem based on elimination of obviously incorrect answers. There is no "hidden information"/trick/leap of thought/insight that is required to solve it.
Not really, no. It's part of a whole class of similar puzzles, and they're easy to solve formulaically, so all it proves is that the candidate has done these puzzles before (which I don't personally find to be a good indicator for job aptitude). It's also the sort of thing that will make nervous candidates who haven't seen such a problem choke without giving you any indication as to their quality.
That also is why the GRE discontinued the old analytical puzzle section, which used to be 1/3 of the exam (along with math and verbal). The scores were bimodal: Those of us who'd done a lot of logic puzzles in school got perfect scores, and those who hadn't did much worse. It turned out not to be a good indicator of anything meaningful.
But do you want your new employee to choke as soon as they see a new problem? To me, being able to solve the problem doesn't reveal anything; however, how they handle the problem can. I think its about context and what information you're trying to glean.
By that logic you could have them do the problem under time constraints and constant interruptions, you wouldn't want a new employee that can't handle stress and distractions.
I realize you were trying for a reductio ad absudum, but actually I kinda like your idea, because it suggests a wide range of other promising ideas. Imagine a software company whose programmers were chosen for being immune to procrastination. They would run circles around competitors!
I recall reading that these sorts of problems were popular at one stage at places like Microsoft and Google for precisely that reason- they allegedly revealed problem solving abilities. They were subsequently dumped when it was found that they showed little correlation with job performance. I don't have the citations offhand, but I would probably personally be wary of working at s place that subjected me to brainteasers in an interview knowing that they were somewhat discredited already.
First variation is with the candidates ability to solve the problem. Like you said, Microsoft and Google seem to have determined there's no correlation between that and job performance.
Second variation is with a panel of interviewers who propose the problem. Based on how the candidate responds, the panel chooses whether to 'hire' the candidate, based on their ability to reason about the problem and communicate, rather than on their ability to solve it.
I wonder if there's a correlation between the yes/no of the interviewers and the candidate's job performance.
I showed it to a few friends and a few of them had zero interest. Some tried for 30 seconds, then asked for the answer. Another wanted a hint. One said "I don't get it". One gave the answer right away and it was wrong. And some didn't get it after a decent step-by-step explanation, or even weren't interested in the explanation.
That says a lot, I think, about a certain mentality of a person towards particular types of problems, challenges and learning opportunities.
But I say mostly no, because there are hundreds of questions like these. Once you do 2-3 (and if you're in certain circles, you most likely have), the 4th or 5th become very easy, if they are even different (and not just a copy/paste) of ones you've already done.
In short, I think the question can be meaningful sometimes, give false positives a LOT of times, and probably give some false negatives, too. (e.g. nervous people who can't think outside the box in an interview boilerroom which is an a-typical work environment in my experience).
So yeah, I wouldn't personally ever use this in an interview.
I can't stand logic problems like these. They take no creativity to solve. They are senseless. They are boring. And as IkmoIkmo said, as soon as you learn to solve one, you can learn to solve any of them.
I wonder if people see "Good interview question." and think that also was intended to mean "This is a good interview question that would work well consistently for a broad swath of candidates and should be given a high weight and/or be used exclusively to rule people out."
For those people, it might be beneficial to stop making such assumptions -- doing so seems to reflect a tendency to jump to conclusions.
There is lots of room for tough interview questions that only a percentage of people do well, provided that your interview as a whole does not skew too much towards any one question.
Personally -- and I don't need people to agree on this point -- I'd rather setup an interviewing process where people don't ace all the questions and that is considered ok. I'd rather see how far a candidate does across, say, 10 relatively deep, hard problems, even if they only do well in a few of them. In other words, I'd rather find out where a candidate excels rather than "average out" an interview so that "on average" candidates don't think it is too hard.
To sum up what I believe to be true: heterogeneity and diversity is good, both in your interviewing questions and your team. Don't be afraid to ask tough questions -- but if you do, think hard about how you evaluate the responses.
Two objections: Questions like this almost certainly do not reflect the work involved with the job you're interviewing for. Not many jobs involve sitting around solving abstract, standalone logic puzzles. Programming, for example, involves logical deduction, but in concert with a variety of other skills, and applied to software, not prose, as part of a complex development process. Maybe these type of hard questions exercise some of the same skills, but why not set tasks that involve exactly the same skills, e.g. programming assignments or some other problem taken directly from the role you're interviewing for.
Second, the circumstances in which you're asking candidates to solve these problems almost certainly do not reflect those in which they will be required to work should they get the job. Nervous anxiety, unfamiliarity, strong time pressure and intense outside observation are not conductive to good performance, and are (hopefully) not part of your everyday working environment, but all are present in an interview. So when you present difficult problems, you're not just selecting for people who can solve them, you're selecting for people who can solve them in conditions that will never otherwise arise.
I was able to solve the logic question in the linked article after about five minutes of head-scratching. But I am 99.9% certain that, in interview conditions, I would never have figured it out. I would have spent those five minutes of head-scratching fighting off a rising tide of panic. And the thing is, having had interviews and given interviews, I am not even particularly nervous during them, relatively speaking.
I disagree, I got it very quickly by writing the dates in order, crossing off all that were impossible after the first statement, then with those were left crossing off the ones that were impossible after the second, then there were three, with only one possible according to the third. Now what if I did not have a pad of paper handy when interviewing? All this question would do is predict if someone would enjoy a game such as Professor Layton more accurately than flipping a coin.
