Quote: Original post by Arrummzen_
I know three ways to implement a Fibonacci calculator. Recursively (O(φ^n)), Iteratively O(n), and Iteratively with Repeated Squaring of the matrix [0,1;1,1] O(lg(n)) time.

There's also a closed form expression for the calculation of Fibonacci numbers.

Quote: Original post by Washu

Quote: Original post by nilkn

Quote: Original post by mkuz
Test must present verification results for the same test cases which will be given in the report, so user can improve his code before submission.

That it doesn't do this is for me the real issue here.

I can see some use in not initially specifying performance restraints to see what the programmer's natural inclination is. But I can see no use at all in disallowing the programmer from improving his program before submission by not allowing him to see the full feedback from the program (assuming I'm interpreting mkuz correctly--I haven't used Codility myself).

It tells you if you passed the tests, your score, your estimated big O, and which tests you passed/failed (with rough descriptions of the tests).

Quote: It seems like very useful information to know, for instance, that someone did not initially write optimal code but, upon realizing that his program was too slow, was able to improve its performance to an acceptable level. That's much more useful than just knowing that he didn't initially write optimal code.

Why? Its an interview question. You should do the absolute BEST you can on it. Show your skills. He didn't, he failed.

Furthermore, does your end user tell you EXACTLY how they're going to use your software? No. That's part of the point of tests like these. You have the constraints of its usage, how it should behave. The performance question is NOT something an end user can tell you. They can say "I want to click button X and have it do Y," they can't say "I want to click button X I want it to do Y within O(n) where n is the number of items I've selected."

Typically by the time an interview candidate has gotten to the point where I'm talking to them, they've generally passed some form of a test much like this, either in house or from similar sites. Often times we'll require a code sample that demonstrates their effective knowledge, but that's usually collected some point after pre-screening such as Codility.

All I can say is that you and I have different philosophies on interview questions.

Signing up for a free plan shows statistics of tests. It's not that bad, 20-40% get 90% score or more.

Quote: Original post by Antheus

Quote: So you risk losing pretty good candidates based on random chance.

Employer gets all test results. They can choose whether numeric overflow matters to them. Many are likely to determine only perfect scores matter.

I just looked into this again, and it seems like using a long in C++ for accumulating the sums is sufficient to avoid numeric overflow. This hints that the backend machine is a 64 bit system. How on earth is the test taker supposed to know that? On a typical 32 bit implementation of C++, using a long would not be sufficient.

There are clear weaknesses in the test methodology here, no matter how you try to justify them.

I took the demo test and scored something like 32 and I'm not worried. I might be a bad programmer, but this is definitely not the test that tells it. I wasted 20 minutes misunderstanding the question and hacked together something quick in the last 10 minutes. I have no employment problems and I'm not the guy who writes that horrible code that everyone would want to get rid of.

Quote: Original post by Prefect

Quote: Original post by Antheus

Quote: So you risk losing pretty good candidates based on random chance.

Employer gets all test results. They can choose whether numeric overflow matters to them. Many are likely to determine only perfect scores matter.

I just looked into this again, and it seems like using a long in C++ for accumulating the sums is sufficient to avoid numeric overflow. This hints that the backend machine is a 64 bit system. How on earth is the test taker supposed to know that? On a typical 32 bit implementation of C++, using a long would not be sufficient.

Long on pretty much every single C++ compiler is 32bits. "long long" might is generally the 64 bit type, although it's not standard yet.

Quote: There are clear weaknesses in the test methodology here, no matter how you try to justify them.

Where? The question EXPLICITLY STATES that you should expect LONG arrays, to quote it:

Quote: Assume that the sequence may be very long.

.

Quote: Original post by Drathis
I took the demo test and scored something like 32 and I'm not worried. I might be a bad programmer, but this is definitely not the test that tells it. I wasted 20 minutes misunderstanding the question and hacked together something quick in the last 10 minutes. I have no employment problems and I'm not the guy who writes that horrible code that everyone would want to get rid of.

