Single Page Coding problem creation [ATF Problem]

This document explains the key fields needed to create a problem on the platform. Each field is detailed with its purpose and expectations.

TABLE OF CONTENTS

• 1. Library Access Steps
• 2. Problem Name
• 3. Expected Solving Time (in minutes)
• 4. Problem Description
  • 4.1 Problem Statement
  • 4.2 Specifications
  • 4.3 Task
  • 4.4 Example Input/Output
• 5. Allowed Programming Languages
• 6. Difficulty Level
• 7. Scoring and Submission Rules
  • 7.1 Scoring System:
  • 7.2 Penalty System:
  • 7.3 Maximum Re-submissions:
• 8. Tags for Search and Categorization
• 9. Stubs
• 10. Sanity Check
• 11. Test Cases
  • 11.1 Test Case in Python
  • 11.2 Test Case in C#

1. Library Access Steps

1. Click the Library tab on the homepage.

2. Click the "+" button at the bottom to create questions.

2. Problem Name

• Requirement: A clear and descriptive title.
  
  

• Purpose: Helps with easy identification and categorization.
  
  

• Tip: Should be concise, informative, and highlight the core of the problem.

3. Expected Solving Time (in minutes)

• Requirement: Estimated time for solving the problem.
  
  

• Purpose:

  • Helps candidates manage time.

  • Used to classify difficulty level.
    
    

• Guidelines:
  
  

  • Easy: 30–60 mins

  • Medium: 60–120 mins

  • Hard: 120+ mins

4. Problem Description

•  Requirement: A detailed problem statement explaining:

  • The real-world significance of the problem.

  •  The tasks the candidate needs to perform.

  •  Any unique constraints or considerations. 

•  Purpose:  

  • This helps candidates understand the expectations. It provides essential context without overwhelming them with excessive details.

4.1 Problem Statement

• When posing an ATF question, it is essential to inform candidates that they must implement the code in the specified programming language (e.g., Java, Python, etc.). Additionally, they should ensure that the visibility of classes, data fields, and methods matches exactly as outlined in the specifications. Please refer to the attached image below

4.2 Specifications

• The specifications are provided in the code block for better visibility to the candidates. It includes all the details necessary to implement the code, such as the class name and visibility. It also specifies the data types, return types, and visibility for methods, all arranged in a precise order with appropriate indentation. Please refer to the attached image below.

• For example, in the image added above:

  • enum to be implemented is specified. It is also mentioned that this part has been added to the stub, which indicates that the candidate does not need to implement it.

  • Class names and their data types are listed, along with the visibility of each data type.

  • The constructor and getter/setter methods to be implemented are specified, including their visibility requirements.

  • The methods to be implemented within the class are specified, including their return types and visibility.

4.3 Task

• In the task section of the problem statement, it is important to describe the expectations for the implementation of the classes and methods in detail.  Please refer to the attached image below.

• In the example image attached above, it is clearly stated that the candidate must implement the People class. The candidate is expected to define the data members and the constructor. Additionally, the candidate must implement the PeopleImplementation class, where they are required to implement the two methods described in detail.
  
  

4.4 Example Input/Output

•  Including sample input and output shows:

• How the input will be given (like a list of objects, arrays, strings, etc.).

• What the output should look like (just a number? formatted text? a list?).

• The image attached below it clarifies what needs to be printed.

  •  You're expected to print each person as-is.

  • Then, print the maximum age.

• The final part of the problem description is the Note section. Candidates can test their code by using the "Run Code" feature, and the system will compare the output against sample test cases.

5. Allowed Programming Languages

• Requirement: Languages candidates can use.
  
  

