# :fa_child: :fa_long_arrow_right: :fa_male: :fa_long_arrow_right: :toilet: I had so much hope for this candidate

• A while back we were looking for someone to join our dev team, at least mid-level. After sifting through the resumes and doing the initial screening, we were down to 4 candidates who seemed really bright. Out of the 4, two were shown to be all talk. This WTF is about the worst of the four.

He had done an alright job with the SQL and first, very simple, C# exercise, so we found it encouraging. Even if he fumbled a bit on the last test, we weren't too picky, since we had an existing group of well-rounded programmers and if he showed willingness to learn, we could strengthen his skills if he had a few weak points. We just didn't realize just how bad his skills would be.

The final exercise was simple enough: Write a function which takes a time of day and, given an analog clock, calculate the angle between the hour hand and the minute hand. This was relevant to our job, since we deal with a lot of geometry in our projects.

The question is vague on purpose. We want to see if the person asks questions (e.g. do you expect hour and minute parameters or a different format? Do seconds count? Do you want the result in degrees or radians? etc.). While at first one might be thinking such an exercise requires trigonometry functions and the like, after thinking about it for a moment, you realize it's really just a simple arithmetic exercise a middle schooler could figure out.

The candidate started out strong, at least asking a couple questions about it, and then he wanted to demonstrate his TDD approach by writing a unit test first.

``````[Theory]
public void ClockExercise()
{
var clock = new Clock();
var angle = clock.getAngle(12, 0);
Assert.equal(0, angle);
}
``````

Then he got to work on the implementation. We knew he wasn't going to get away with such a limited and degenerate test case, but we let him continue.

``````public class Clock
{
public float getAngle(int hour, int minute)
{
var result = hour * 12 / 360;
return result;
}
}
``````

...test fails. My boss and I look at eachother incredulously, but was willing to give him the benefit of the doubt. After all, he was showing signs of being a little nervous. He realizes he is not even accounting for minutes in his equation, so he adds it:

``````public class Clock
{
public float getAngle(int hour, int minute)
{
var result = hour + minute * 12 / 360 * 60;
return result;
}
}
``````

...umm, whut?

I can hear the lightbulb go in his head. "Oh... between!" he realizes. "That infers subtraction!"

``````public class Clock
{
public float getAngle(int hour, int minute)
{
var result = hour - minute * 12 / 360 * 60;
}
}
``````

He then sees that in his unit test the result is 12, when it's expecting 0...

``````public class Clock
{
public float getAngle(int hour, int minute)
{
var result = hour * 12 - minute * 60 / 360;
}
}
``````

This yielded 144. "Well, that's not good," he surmises. "I'm going AWAY from where I want to be."

Then he realized something. Clocks are 12 hours, while there are 24 hours in a day! He was going about this all wrong. If the hour were 12, then mathematically speaking, that's really the 0th hour on a 12 hour clock.

``````public class Clock
{
public float getAngle(int hour, int minute)
{
if (hour >= 12) {
return hour * 12 - minute * 60 / 360 - 12;
}
else {
return hour * 12 - minute * 60 / 360;
}
}
}
``````

Now the value is 132, getting closer...

``````public class Clock
{
public float getAngle(int hour, int minute)
{
if (hour >= 12) {
return hour - 12 * 12 - minute * 60 / 360);
}
else {
return hour * 12 - minute * 60 / 360;
}
}
}
``````

And the pendulum swings to -132.

``````public class Clock
{
public float getAngle(int hour, int minute)
{
if (hour >= 12) {
return (hour - 12) * 12 - minute * 60 / 360);
}
else {
return hour * 12 - minute * 60 / 360;
}
}
}
``````

And now the unit test passes. "There," he said satisfied with himself. "That was a tough one."

We said, "Alright, the test passes, but you only have one test in there. You should be seeing if other tests pass, like 6:00 should be 180 degrees, and so on."

He said, "You're right" and continued on.

``````[Theory]
public void ClockExercise()
{
var clock = new Clock();
var angle = clock.getAngle(12, 0);
Assert.equal(0, angle);
angle = clock.getAngle(4, 30);
Assert.equal(90, angle);
}
``````

That's not a typo. He is expecting 4:30 to be 90 degrees on an analog clock. He then fumbled with the code for another several minutes until he came up with the following equation:

``````public class Clock
{
public float getAngle(int hour, int minute)
{
if (hour >= 12) {
hour = hour - 12;
}
return (hour*12+minute*(60*hour)/180)+hour/2;
}
}
``````

