Skip to main content
A boilerplate and its test cases are easiest to understand from real examples. Below are two: a simple single-line problem, and one that needs multi-line input. See Creating a Custom Programming Test to set up a custom test and find where each field lives in the builder.

What the Boilerplate Actually Does

A candidate never sees a blank file. They see your boilerplate: starter code that already reads their input and prints their output, with a single function left for them to fill in. Their job is to write only the logic inside that function; your boilerplate handles everything around it.
Your test cases run against the whole boilerplate, not just the candidate’s function. If the input-reading or output-printing part of your boilerplate has a bug, every candidate’s submission fails, even correct ones.

Example 1: Single-Line Input

Problem statement: Given a string, return its first character. Submitting equip should return e. A test case for this problem is just that pair: The boilerplate reads one line, calls the candidate’s function, and prints the result:

Example 2: Multi-Line Input

More complex problems need several pieces of input. For example: Given an array and an index, return the value at that index. The input arrives as three lines:
The first line is the array’s length, the second is the array itself, and the third is the index to look up. For this input, the expected output is 3. The boilerplate now has to read three lines and assemble them into structured data before calling the candidate’s function:
The candidate’s function never sees raw input lines, only the clean, typed values your boilerplate extracts from them. The more parsing you do in the boilerplate, the less room candidates have to get tripped up by formatting instead of the actual problem.