Hacker News Reader

Comment by tomtang0514 | Hacker News Reader

I've seen several companies giving out such homework to me or my friends back in college. And to be honest, none of the are among the "great culture company list" people are talking about. Beside all the issues you mentioned above, those tests don't have a clear PASS line. You spent hours on that and can be rejected for no reason. Back in college I've done a code challenge from Box and my solution ranked No.1 in their leaderboard (although nearly 100 people are No.1 with the same highest score) and I was rejected without an interview. Another company I don't remember rejected me because I used (x * 8) not (x << 3). (But I'm interviewing a web company and I was writing python, not C in some embedded system) Most of the time I just don't know what the hell they're looking for. So now I reject all those HW or code challenge unless they agree to pay me for the time I spend. (Obviously no one has ever agreed my term so far.)

View on HN

Not that does anything except to confirm the pointless of that selection criterion:

  % python -mtimeit -s 'x=1' 'x<<3'
  10000000 loops, best of 3: 0.061 usec per loop
  % python -mtimeit -s 'x=1' 'x*8'
  10000000 loops, best of 3: 0.0602 usec per loop

  % pypy -mtimeit -s 'x=1' 'x<<3'
  1000000000 loops, best of 3: 0.00103 usec per loop
  % pypy -mtimeit -s 'x=1' 'x*8'
  1000000000 loops, best of 3: 0.00103 usec per loop

Even in C I would point out that the compiler will likely make such a trivial optimization for you. That was clearly a company full of morons.

In fact GCC will virtually always produce optimal code for multiplication by a constant. Targetting AVR, for example (which doesn't always have hardware multiply), GCC produces more compact code if you use '*' than if you use '<<'. Similarly, any attempt I made to multiply by non-round constants using bitshifting and addition led to less compact code.

The one case so far where I've seen better results using tricks like reciprocal multiplication and shifts was when there was no way for gcc to know it could throw away almost half of the bits due to input range limits. It would be kind of nice to have, say, a 19-bit integer type.

Uh, extremely unexpected.

Not really, simplifying simple operations (like multiply by a constant) is pretty much Compilers 101 / Dragon Book kind of stuff

Regardless of the compiler, let's say (x << 3) is slightly more efficient than (x * 8), I don't see it make such difference since my job will probably be writing code for webapp sort of things. For the things I do I actually believe readability advantage of (x * 8) overcomes the efficiency disadvantage (which doesn't even exist with modern compiler).

Some interviewers (not just the "homework") raise their bar by not allowing you to make any tiny mistake. And I just don't get it. If someone is good enough to write something like a lite version of Hacker New website in hours, I'm not going to turn him/her down because of such mistake.

And the person who could potentially write the "most perfect" code with all of the conditions applied is often not within that company's price range.

I did interviews at a company for about 2 years and there was constant pressure from management to do trivial crap like that, it finally came to a head and I invited management and one of the "rockstars" to do a mock interview.

When it was evident that the person they thought of as a "rockstar" could not solve these tests(without prior knowledge of the problems), they immediately discounted them as a worthless and stopped bugging me (about that, of course not about everything else).

What the hell. A developer who writes x << 3 instead of x * 8 when writing code that is logically doing multiplication is not a good developer. Written code is designed for human readability; the human should not be having to convert that mentally to its math equivalent to understand what operations are taking place. In nearly every possible case, this is at best a micro-optimization. At worst, a symptom of someone who writes unnecessarily obfuscated code to show off their knowledge in a manner that only hurts the maintainability of code by a team.

If I found bit shifting in an interview code sample as a replacement for basic multiplication, I would ask the developer why they chose to do it that way. They'll either a) calmly explain that their computer science classes taught it that way or it's a habit they've adopted after writing code for embedded systems or similar where the optimization actually made a difference, or b) their ego will make an appearance with a "because I'm so senior" attitude. The latter is not a good sign.

Or it's idiomatic for that language.

Sometimes x << 3 is more readable than x * 8. It depends on why you are doing the shift/multiply.

(Obviously no one has ever agreed my term so far.)

My company does 4 hour work-product tests, and we pay each of the candidates for their time. We're in Portland, not SV, so maybe there is a difference in environment.

As a candidate I think the bodes so well for the culture and how respectfully people would be treated in such an organisation.

It shows a level of thought about people that goes beyond ping-pong tables and free pizza and coke (and ironically probably costs less than those things).

Let me guess ... you are happy working there right?

I have had an interview where both the (x * 8) and (x << 3) would have been frowned upon, for using a "magic number".

Good, I think? It wouldn't be a deal breaker at interview for me (or even something we test for, come to think of it), but they were right in that it is a magic number. Unless you are doing something where the context is so perfectly obvious that number should be an 8, it's better off tagged as a constant so the next dev to come along has a better chance of understanding your code.

Indeed:

  static const int eight = 8;

  x * eight;

Sometimes magic numbers are just that - numbers. Adding constant definitions is often a good thing, but sometimes just adds noise.

I think you mean

    static const int days_per_week = 8;

:-).

Reply on news.ycombinator.com