Yes. We encourage people to use the internet to complete activities. Using the web to figure out how to do things is an integral part of any software engineer's job today.
You can use the internet for guidance, but please solve the problem by yourself. Do not cut-n-paste from the internet. We try hard to ensure that the problems we pose do not have a ready-made answer on the internet. If however, you do find that an exact answer exists on the internet for one of our problems on the internet, then 1) please let us know, and 2) please don't copy-n-paste that as your answer.
If you complete an activity that has been listed as a pre-requisite for a job, an "apply" link will appear on the job description page. Clicking on that will let the company know that you're interested.
To find the job description page, go to the company page, and you will find links to each of the jobs that the company has listed.
Right now we're in a limited beta, and are being very selective about what companies we work with.
We're adding new activities every week. Please keep checking.
Different answers are evaluated differently on ReliScore.
Some answers are checked by our automated evaluation engine. An answer is subjected to multiple test cases, and the rating that your solution gets depends upon the number of test cases it passes.
In some cases, the ReliScore team checks answers manually.
And in some other cases, an employee from the company who posted the problem, or the domain expert might evaluate your answer.
In most cases, if you submit an incorrect or incomplete answer, you will be given more chances to re-submit an improved answer. Often, you will also get feedback on what improvements you can/should make. Sometimes, you might also get pointers to tutorials or background reading material that will help you to solve the problem.
It depends.
In some cases (e.g. multiple choice questions) taking multiple attempts to reach the correct answer is clearly a bad thing.
In other cases (e.g. submitting a program) the situation is less clear. Multiple attempts can be interpreted negatively to mean that you're not as smart as someone who solved it in one attempt, but it could also be interpreted positively to mean that you are persistent and don't give up easily.
Usually, the ReliScore points you get for any (non-multiple-choice) solution depend only on the quality of your answer. The number of attempts is simply reported to potential employers, and they are free to interpret it as they wish.
Our recommendation: focus on getting a good quality solution. Don't worry too much about the number of attempts or the amount of time it took.
In most cases, we don't care about how long you took to solve a problem. We care more about the quality of the solution, and how many test cases it passes, and how well the code is organized.
The ReliScore points you get for any solution depend only on the quality of the solution, and does not depend on how long you took to solve it. However, do keep in mind that the backend does keep track of how long it took you to solve any problem, and this number is reported to potential employers, and they are free to interpret it as they want. Some might ignore it, and others might give it a lot of weightage.
Our recommendation: focus on getting a good quality solution. Don't worry too much about the number of attempts or the amount of time it took.
We would prefer it if you post it as a tutorial, or a rough guide - not an exact solution.
Basically, if your blog post about your solution is something that another ReliScore user can simply copy-n-paste, without even having to think through the solution, then it is something that we definitely would not like.
On the other hand, if your blog post is a rough guide, or a step-by-step tutorial with only code snippets, and it is expected that anyone who reads your blog post will also understand and learn in the process, then we would encourage it. In fact, send us a link, and we can include it on ReliScore as a hint to users who are unable to solve a problem.
If you're unsure whether to post something or not, just ask us, and we'll be happy to give you our opinion.
We cannot force you to remove anything you post on the internet, but if you do, please let us know, so that we can at least change our problems.
Solving a problem with extra features, or in a way much better than what the original problem asked for is a good thing and will usually get you extra points. However, be sure to add comments in your solution to justify why you have chosen to do extra work. Basically, make sure that the examiner understands that you haven't misunderstood the problem.
In the real world, over-engineering the solution to a problem is usually a bad thing, but ReliScore is a place to showcase your skills, so we usually reward the display of knowledge of advanced features. Just make sure the examiner understands that you know what you're doing and why.
A high score for any question or activity is a ReliScore estimate of what a very good user would score. Companies use this as an indicator of how good or bad a user's score is.
For programming and subjective questions, it is rare for someone to get a high score or higher.
For an individual multiple choice question it is easy to get a high score or above. a correct answer gets the high score (if the question has a single correct choice) or slightly higher than the high score (if the question has multiple correct choices, and the answer gets them all correct, without mis-identifying any of the wrong choices). However, for an entire section of multiple choice questions, again it is rare for someone to get a high score or higher.
This section lists some common mistakes people make, which results in their programs not compiling, or failing the ReliScore tests.
input.txt or test.txt or something like that will result in a failure.printf("Please input a number\n") or System.out.println("What is the size of the array?")conio.h - these are not part of the standard, and do not exist on non-Microsoft platforms. getch, which is found in conio.h is also not standard CDo not include iostream.h - that is no longer considered standard code. You should include just iostream. Same is the case with other standard headers. Your include like should look like this #include <iostream>
cout, cin, eof etc are in the std namespace, and hence will not work directly. You need to reference them as std::cout, std::cin, and std::eof respectively.
public class Main { otherwise it will fail to compile on our server.Contact Us, and we'll get back to you.