:fa_child: :fa_long_arrow_right: :fa_male: :fa_long_arrow_right: :toilet: I had so much hope for this candidate
-
only tangentially time related, in that the hands of an analog clock are a ubiquitous example of an angular system
But the values that get passed in are wall time values. That means dealing effectively with all the crufty 12 hour vs 24 hour historical baggage.
Tangentially is quite enough to screw things up if you're not watching out for it.
-
For an actual time and/or date problem, I would hope the candidate would ask what language and/or library functions are available.
I'm more interested in whether the candidate is capable of thinking flexibly enough to understand the problem domain.
Best time-related interview question I know: Can you give me an example of a circumstance where immediately converting a user-supplied date and time from local time to UTC, and then storing only the UTC value, is the wrong thing to do?
-
Situations where the relevant government changes timezone laws between the setting of the event and its occurrence?
-
Best time-related interview question I know: Can you give me an example of a circumstance where immediately converting a user-supplied date and time from local time to UTC, and then storing only the UTC value, is the wrong thing to do?
Now that is an evil question.
-
A timestamp that changes depending on the local time zone? Such as the moment when to light the next new year's fireworks, or the midnight to celebrate your next birthday.
Anyways, I guess the aim of such a question is not only to get an answer but also to test what kind of reasoning the candidate can come up with spontaneously?
-
Best time-related interview question I know: Can you give me an example of a circumstance where immediately converting a user-supplied date and time from local time to UTC, and then storing only the UTC value, is the wrong thing to do?
F-Spot Considered Harmful
There is a good possibility that every photo you’ve imported to F-Spot has had its EXIF date tags altered without your permission and without F-Spot informing you that it has done so.
Guess what happened to some of my photos.
-
That's a bit different, because the fields don't have time zone information. Although I guess "when you don't know for certain what the local time is" would be one good example of when not to convert to UTC.
-
I'm genuinely trying to get an understanding of the interview process and I figured that a thread about interviews might be a good place to do that.
The trick is to not treat it as an interview process but as a chat between co-workers. It's just that the two of you know that if either of you say too much stupid stuff the other will probably not want to meet again. Your
exp()solution would probably get a good laugh and then you'd have to talk about how it fails. A clever question (srsly
no *) is bound to elicit clever answers (hurr I justexp()), and one of the important things is realizing when you're being too clever.
-
I would consider any solution that can be written in under an hour to be trivial. Outside of any specialized knowledge, of course, but the number of degrees in a circle should be common knowledge.
Hm, must be a difference of the types of problems we work on. Trivial to me is that I know the answer by the time I'm done reading or hearing the question; the only thing left is time for implementation, which is basically just typing time.
I think I was sidetracked because I have worked with radians so much, particularly recently with geocoding. I was just way overthinking it. As soon as I realized that it went very quickly.
-
If 12 is in hours per revolution and scale is in degrees per revolution (as it appears to be given the numbers passed in) then unitAngularHour is in units of hours per degree. You then multiply that by a number of hours, which yields a result in hours squared per degree, which is wrong.
When writing this kind of thing I like to build the unit names into the variable names, making it easy to check that the calculations make sense. So instead of unitAngularHour I'd have used anglePerHour which would have made it instantly apparent that the associated calculation should have been scale / 12 rather than 12 / scale.
facepalm OK, now that is an embarrassing mistake on my part. I was sort of throwing it together quickly, but I really should have noticed that. Good call on the naming convention part, too, that's good advice.
The logic around greater and lesser is dubious as well; it's just a circuitous way to calculate Math.Abs(thetaHour - thetaMinute). This doesn't calculate the angle between the hands; it just makes the reported angle positive, meaning that it will be relative to whichever hand is further around the clockface. For example, at 11:00 it would return 330° rather than the 30° you presumably intended it to.
Nice analysis. OK, I spaced on using the absolute value function, and also missed the fact that the absolute angle would not necessarily be the clockwise directional angle.As for it being time related, well, yes and no; it strikes me that the use of the clock face (rather than a more abstract sort of modular mathematics) was mostly for familiarity's sake. Still, it does drive home the point about my sloppiness here in not reviewing all possibly relevant edge cases and criteria.
-
I felt like it'd be better to have it consistently return a value that included as much information as possible, and absolute value removes information.
Once you have the angle, you can easily get its absolute value if you don't care about direction, or calculate the smaller/larger angle if you need it simply by subtracting the given angle from 360 degrees.
-
the use of the clock face (rather than a more abstract sort of modular mathematics) was mostly for familiarity's sake
That's actually most of the trouble with time-related code. It's really really good at posing sneakily as something completely familiar, and familiarity breeds contempt. Use of the word "trivial" to describe anything even tangentially related to dates and times is a design smell.
Writing buggy time-related code is like playing chess with a ten-year-old and getting beaten up because you didn't think you actually needed to be on your game.
-
I'd say the guy got pretty confused with the math, but I was a bit confused while thinking about a solution too. It took me a while to accept that the angle was directly proportional to the time, instead of something with sine, cosine and tangents.
It's a simple problem, but not something I would be able to answer quickly if someone asked in an interview.
-
It's a simple problem
Stuff to do with time is full of problems that are 90% simple and 10% evil bastardry. There are just so many tricky nuances, and so many people get it wrong in ways that don't show up until the code hits production.
-
Stuff to do with time is full of problems that are 90% simple and 10% evil bastardry
...often posing as each other.
-
You usually have a mix of the two in the same problem.
-
Best time-related interview question I know: Can you give me an example of a circumstance where immediately converting a user-supplied date and time from local time to UTC, and then storing only the UTC value, is the wrong thing to do?
Really easy answer:
When you're setting the time on the system clock because the operating system expects it to be in the local time zone.
-
It took me a while to accept that the angle was directly proportional to the time, instead of something with sine, cosine and tangents.
...what.
I'd expect sine and cosine if I'm converting from polar coordinates to cartesian coordinates, but getting an angle from a couple of hands that move at constant angular speeds shouldn't involve any of that trickery.
Anyway, the OP did say that he wanted a candidate who had a pretty good grasp on geometry, so if your geometry is really rusty then you probably wouldn't have been his ideal candidate unless you brushed up on it first.
-
http://daniel-bartholomew.com/wordpress/2009/10/f-spot-considered-harmful/
Well, I will never use f-spot because it is written in C#.
Yes. That's a reason not to use something...
-
Yes. That's a reason not to use something...
The post author (as opposed to the commenter you quoted) has a more rational view:
I attribute the error solely to the F-Spot developers. There are too many silly conspiracies going around about Mono and C#. I don’t want to add to them.
...but I can also remember at the time being worried about the same thing*. Except I looked into it and got over it, rather than simply avoiding everything C# related because of a conspiracy theory.
*: I think it was something like "Microsoft is only doing this as part of it's Embrace, Extend, and Extinguish strategy. They're going to get people using it via Mono (terrible name) and then pull the rug out by suing them with the backing patents, thus forcing said developers to sell out to Microsoft, pay up in a settlement, or otherwise hobble them or steal their work." Of course, it originally sounded a bit more persuasive than I put it.
-
-