This interestingly passed the unit test, and I could tell he felt quite proud of himself, saying that was a challenging problem, and one he hadn't seen before. We concluded the interview, and after he hung up all we could say to eachother was "Wow." I know I said in the beginning we were willing to accept someone who had some weak points in programming if they showed strength in other areas, but seeing that we had two much stronger candidates, and there were layers of WTFs in his failed solution, we turned him down.

• That is actually a really good question though. I doubt anyone would have rehearsed an answer to that or had one ready. It would give people some pause, and you'd get to really see their problem solving skills. Or lack thereof, like this candidate's.

• That is actually a really good question though. I doubt anyone would have rehearsed an answer to that or had one ready.

It's really simple though. Something I'd give as a 5-minute first-pass filter to a candidate, not something I'd make a proper task out of.

And of course, because it's not a programming task topic without an answer nobody wanted:

``````private static decimal GetAngle(DateTime timeOfDay)
{
var minutesAngle = ((decimal)timeOfDay.Minute / (decimal)60)*360;
var hoursBaseAngle = ((decimal)(timeOfDay.Hour % 12) / (decimal)12)*360;
var hoursWithMinuteAngle = hoursBaseAngle + ((decimal)timeOfDay.Minute/(decimal)60) * (360/12);
return Math.Abs(minutesAngle - hoursWithMinuteAngle);
}
``````

TODO refactor, but it does the job.

• That is actually a really good question though. I doubt anyone would have rehearsed an answer to that or had one ready.

It's pretty stock. I've seen it at 2 different companies, and asked it myself at least once.

It's a good question, but there's a reasonable chance the candidate has seen it before and an outside chance they've prepared an answer for it.

It's really simple though. Something I'd give as a 5-minute first-pass filter to a candidate, not something I'd make a proper task out of.

For my first-pass, I use:

"Write a function that takes two numbers and multiplies then, without using the multiplication operator (in your language of choice)"

Again the requirements are open-ended to prompt thoughtful questions (integer, floating point, or both?) and the solution is surprisingly tricky. There's a lot of error conditions that candidates almost inevitably miss.

• integer, floating point, or both?

Include complex numbers if you really want to have fun

• "Write a function that takes two numbers and multiplies then, without using the multiplication operator (in your language of choice)"

That is obviosly a super easy problem

``````#include <math.h>
template <typename T>
T multiplyWithoutOperator(T x, T y){
return exp( log( abs(x) )+log( abs(y) ) ) * (x<0 ^ y<0)?-1:1;
}
``````

• if you get the real numbers multiplication, doing it for complex numbers is simple

• C++ has standard library support for complex numbers, don't most decent languages support complex numbers in one form or another without having to set them up manually?

• Yes. But he wanted a solution without resorting to the built-in multiplication operator.

• Yeah, I'm not sure how those are mutually exclusive?

• ``````function angleBetween(h, m) {
return m % 60 * 6 - h % 12 * 30;
}
``````

