Heres a quick funny (not so funny) question.....
I was taking a test for a job, and on this quiz, most of the stuff was total bs. Including the following question:
If a clock loses 9 minutes per hour, and is correct on Monday at noon, when will the next time it be correct?
They listed days ranging from Tuesday to Friday with various times - and heck - if you do the math, it turns out to be the next week on Monday at 4AM.
The solution:
The slower clock cannot *catch* the faster (correct) clock, so it's going to have to wait until it's *lapped* by the faster one.
The math:
24 hours in a day * 9 minutes lost per hour = 216 minutes
1440 minutes in a day / 216 minutes = 6.66667 or 6 2/3
Monday Noon + 6 days and 16 hours = Monday at 4AM.
And they did not list that answer. :rolleyes:
# 1 Re: Heres a quick funny (not so funny) question.....
And they did not list that answer
darn bastards... :D :p
cilu at 2007-11-9 12:59:18 >

# 2 Re: Heres a quick funny (not so funny) question.....
Hey cilu :wave: you are not supposed to be speaking out such words here...
I don't understand why a software engineer should know about *clocks*, I think this is total peice of utter crap designed just to get some thing out of you which is almost surely required to be known.
To be frank I really go haywire when I see such questions, however I am not able to find out how answering/not answering such questions should decide my career.
# 3 Re: Heres a quick funny (not so funny) question.....
Well, I think this kind of questions are good. They are not supposed to check your knowledge with a particular technology, but see how you can approach and solve a problem. That could be more important than some particular knowledge.
cilu at 2007-11-9 13:01:26 >

# 4 Re: Heres a quick funny (not so funny) question.....
Anyway, the OO solution in C++ is this:
enum PrecisionPerHour{Clock1 = 51, Clock2 = 60};
class IClock
{
const PrecisionPerHour precision_;
unsigned long time_;
unsigned long days_;
public:
IClock(PrecisionPerHour precision):precision_(precision), time_(0), days_(0){}
void Increment() {time_ += precision_; time_ %= 1440; if(time_ < (unsigned long)precision_) days_++;}
unsigned long GetTime() {return time_;}
unsigned long GetDays() {return days_;}
};
class FirstClock : public IClock
{
public:
FirstClock():IClock(Clock1){}
};
class SecondClock : public IClock
{
public:
SecondClock():IClock(Clock2){}
};
int _tmain(int argc, _TCHAR* argv[])
{
FirstClock c1;
SecondClock c2;
do
{
c1.Increment();
c2.Increment();
}while(c1.GetTime() != c2.GetTime());
std::cout << c1.GetDays() << ":" << c1.GetTime() / 60 << std::endl;
return 0;
}
Answer is: the clock shows the correct time again after 5 days and 16 hours.
cilu at 2007-11-9 13:02:20 >

# 5 Re: Heres a quick funny (not so funny) question.....
darn bastards... :D :pAmazing, amazing... :D :p
Till sometime back, I couldn't say hell, but I fought like hell for sake of DLL Hell!
Now, I cant say d@mn, but, I can say bastar*$.
I cant say f**k, but I can say ashole...
Godess of censorship, where art thou? :D
# 6 Re: Heres a quick funny (not so funny) question.....
And they did not list that answer.
AFAIK, an analog clock has no AM/PM indicator : And thus, a 12-hours shift is invisible.
Thus, the time will seem correct after 12*60/9==80 hours.
80 hours == 3 days + 8 hours.
Monday + 12 hours + 3 days + 8 hours == Thursday + 20 hours == Thursday at 8 hours PM.
# 7 Re: Heres a quick funny (not so funny) question.....
AFAIK, an analog clock has no AM/PM indicator : And thus, a 12-hours shift is invisible
Well, I don't see anything about an analog clock in the text of the problem. ;)
cilu at 2007-11-9 13:05:28 >

# 8 Re: Heres a quick funny (not so funny) question.....
Well, I don't see anything about an analog clock in the text of the problem.
A numeric clock shifting of 9 minutes per hour?
# 9 Re: Heres a quick funny (not so funny) question.....
LOL :) :thumb:
# 10 Re: Heres a quick funny (not so funny) question.....
Well, you should stick to the original story and not make free assumptions.
cilu at 2007-11-9 13:08:32 >