• Purpose:
  
  

  • Ensures compatibility.

  • Restricts to specific languages (e.g., Java, Python, C#).

6. Difficulty Level

• Requirement: Label as Easy, Medium, or Hard.

• Purpose:

  • Match complexity with skill level.

  • Estimate time/effort needed.

• Guidelines:

  • Easy:

    • Basic logic

    • Minimal constraints

    • Solvable in < 1 hour

  • Medium:

    • Moderate constraints

    • Multiple solutions possible

    • 1–2 hours to solve

  • Hard:

    • Advanced concepts, data structures, algorithms

    • Requires significant time (>2 hours)

7. Scoring and Submission Rules

7.1 Scoring System:

• Base Score: e.g., 100 points for full solution

• Partial Scoring: Points proportional to test cases passed

  • e.g., 70% test cases passed = 70 points
    
    

7.2 Penalty System:

• Wrong attempt deduction:

  • Easy: -10 points

  • Medium: -20 points

  • Hard: -30 points

7.3 Maximum Re-submissions:

• Specify unlimited or fixed number of allowed attempts

8. Tags for Search and Categorization

• Requirement: Add relevant tags

• Purpose: Enhances searchability and analytics
  
  

Types of Tags:

• Skill Tags: Key skills used

• Discovery Tags: Helps explore similar problems

• Insight Tags: Offers hints or strategies

9. Stubs

• Requirement: Starter code for candidates
  
  

• Purpose:

  • Guides expected input/output

  • Reduces boilerplate

• Note: Only include classes/methods candidates must implement

10. Sanity Check

• Purpose: Ensure correctness and testability before using in assessments

11. Test Cases

• Requirement: The submission will be assessed based on the correctness of the methods implemented in the class. 

• Common Evaluation Metrics: The Java code evaluates the functionality of the classes by testing its methods using assertions. 

• Purpose: 

  • Ensures a fair and measurable evaluation for all submissions. 

  • Helps candidates understand that correct results and efficient implementations are required. 

• The image provided below serves as a test case for the problem statement explained above.

• Import required classes or packages into visibility within your current class.

• The class name used in the test cases will always be "eval."

• Here, we are setting up a test-driven structure using assertEquals to validate methods getMinimumAge() and getAgeOfOldestMan() inside PeopleImplementation.

• p.getMinimumAge(peoples)

  • Calls the method getMinimumAge() on the object p (which is an instance of PeopleImplementation).

  • It processes the list peoples and returns the People object with the smallest age (in this case, "Vivek", age 16).

  • String.valueOf(...) Converts the returned People object into a string using its toString() method.

  • assertEquals(expected, actual) Compares the expected value on the left to the actual output from the method (on the right).

  • If both are equal → test passes.

  • If not →  test fails, and it shows the mismatch.

11.1 Test Case in Python

Let’s consider another example of a test case in Python.

from source import *

def test_get_minimum_age(self):

    p = PeopleImplementation()

    peoples = [

        People("Vivek", 16, Gender.MAN),

        People("Kayle", 23, Gender.WOMEN),

        People("Jeremy", 42, Gender.MAN),

        People("Ivan", 69, Gender.MAN)

    ]

    self.assertEqual(str(p.get_minimum_age(peoples)), "People{name='Vivek', age=16, gender=MAN}")

• from source import *: This imports all classes and methods from the source module. It assumes that People, Gender, and PeopleImplementation are defined in a file called source.py.

• Define a test function named test_get_minimum_age.

• Create an instance of the class that contains the method you're testing.

• Call the method get_minimum_age(peoples) to get the youngest person from the list.

• Convert the returned People object to a string using str(...).

• Compare the result to the expected output string using assertEqual.

• This test ensures that get_minimum_age() returns the correct youngest person (Vivek, 16) and that the result matches the expected string format exactly.
  
  

11.2 Test Case in C#

Let’s consider another example of a test case in C#.

using System;

using System.Collections.Generic;

class Program

{

    static void Main()

    {

        var p = new PeopleImplementation();

        var peoples = new List<People>

        {

            new People("Vivek", 16, Gender.MAN),

            new People("Kayle", 23, Gender.WOMEN),

            new People("Jeremy", 42, Gender.MAN),

            new People("Ivan", 69, Gender.MAN)

        };

        string expected = "People{name='Vivek', age=16, gender=MAN}";

        string actual = p.GetMinimumAge(peoples).ToString();

        if (expected != actual)

        {

            throw new InvalidOperationException("Method Error");

        }

    }

}

• A list of People is created.

• The method GetMinimumAge() is called.

• The output is converted to a string and compared with the expected result.

• If they don’t match, the program throws an exception with the message “Method Error”. This acts like a test failure.

• Test Passes If:

  • The returned object represents Vivek,

  • And the string is exactly: "People{name='Vivek', age=16, gender=MAN}".

• Test Fails If:

  • Wrong person returned,

  • The output string doesn't match (even one character or space off),

  • The method is broken or buggy.