...there. Angle in degrees, measured in the clockwise direction. Positive if the minute hand is further than the minute hand is (relative to 12:00), negative if the hour hand is past the minute hand (but 12 % 12 = 0, so if the hour hand is at 12 then it's not past the minute hand). If you want to get the absolute value from that, or the smaller/larger angle, well, that's just geometry, easy to do.

• `(a+b i) * (c+d i) = (a*c+b*d)+(a*d+b*c) i`

ITYM `(a+b i) * (c+d i) = (a*c-b*d)+(a*d+b*c) i`

• yeah, that.

• but 12 % 12 = 0, so if the hour hand is at 12 then it's not past the minute hand

If the hour hand is exactly at 12 then so is the minute hand and the angle is 0.

• Right, so it's 0 not 360 or -360.

Wait a minute... in hindsight, I forgot that the hour hand moves every minute... damn, I've been using digital clocks for too long. Hell, I've even written analog clock programs... I just forgot...

``````function angleBetween(h, m) {
return m % 60 * 6 - (h + m / 60) % 12 * 30;
}
``````

There, that should be better. `angleBetween(3, 30)` returns 75, not 90.

• You touched on another benefit of the exercise. There are little subtleties like that which gauge how well people pay attention to detail. A lot of them do well on the basic math part, but forget about the hour hand moving between hours depending on the minute.

Sadly, at some point we won't be able to really use this exercise after some of the people after the millenial generation start entering the workforce, since I bet some of them will not even know what an analog clock is, besides the hipster types who go for the trendy retro look or enjoy Flava Flav.

• One of my favorite brain-teasers goes "in 24 hours, how many times will the hands of an analog clock go in exactly the same direction" (or, in exact opposite directions).

• the hour hand moves every minute

Strictly, it moves every time the time regulation device (pendulum, spring, crystal) inside the clock allows it to advance. Some clocks that's every second, some less, some more.

• Right... but since the OP already gave that part away, I left it to just assume that the seconds are zero.

• More than the algorithm itself, I find more worrying that he wrote a getAngle function to accept two params on a Clock class. This does demonstrate his lack of OOP understanding. Also, the angle variable is not required on such an easy thing:

``````var clock = new Clock();
clock.setTime(12, 0);
Assert(clock.getAngle() == 0);

``````

• You're right, although given how we asked the question (we specifically asked for a function that takes a time of day as a parameter which then returns the angle) that part's totally forgivable, and is really a fail on our part in a sense. We were focused more on figuring out the equation itself rather than the OOP part anyways.

I think, given the wording of the question, it might be more prudent to make getAngle a static function, since by passing in the parameters you're not taking any consideration to the context of the clock object itself, but we weren't even thinking about that kind of stuff for the purpose of the question.

• One of my favorite brain-teasers goes "in 24 hours, how many times will the hands of an analog clock go in exactly the same direction" (or, in exact opposite directions).

All the time!

Wait, you didn't mean the angular momentum?

• No, he clearly meant linear momentum

[spoiler]double once you realize I'm telling the truth[/spoiler]

• "Write a function that takes two numbers and multiplies then, without using the multiplication operator (in your language of choice)"

What would you think of this?

`````` function multiply(a,b) {
return exp(log(a)+log(b))
}
``````

• It's not a trivia question.

• Strictly speaking, the hands don't go anywhere. I meant "point", obviously. How many times will they point in the same direction.

The point is the end furthest away from the pivot, in case that wasn't clear enough. It's usually (though not always) shaped like a point, and usually (though not always) points toward a series of increasing numbers near the clock's perimeter.

• While at first one might be thinking such an exercise requires trigonometry functions and the like, after thinking about it for a moment, you realize it's really just a simple arithmetic exercise a middle schooler could figure out.

I remember it's taught of Primary 3 Mathematics here, immediately follow the chapter on velocity.

You did once put this kind of question on "Maths. Week" quiz in my secondary school. Unfortunately very few people remember it.

• Without looking I would guess 48 but I suspect that is horribly wrong.

• Yep, horribly wrong.

• For the sake of simplicity, assume that if your 24-hour period started and ended with the hands pointing in the same direction, you only count one of those. Or you can just start and end at 6:00 to keep everything simple.

• I'm going for what I think must be the wrong answer: 24... but I can't think of any reason why it would be anything else... unless the trick part is I'm forgetting the seconds hand or something... although, even then, the answer would be the same, wouldn't it?

• Here, let's see who can answer this interview question.

• Nope, but that's the answer that most people guess, so you're in good company at least.

The seconds hand isn't the secret, either.

• One of my favorite brain-teasers goes "in 24 hours, how many times will the hands of an analog clock go in exactly the same direction" (or, in exact opposite directions).

I'll put these people out of their misery. It's 22. The minute hand goes round once an hour, so 24 times, but the hour hand goes round twice so we subtract 2. We ignore the second hand because many clocks don't have them.

• I would think you copied my answer but fail once a or b are negative.

• Strictly speaking, the hands don't go anywhere.

Strictly speaking, they do go somewhere. They go round a circle.

• Write a function which takes a time of day and, given an analog clock, calculate the angle between the hour hand and the minute hand.

Taking anticlockwise rotation as positive, as is conventional for polar co-ordinates, an analog clock's hour hand rotates at -2 rev/day and its minute hand at -24 rev/day. Therefore, relative to the hour hand the minute hand rotates at -22 rev/day = (-22 * 360 / 1440) degree/minute.

At every midnight the angle between the hands is zero. So the angle from the hour hand to the minute hand at any given time of day is (((minutes since midnight) * -22 * 360 / 1440) mod 360) degrees. The most convenient method of converting time of day to minutes since midnight will depend on the format in which the time of day is passed in.

Note that the remainder operation in most programming languages preserves the sign of the input value rather than yielding a proper modulo for negative inputs, and that this will matter if this function is always supposed to yield a result in [0, 360). Easiest way to deal with that is to pre-bias that input by a multiple of the modulus big enough to keep it positive.

For example, if `minutes` has the correct minutes since midnight value, you might use something like

return fmod(minutes * -22 * 360 / 1440 + 23 * 360, 360);

If you want the smaller angle "between" the hands, rather than the angle of the minute hand relative to the hour hand, then do the previous calculation and if the result is > 180 then subtract it from 360.

If you want a result in radians, use 2 * PI instead of 360 above, and PI instead of 180.

If you want a more accurate result, work in seconds since midnight rather than minutes since midnight, and use 86400 instead of 1440.

I am not convinced there's any particular virtue in doing these calculations in decimal rather than double.

• But they end up back where they started, so they haven't actually gone anywhere.

In fact, every point on the circle is "back where they started" that circle, 360 degrees ago. Every point on the circle is just the hand's starting and ending point for one 360 degree arc of the circle. So at any given point in time, the hands are back where they started. So even as the hands move, they still haven't gone anywhere.

Unless the clock was recently made and the hands have never been in a specific location, yet, but mathematically speaking the functions of time that define the hands' movement don't have a beginning or end.

• Correct. It's just double the number of times in 12 hours, which is 11. The description you gave is correct, but I find it easier to visualize the hands of the clock to figure it out... or better still, if you have an actual analog clock you can move the hands around and see where they cross.

Starting and ending at 6:00, they'll cross once between 6 and 7, once between 7 and 8, once between 8 and 9, once between 9 and 10, once between 10 and 11, once at 12:00 exactly, once between 1 and 2, once between 2 and 3, once between 3 and 4, once between 4 and 5, and once between 5 and 6, for a total of 11 times. In 24 hours you just repeat that twice.

• But they end up back where they started, so they haven't actually gone anywhere.

The Wheels on the Bus go round and round - 3D Animation English rhyme for children – 02:15
— CVS 3D Rhymes

• But they end up back where they started, so they haven't actually gone anywhere.

Maybe they're chasing the refrigerator.

• This is why I hate these sort of problems because they are more about clever wankery than just looking at "how do I solve X the simplest way".

Maybe I should have done production engineering instead of software engineering.

• But they end up back where they started, so they haven't actually gone anywhere.

Technically, if the clock is moved, the hands have gone wherever the rest of the clock has gone (unless you drop it while you're moving it and the hands fall off, in which case the whole question becomes ).

• It's not a trivia question.

My code fully meets the stated requirements. And is standard high school math really considered trivia?

• Then how about "Only using addition, subtraction, bitwise, and shift operators".

• Jesus Christ.

We're talking about interview techniques, it's not some dumb game where someone gives you a problem to solve in code. Nobody gives a shit that you can solve the problem in code, that's not the fucking point.

• Then how about "Only using addition, subtraction, bitwise, and shift operators".

And this is exactly why I can't work in IT anymore. My boss says "here's the requirements, " I produce code matching those requirements, and he says "what about all these other requirements I didn't tell you about? "

• We're talking about interview techniques, it's not some dumb game where someone gives you a problem to solve in code. Nobody gives a shit that you can solve the problem in code, that's not the fucking point

Then I'm confused, because the interview question is specifically asking for the person to write some code, is it not?

That is precisely the answer that I would have given you if you had interviewed me, and I was attempting to ask you what your reaction would be to getting that answer during the interview.

I guess this is a an example of my inability to communicate clearly. I had been considering trying to get another programming job, but this has convinced me otherwise.

• Then I'm confused,

Well maybe this simple yes/no question will clarify things:

Am I interviewing you right now?

If the answer is "yes", well, then by all means proceed and bore us all with little code snippets while ignoring the actually interesting conversation would could be having in a universe where people like you don't exist.

If the answer is "no", well, then you'll soon realize there was absolutely no point for you to post that code snippet and maybe you should have actually contributed to the conversation in some useful way instead.

That is precisely the answer that I would have given you if you had interviewed me,

#I'm not interviewing you!

I was just giving an example of a basic coding question I've found useful when I've been interviewing other people. Stupid me.

and I was attempting to ask you what your reaction would be to getting that answer during the interview.

Well, if you want to see what my reaction would be if I were interviewing you and you gave that answer, I'm thinking your solution here isn't going to work. Because I'm not interviewing you.

• Well, if you want to see what my reaction would be if I were interviewing you and you gave that answer, I'm thinking your solution here isn't going to work. Because I'm not interviewing you.

Is there a way in which I could ask for your help/advice and you would willing to give it?

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.