Problem setting - Guidelines

Overview

1. Introduction
2. Eligibility criteria
3. Contest type and schedules
4. Problem difficulty level
5. Problem setting guideline
1. Problem components
2. Things to remember
6. Conflict resolution
7. Payments
8. Disclaimer

Introduction

Do you also think of improvising a problem while taking up a coding challenge or just making a new one altogether by using the coding concepts? HackerEarth is always on a search for the finest of talent who can be part of our problem setting team to create and/or test problems along with writing good editorials in simple English for our contests and challenges. If you are remotely interested in doing these things, read the guidelines and apply to join this cool place full of talent, experience, and lots of learning and be part of our problem-setting hacksters. 

Contest type and schedules

There are three types of contests HackerEarth hosts which are the following:

1. Easy
2. Data Structures and Algorithms
3. Circuits

 

1. Easy

Easy is a series of HackerEarth’s beginner-level challenges that are hosted on the first weekend of every month. The purpose of this challenge is to help beginners hone their coding skills in the language of their choice. Easy is a rated contest and is open for everyone to participate. You have 6 algorithmic questions to solve within 3 hours on a particular date and time. The leaderboard is generated based on the score given for each problem. The prizes and t-shirts are given to the top participants with ratings < 1600 (Beginners). 

These are the following terms and conditions you need to know:

• In order to be able to claim your prizes, your HackerEarth profile must be more than 60% complete.
• Ratings will be updated 5 days after the challenge ends in each programmer’s user profile.
• If your code is found plagiarised, you will not be eligible to claim the prize. 

2. Data Structures and Algorithms

Technical interviews with long coding rounds are a bit intimidating for freshers and even experienced people. Well, worry not because HackerEarth presents to you a one-of-a-kind Data Structures and Algorithms coding challenge where you can compete in a real-time interview environment and practice your coding skills to make them all the more efficient. The challenge has 3 programming questions and you have 90 minutes to solve all the questions. This is a rated contest but there are no prizes for this challenge. 

3. Circuits

Circuits is a coding marathon to challenge programmers and developers with several programming questions of mixed difficulty levels over 9 days. The questions are created by multiple problem setters from HackerEarth and test your logical minds and coding skills by solving real-life programming problems. Circuits take place during the third and fourth week of every month. The timeline is as follows:

Day - 0	Problem 1, Problem 2, Problem 3 (Approximate)
Day - 1	Problem 4, Problem 5
Day - 4	Problem 6, Problem 7
Day - 6	Problem 8
Day - 9	Challenge ends

New problem statements will be published every 48 hours and the ace coders will win amazing prizes. The top 5 candidates will be given amazing HackerEarth T-shirts.  

Problem difficulty level

The problems are classified into the following 3 levels on the basis of difficulty:

1. Easy 
2. Medium
3. Hard

Easy

Easy problems are basic problems that use the coding concepts directly without much mathematical calculation or problem-solving. They have easy constraints and a simple problem statement that can be understood by beginners easily. The test cases are also easy to pass and it is easier to implement the concept in the coding.

Medium

Medium problems are having moderate difficulty which includes the use of advanced coding concepts along with mathematical formulas and complex problem-solving. They have difficult constraints to implement and a bit complex problem statement. You need to solve the question by putting together various advanced coding concepts and implementing them in your code.

Hard

This is considered the highest difficulty level for a problem. These questions can be solved by applying various advanced coding concepts to a single problem. Sometimes they are real-life problems and though the problem statement is simple but implementing the solution is a bit difficult in these problems. The constraints are also difficult and these questions take time to solve. 

Problem setting guidelines

Question statement

Problem statement structure

The problem statement must be written in American English. It is divided into the following two sections:

• Problem statement
• Task

Follow these guidelines to ensure the content of the problem statement is readable and understandable.

Problem statement content