You can be forgiven for not understanding it, as I would assume english is your second language. None the less, it does rather explicitly spell out (both mathematically and through examples) exactly what it's looking for.

Also, that person everyone else wishes would DIAF due to their code? Yeah, they never think they're the one.

Quote: Original post by Washu

Quote: There are clear weaknesses in the test methodology here, no matter how you try to justify them.

Where? The question EXPLICITLY STATES that you should expect LONG arrays, to quote it:

I'm not arguing that. What I was arguing in that comment was simply: as far as I know, C++ has no native type that is guaranteed to be big enough to hold "maximum absolute value of int times maximum size of a vector<int>". So whether you get it truly right in C++ (without using a big integer class) is basically a matter of luck unless somebody tells you the exact environment the code will operate in.

(As an aside, long is typically 32 bits only on 32 bit systems, but is 64 bits on a 64 bit system. At least on Linux/BSD it works that way, it's been too long that I've touched Windows to say for certain how it works there. Clearly if int has 32 bits, but long has 64 bits, using long as accumulator works in that particular test (until they decide to have vectors with multi-billion size). If both are 32 bits, using long as an accumulator will fail. You really have to know the relevant details of the environment to make it work in C/C++.)

I don't think anybody is seriously disputing that the test correlates with programmer ability. I believe it does correlate, and whoever says they're not worried about only scoring around 30 should really reconsider. But if you expect even very good programmers to consistently score 100% on tests of this type you are deluding yourself.

The thing is, I'd much rather work with somebody who only scored around 90% in that test because of a minor slipup, but is a guru for tracking down bugs, rather than having to work with somebody who scored 100% but fails at debugging when he doesn't get it right the first time. It's the right mixture of skills that counts, and this particular automated test doesn't account for that.

Quote: Original post by nilkn
All I can say is that you and I have different philosophies on interview questions.

Have you been involved in the interviewing process as an interviewer? Because I have, and I agree with Washu.

The truth is, most people aren't worth hiring. Out of around 30 people I've interviewed in the last two years, three of them impressed me. Unfortunately, I haven't always had the final say on who gets hired, and people I did want didn't always accept the offers, so we still ended up with duds. And then management is reluctant to fire anyone, because "then who are we going to put on the project?" Apparently negative productivity is better than 0 productivity.

So, in those situations, the game then becomes, "how do I find that 90% and get them out of my sight the fastest?" I need to figure out who the stupats are and paint them in the worst possible light. The good people are so rare that they will defy my attempts to make them look bad, so this is a decent strategy. At least it helps keep me from wasting too much time on people.

I can see this test as a good filter for programming jobs in NASA or some engineering firm. But for something like web programming or desktop application, is this really applicable? Do all programmers write 100% flawless code on the first or even second go? Shouldn't tests of this sort be adjusted to the type of job being offered as opposed to a blanketed litmus test regardless of the position (like Codility seems to be)?

I can see this test being used for placement (junior, mid-level, senior, etc), but not for weeding people out (in general).

Quote: Original post by capn_midnight

Quote: Original post by nilkn
All I can say is that you and I have different philosophies on interview questions.

Have you been involved in the interviewing process as an interviewer? Because I have, and I agree with Washu.

The truth is, most people aren't worth hiring. Out of around 30 people I've interviewed in the last two years, three of them impressed me. Unfortunately, I haven't always had the final say on who gets hired, and people I did want didn't always accept the offers, so we still ended up with duds. And then management is reluctant to fire anyone, because "then who are we going to put on the project?" Apparently negative productivity is better than 0 productivity.

So, in those situations, the game then becomes, "how do I find that 90% and get them out of my sight the fastest?" I need to figure out who the stupats are and paint them in the worst possible light. The good people are so rare that they will defy my attempts to make them look bad, so this is a decent strategy. At least it helps keep me from wasting too much time on people.

I hope you're not saying that because he hasn't interviewed his opinion is invalid or discredited.

I spoke to someone who's a programmer and has been an interviewer and that person actually agreed with the OP (well except for the illegal part).