DataCamp Practice supports three types of exercises: MultipleChoiceChallenges, OutputChallenges and BlanksChallenges.

In this article, you'll learn about the different parts that make up the coding Practice exercises: OutputChallenges and BlanksChallenges. For detailed instructions on each of these exercises types, go to the dedicated articles on OutputChallenges and BlanksChallenges.

Building blocks

DataCamp Practice exercises are based on building blocks. The scheme below provides an overview of the different building blocks and how these are combined to create the different types of Practice exercises.

As you can appreciate from this scheme, MultipleChoiceChallenges are very different from coding exercises. That's why MultipleChoiceChallenges are not discussed in this article. For detailed instructions on MultipleChoiceChallenges, go to this dedicated article.

What's in a name?

Each exercise starts with an informative title. This title is for internal use only: students will not see it. Setting an informative title will help you and us to navigate the exercises your create. To identify the different exercise types directly from the navigation bar, the exercise title is preceded with the abbreviation of the exercise type between square brackets, as in this example here: 

The building blocks explained


In some cases, you might want to specify a bit more context with the challenge at hand. You can do this by optionally specifying a context block. This context part will be parsed as markdown, and shown in a paragraph at the top of the view.

When relevant, use the context block to tell students about relevant packages, datasets, and functions that have been pre-loaded for them in the pre-challenge code (up next!).

Pre-challenge code

Pre-challenge code block contains code that is executed each time an exercise gets initialized. This code is not visible to students, and usually consists of dataset and package imports.


The code block provides a placeholder to generate the code for your exercise. It contains references to variables between double curly brackets: {{ }}. For example, the code below refers to variables var1, var2 and fun1, whose values are dynamically generated based on the values specified in the variables block (up next).


You can specify variables as a list of values for each variable name in the variables block. The backend will use these values to randomly generate a variation of an exercise. These variables are 'local', so they can only be referenced in the exercise where they are specified.

Instead of exhaustively specifying all the values, a variable's value can also be defined as an R or Python expression (depending on the language you're writing up a pool for). Take this example:

When the backend renders this kind of challenge and tries to find a valid value for var1 or var2 , it will first execute the g.rand_int() expression. It will use the resulting values as if they were hard coded. This allows you to make the number of possibilities virtually endless. Notice that you can still specify hardcoded values in addition to 'expression values'. This is supported for R, Python and SQL now.


Distractors are necessary only in blanks challenges and are meant to try to confuse the user into thinking that they are the right answers. The formatting is similar to variables but instead is specified in the distractors block. Distractors, however, do not need to be valid code as they are not run within the exercise.

YAML Syntax

Variables and distractors are written in YAML syntax as indicated by the 'LANGUAGE' field of those blocks. YAML is powerful, but sometimes peculiar. To make sure it always behaves as expected, you should wrap every variable in single quotes. However, this becomes a bit odd if you want to specify a string, with quotes:

  - 'quotes not kept'
  - '"double quotes"'
  - "'single quotes'"
  - '"this isn''t a problem"'

To see how this particular piece of YAML is parsed, you can use this online YAML parser. Checking the JSON output for the example above, results in this piece of code:

  "quotes": [
    "quotes not kept",
    "\"double quotes\"",
    "'single quotes'",
    "\"this isn't a problem\""

Here, it becomes clear that the first element indeed does not keep the quotes, while the other ones do.

Final note

Now that you understand the building blocks of coding Practice exercises, learn about creating OutputChallenges and BlanksChallenges.

While creating these exercises, be sure to also take a look at the Practice style guidelines, which helps keeps our product clean and consistent across the platform.

Never stop learning!

Did this answer your question?