You're right about question 2, my apologies. There indeed was a bug in the test data for that question (which we have fixed now). However, the rest of the questions given in the test work properly.
The reason different test takers get (somewhat) different question sets is because our algorithm alters the difficulty of the questions based on the test taker's performance. I.e. if you did the first few questions well, you'd start getting progressively tougher questions. On the other hand, if you do badly, you'll be given successively easier questions.
I went through your solutions and I must disagree. Your solutions did not generate the correct output for the questions.
For example, I'll take the following question :
'Given the string variable 's' and the integer 'n', return a new string consisting of n repetitions of s.
For example, if s = "abc" and n = 3, you should return "abcabcabc".'
The code you have written is as follows :
String duplicate(String s, int n)
{
String result = s;
// First assignment already done
while (n > 0) {
result += s;
n--;
}
return result;
}
If we analyze the following code (assuming that s = "abc" and n = 3), initially, the variable 'result' is assigned the value "abc".
The loop then runs 3 times - when n = 3, when n = 2 and when n = 1. Which effectively means that "abc" is concatenated 3 more times giving the string "abcabcabcabc", which is incorrect.
I do agree that the solution is almost right. Note that you are allowed to compile your code and run it against our testdata (and even your own test cases) in order to establish it's correctness - which means that you did have the opportunity to find out that there was a bug in your code and fix it.
But in computing, how often is it acceptable to get things 'almost' right ? Would you be happy if Google returned search results which were almost right ?
I know that if a human conducted the interview, he would have helped guide you through the test - in fact, we are almost done adding the capability for recruiters to monitor test sessions in real time and converse with candidates.
I can also provide a case by case analysis of your other solutions if you wish.
As you said, it is the final code which is more important. But don't you think that it is also important to view the process by which the programmer arrived at the final code ?
An experienced coder will quickly reach a solution. Although he might make several mistakes on the way, he can usually quickly detect and correct them.
Someone less experienced would take longer, make more mistakes and probably take several attempts to correct those mistakes before getting it right.
Even though the final code might be more or less the same, the playback would help you discern who has better coding skills.
Of course, this would mainly be of use when attempting to choose between two closely matched coders.
Regarding copying and pasting - at the moment the rules don't explicitly ban this. The problem with allowing it is that the likelihood that the coder might attempt to cheat (and get away with it) is vastly increased (and cutting and pasting makes the playback feature worthless !).
That is why we went to the trouble of enabling syntax highlighting, compilation and testing within the widget, so that it would be as close to an IDE as possible.
BTW - regarding testing - aside from the 2 default test cases, it is also possible to enter your own testdata in the widget.
What you say is quite true and resonates with my personal experiences.
I myself do not possess an encyclopedic knowledge, nor will you see my fingers flying over the keyboard.
On the other hand, what I have noticed is that my understanding of the basics of coding, i.e. how to mix and match loops, arrays, conditionals, etc has vastly improved over time.
I frequently forget advanced or language specific topics - and I don't really care, since I can easily re-read about them online and refresh myself.
I have worked as an examiner for computer science university students and also as an interviewer for new hires for companies. What I have noticed is that the best candidates are similar - they have a rock solid grasp of the fundamentals of the language, and just twist and turn that knowledge to acquire the results they need.
You yourself have mentioned this - a good developer with an understanding of ORM can easily adapt to whichever framework he is required to use.
This mastery of the basics is what we are trying to assess with TechTestNow. You might notice that none of the questions require in-depth knowledge of the APIs (although that knowledge might help you solve some of them faster, there is always a solution that uses only basic constructs).
The main reason the tests are timed is because, all said and done, a good programmer does need to have a certain coding speed !
Also, in real life, a lot of time is spent not on figuring out how to solve a problem, but rather on figuring out what the problem is in the first place - what do we really need to do ? (and can it be done at all ?). Although the problems given in TechTestNow might seem contrived, they do have the advantage of being unambiguous, so that the programmer can just concentrate on writing a solution.
I think that the confusion is because you attempted to take the test using the login credentials for the recruiter.
Recruiters cannot take tests - only candidates can. Note that you can easily create a new account at the 'take test' page (please use one of your email addresses).
The reason different test takers get (somewhat) different question sets is because our algorithm alters the difficulty of the questions based on the test taker's performance. I.e. if you did the first few questions well, you'd start getting progressively tougher questions. On the other hand, if you do badly, you'll be given successively easier questions.