0% found this document useful (0 votes)
24 views5 pages

upGrad Coding Assessment Guide

Uploaded by

jaibirmalik2023
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
24 views5 pages

upGrad Coding Assessment Guide

Uploaded by

jaibirmalik2023
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

upGrad Coding Console Walkthrough

Types of coding assessments

There are two types of coding assessments on the upGrad learning platform:
1) In-module coding questions
2) Timed assessments comprising multiple coding questions

Common to All Coding Questions

Test Cases

1. Sample test cases (non-hidden test cases): ​These test cases are visible to learners
once they verify with the code. The logic of the program is tested against these test
cases. Depending on whether these test cases pass or not, learners can make changes
to their code to get the desired output.
2. Non-sample test cases (hidden test cases): These test cases are not visible to learners.
Each coding question will generally have at least one non-sample test case and for any
graded question, the final score in the question in only evaluated basis ​the number of
non-sample test cases passed​. Sample test cases have no contribution to the final score.
They are present just to check the sanity of your code. Non-sample test cases are
generally not visible to learners to restrict students from getting the expected output
through hard-coding.

Note: In cases where coding questions are evaluative in nature, marks are awarded only on
successful execution and acceptance of non-sample test cases.

1. In-module coding questions

For all coding questions, three features are available on the do-select platform to help students
write and test their code (both the syntax and the logic of the program). These three features
are:
a) Run
b) Verify
c) Submit

Run

The run option checks for any syntactical, runtime, or execution error present in the written
code. You can learn about the different types of errors ​here​. If the code runs successfully
without throwing any of the aforementioned errors, the console prints a message “Code
Execution Successful!” as shown in the screenshot below.

Please note that Run option does not check for the program logic or output against the test
cases (neither sample nor non-sample), and hence, its successful execution is nowhere related
to the evaluation of the code.

Verify

The verify option checks the code against the sample test cases available on the coding
console. It also prints the input along with the expected output and the output as produced by
the learner’s code.

If all the test cases pass successfully, a screen prompting “All sample test cases passed!” will
appear (something similar to the screenshot shown below):
However, in case the output is not as expected, the system prints “No sample test cases
passed” along with the details (as shown in the screenshot below):

Please note that the Verify option only validates the code against the sample test cases, and
hence, it does not directly imply that the code will finally be accepted when submitted.

Submit

The Submit option validates the code against both sample and non-sample test cases. If both
sample and non-sample test cases yield the expected output, i.e., if the test cases pass
successfully, the code is accepted. Else, the code will be in the rejected state. The screenshot
below is a sample of a code in the rejected state:
When you click on the “details” option (in case the code is rejected), you will be able to see the
failed test cases. But the details of these test cases won’t be mentioned as it might lead to hard
coding by some students.

If the code is partially correct, marks will be awarded depending on the number of non-sample
test cases passed successfully.

Please note that ​if there is no non-sample test case, on submission, the code will remain in the
submitted state and is neither accepted nor rejected.

How does the evaluation engine work?

Evaluation is done character by character in the console. A mismatch of even a character will
prevent the expected output and will throw an error.

For the non-sample test cases, the evaluation is done at the backend.
2. Timed assessments coding question

In a timed assessment, the submit button is triggered as soon as the test ends. Initially, you can
verify and run the code. You can submit all the questions upon completion at one go.

Common questions

Powered by AI

The hidden nature of non-sample test cases compels students to create universally applicable solutions rather than hardcoded answers to known outputs. This fosters critical thinking, creativity, and adaptability, as students must anticipate various unknown inputs and edge cases. Such skill development equips students with the capability to tackle real-world programming challenges effectively, ensuring they learn to build robust and flexible code .

By not revealing details of failed non-sample test cases, students are encouraged to reinforce deep understanding and genuine problem-solving skills rather than reverting to trial-and-error or hardcoding specific solutions. This constraint enhances learning outcomes by pushing students to reflect on the program's logic as a whole and develop more generalized, robust solutions .

The 'Submit' feature checks the code against both sample and non-sample test cases. Successful execution against non-sample test cases is mandatory for the code to be accepted, thereby preventing students from passing assessments through hardcoding. If the code fails non-sample test cases, it is rejected. This feature ensures that code correctness is evaluated objectively without student bias, as the details of non-sample failures are not shown, mitigating potential exploitation .

Sample test cases are visible to learners and are used to test the basic logic and sanity of the code by checking if it behaves as expected in known scenarios. Non-sample test cases, which are hidden, test the robustness and correctness of the code against the requirements and are crucial for the final evaluation of the code. This separation ensures learners don't rely on hardcoding responses. Marks are awarded based on passing non-sample test cases only, ensuring an unbiased evaluation based on true understanding and implementation of problem logic .

'Verify' is used to check the code against sample test cases, allowing learners to confirm the basic operational correctness of their solution. However, 'Verify' does not guarantee acceptance as it doesn't assess non-sample test cases, which 'Submit' does. By separating these steps, learners understand the importance of robust coding beyond sample cases, thus deepening their comprehension of extensive testing and real-world application readiness .

Character-by-character evaluation is stringent and unforgiving, as even minor deviations like extra spaces or incorrect characters will result in a failed case, regardless of functional correctness. This can be particularly challenging for students, as they must ensure that their output formatting is exact, adding complexity to debugging and emphasizing attention to detail in their development process .

A 'partially correct' submission means some non-sample test cases passed while others failed. This situation challenges students to diagnose and fix errors without insight into the specific logic errors of failed non-sample test cases, as these details are hidden to prevent hardcoding. Nonetheless, partial marks are awarded depending on the number of successful non-sample test case passes, enabling some credit for partially correct solutions .

The 'Run' feature focuses on detecting syntactical, runtime, or execution errors, not the logic compared to the test cases. If the code contains syntax errors, runtime issues, or exceptional errors, the console will print errors despite the logic being correct. This step ensures the code is clean and error-free from a technical perspective before moving on to logic verification .

Timed assessments force students to efficiently manage their time, balancing between understanding the problem, coding the solution, and thoroughly testing before submission. Since submission is automatically invoked at the end, students must strategically allocate time for verifying and debugging their code beforehand to maximize their test case pass rate under time pressure, encouraging rapid yet careful problem-solving and decision-making .

Sample test cases are designed to ensure code accuracy regarding basic functionality but do not reflect the full complexity or challenge of the problems. By not affecting scores, the system emphasises successful passing of non-sample test cases which gauge comprehensive understanding and ability to address unforeseen scenarios, thus aligning student performance evaluation with real-world problem-solving requirements .

You might also like