• Avoid using elaborate stories that can confuse the reader while reading the problem statement.
• Make the content gender-neutral. Do not use he or she.
• Avoid using vague or ambiguous sentences.
• Ensure that terms are consistent- If you are referring to ‘x’ as the distance between point A and point B, you must not refer to ‘x’ as ‘length’ anywhere else in the problem statement.
• Avoid spelling errors.
• Every variable provided in the problem statement must be in Italics (except mathematical equations). For more information, refer to LaTex symbols.

Neutral content

• Avoid using geography-specific backstory, names, places, or events that may not be familiar to a candidate.
• Avoid referring to any culturally specific territories. 
• Strictly avoid any sexist, racist, or religiously offensive remarks or any sentence that promotes any type of political ideology, regionalism, or community-based generalization.
• Avoid references to politics, religion, and other controversial topics.

Important: If your problem statement contains anything mentioned in this section, it will be rejected without further checks.

Currency reference

If the question is currency-related, then it is advisable to use only US dollars.

Reference about any person

• Strictly avoid defaming any person, team, place, community, region, country, or sport. 
• Avoid using references that represent hatred or personal bias against anything or anybody.
• If you must refer to a person or use names in a problem statement, use only the following names:

First name	Last name	Gender
Alice	Smith	Female
Bob	Jones	Male
Ben	Johnson	Male
Mike	White	Male
Tara	Green	Female
Anita	Williams	Female
Lisa	Davis	Female
Mary	Brown	Female
John	Wilson	Male
Paul	Miller	Male

Example

The structure of the example is as follows:

1. Assumptions: It comprises all the assumptions and variables of the example in bulleted points.
2. Approach: It comprises a structural approach to the problem with the help of an example.

Important: The example provided here must be different from the sample test case.

Function description

This defines the number of parameters the function takes along with what they represent according to the problem statement. It also defines the answer which will be returned by the function.

Input format

The structure of the heading is as follows:

• It must be in bold.
• It must be in sentence case only.
• It must not be underlined.
• There must not be a colon (:) after the heading.

The sample input format for a programming question is as follows:

• The first line contains a single integer N denoting the size of array A.
• The next line contains N space-separated integers denoting the elements of array A.

In this, the different inputs that are required are clearly specified in bullet points. 

If your input format refers to test cases in the programming question, then follow this style of writing

• The first line contains a single integer T, which denotes the number of test cases. T also specifies the number of times you have to run the solve function on a different set of inputs.
• For each test case:
• The first line contains a single integer N denoting the size of array A.
• The next line contains N space-separated integers denoting the elements of the array.

This section is especially important when a candidate wants to use their own custom input while solving a problem. 

Output format

The structure of the heading is as follows:

• It must be in bold.
• It must be in sentence case only.
• It must not be underlined.
• There must not be a colon (:) after the heading.

This section must contain precise and clear instructions about how the output is expected. For example, if the expected output of a programming question is a single numerical value that represents the length of an array, then you must write it in the following way:

‘The output must contain a single integer value that represents the length of the array A.’

Note: Sometimes, certain expected outputs are required to be printed in a new line or in a space-separated format. In such cases, it is important that such requirements are clearly called out.

Constraints

The structure of the heading is as follows:

• It must be in bold.
• It must be in sentence case only.
• It must not be underlined.
• There must not be a colon (:) after the heading.
• The constraints must be in Latex.

Every programming question requires some constraints. They represent the upper and lower limit of the input data. 

The constraints must be formatted using the LaTex symbols. You can click the symbol provided in the menu of the Question statement text area. 

For more information, refer to LaTex symbols.

Note 

• The constraint’s range must be in exponential form. For example, if you want to use 100000, then the correct method to represent this is 10^5.
• The same rule holds if you are using the mod value in a programming question, then it must be represented as 10^9+7 instead of 1000000007. This improves the readability of constraints.

You can check the sample format here. Here is an example of a sample problem.

Conflict resolution

• If a problem tester finds any faults with a problem, the problem setter will have to correct the problem until the tester rechecks and approves the problem.
• If a problem is found to be faulty while it is being used, the problem setter and problem tester will have to forfeit the entire compensation amount paid for the problem.