Project Challenges: Files

A project challenge is built out of one or more virtual files. The file structure is mostly open-ended, with some restrictions to accommodate our code runner.

File Commands

Each file will have various commands associated with it, such as rename, delete, or configuring access levels. Most file commands are in 3 ways:

Basic File Editing

Opening Files

Click on a file in the file tree to open its editor.

Creating Files & Directories

There are several ways you can create or add files to our IDE:

Moving and Renaming Files

You can move or rename a file using the Rename () action from the file commands.

To move a file to a different folder, simply change its path in the rename dialog.

Deleting Files

You can delete a file using the Delete () action from the file commands.

A deleted file is moved to Deleted Files. You can undelete the file from this location if it was a mistake.

Files in this section are only saved until the page is reloaded.

File Configuration

There are several options available to customize how files work for the candidate. Use these customizations to help provide an optimal testing experience for your candidate.

Access Level

The access level affects the editability and visibility of a file for the candidate. By changing this value, you can create files that are read-only, unreadable, or even completely hidden. These changes can be both for reducing complexity (by removing the amount of variable content for the candidate), and improving submission test quality (by hiding content we don't want the candidate to see).


This is the default, and highest level of access. A Read/Write file is fully editable by a candidate—including being able to delete or move the file. Unless explicitly excluded, these files will be included on both candidate and submission tests, and are the primary source for solving challenges.

For directories, read/write is the only option that lets candidates add new files under it. It can be useful to disable read/write access on entire directories where you don't want the candidate to change files.


This option is only available for read/write files. If unchecked, the file cannot be deleted or renamed. The candidate can still edit this file.

This can be useful when you want the candidate to focus on correcting or improving a file, but not to worry about file names or breaking tests.

Read Only

A Read-Only file is fully visible to the candidate, but they cannot change its contents. These have many uses:

Note that directories can be marked as read-only, which prevents files from being added to them without preventing editing read/write files. This can be a useful technique for helping to define the application structure without being overly strict.


If a file is part of the test, but you don't want the candidate to view its contents, Restricted provides the ability to have a file or directory that's visible within the IDE, but its contents are completely hidden. Directories will not be able to be expanded, and files will not be openable.

Use cases here include:


A fully Hidden file or directory never shows up in the UI for the candidate. If they accidentally try to create a file that overlaps with a hidden file or directory, they'll get an error message about it being a restricted path, without any more information.

It's not often recommended to have fully hidden files or directories, as this can lead to a not entirely realistic testing environment. However, there are a few cases where fully hiding a directory or file make sense:

Run/Submit Options

A few other options are available to files for improving the testing experience and assessment results.

Include on candidate tests & Include on submission

These options define when to send a file to the code runner. (Empty directories are never sent to the code runner.)

Both options are enabled by default, which means the file will always be included when running code.

Go to/Create Reference/Project File

Use this action () to quickly create or toggle between reference and project files. Depending on your workflow, it may be faster to build the reference solution file first, then once all the tests are passing, create the project file and remove the working code. Or you may prefer to work in the opposite manner.

Submission Ignore Paths

Under Run Configuration is an option to add one or more Submission Ignore Paths. These paths are regular expressions that override any Access Level by allowing you to ignore edits & new files made by candidates during their submission.

Using submission ignore paths allows the candidate to create files that can help them test their code—such as additional unit tests or specs—without affecting the submission scoring process.

The way they work is any candidate-created file that matches an ignore path is not included in the runtime files. If a Project File matches an ignore path, the original, unedited Project File will be used instead of the candidate modified one.