In an OutputChallenge, a student matches code with the corresponding output, or matches output with the corresponding code. That is why each OutputChallenge consists of at least 3 pieces of executable code. How to write these, is described in detail in this article.

Here's an example of an OutputChallenge on mobile:

And this is how the same OutputChallenge looks on desktop:

When to use an OutputChallenge?

OutputChallenges are the ideal choice for testing the student's understanding of similar syntax that leads to a different output.

Note that an OutputChallenge cannot generate a plot as an output. To learn about testing plotting knowledge, go to this article.

Authoring an OutputChallenge

The anatomy of coding Practice exercises, such as OutputChallenges, is described in this article. This section here describes the specific syntax to write an OutputChallenge in the Teach editor.

To learn about using DataCamp's Teach editor to create practice content, take a look at this article.


The OutputChallenge template contains an optional context block. When and how to use the context block is described in the article on Practice exercise anatomy.

Pre-challenge code

At the bottom of the OutputChallenge template you'll find the pre-challenge code block. You'll use this block to prepare the workspace, allowing the exercise code to run properly. So this is the place to be for loading packages and datasets or creating datasets on the fly.

Exercise code and variables

A code block provides a placeholder to generate code for an OutputChallenge. That makes sense, right? By including references to variables specified in the variables block, you create variations on the code. In the Teach editor, variables are referred to by placing the variable name between double curly brackets: {{ }} .
that var, fun, function or actual function names are not accepted as a valid reference. These will result in a mobile Preview error, such as Unexpected token ).
For example, the code below refers to variables var1, var2  and fun1 . As such, the different options for this exercise are dynamically generated based on the values specified in the variables block.

The OutputChallenge template contains multiple code blocks. You can use additional code blocks to specify several code templates. In this case, for the generation of each option, the backend will first randomly select one of the two templates, and next randomly fill it in based on the provided options for the variables. It's therefore perfectly possible that 2 out of three generated options come from the first template, while the third one comes from the second template.


To limit the variability between the different options that are generated, it's possible to anchor certain variables. Have a look at this example:

By prepending var1 and var2 with $, we are slightly changing the way the 3 code-to-output or output-to-code options are generated. Instead of randomly selecting a value for var1, var2 and fun1 for each option, a value for var1 and var2 will only be chosen once. All the options that are generated will now use the same combination of var1  and var2 , and only fun1  will be varied for the different options.

This will typically be useful if you're working with data variables, and you don't want the different options to contain very different dummy data to start from. With anchoring, you prevent the options from being too different, but there's still a high degree of randomization, because the anchored variables are still randomly chosen in the first stage.

Final note

Now that you've seen the details of creating an OutputChallenge, take another look at the examples provided at the beginning of this document. Do you see how they relate to the code mentioned throughout the document? Can you tell whether anchoring has been used?

Now it's your turn! Go to the Practice pool you are working on and make some amazing OutputChallenges!

Did this answer your question?