Given below is the process through which you can create a problem of type: .NET Project Based Back-end.
TABLE OF CONTENTS
- 1. Landing on the Dashboard
- 2. Navigating to Problem Creation
- 3. Configuring Basic Problem Details (Required)
- 4. Setting Up the Project
- 5. Filling Remaining Problem Details
- 6. Finalizing the Problem
- 7. Understanding the Project Structure
1. Landing on the Dashboard
When you log in to the DoSelect Platform, you arrive at the Home dashboard.
From here, you can manage tests and access the Library tab at the top of the page.
Action: Click on the Library tab to move to the question bank.
2. Navigating to Problem Creation
Once in the Library, you will see available libraries like DoSelect Questions and My Company Questions.
At the bottom-right corner, you will find a + (plus) button.
Action: Click on the + Create a new problem button to start creating your problem.
3. Configuring Basic Problem Details (Required)
A dialog box titled "Create New Problem" will appear.
Fill the following fields:
Name: Enter a descriptive and concise problem title (e.g., ".NET: Laptop Model"). Try to keep it concise and meaningful, as the title has a 45-character limit.
Problem Type: Choose Project Based: BackEnd.
Level: Select difficulty level – Easy, Medium, or Hard.
Framework: Choose from .NET(6) + SQLite, based on the requirement.
Action: Click Create to continue.
4. Setting Up the Project
You will land on the Problem Setup Interface.
Choose one of the two setup methods:
Upload ZIP: Upload a .zip file of the project.
GitHub Link: Provide a repo link for setup.
Using Upload ZIP Method (Required)
Download the projecttemplate.zip file provided.
Modify it locally as per the problem requirement.
Remove core logic to convert it into a Project Stub.
Compress and upload the stub via the interface.
Project Stub (Required)
This is the version of the project with key logic removed.
Candidates fill in the required logic.
Must be uploaded in .zip format (max 5MB).
Open in Editor option allows you to view/edit the stub in the online editor.
Sanity Check (Required)
Ensures the stub is valid and will run:
ZIP file < 5MB
Extracted contents < 20MB
Proper structure & valid config format.
Project Solution (Required)
Enable this to upload the fully working solution for reference.
Upload the complete version of your modified project (with logic).
Run the Sanity Check to verify everything compiles and works as intended.
5. Filling Remaining Problem Details
Problem Name (Optional)
This section allows you to modify the name provided during initial setup, if needed.
Expected Solving Time (Required)
Indicate how long a candidate should take (e.g., 60, 90, or 120 minutes).
Helps in difficulty tagging and test setup.
Description (Required)
Main problem statement seen by the candidate.
Must include:
Context
Task Description
Requirements
Use formatting tools and preview for clarity.
Difficulty Level (Optional)
This section allows you to modify the level provided during initial setup, if needed.
Scoring (Optional)
Assign points (e.g., 75).
Penalty is not applicable for project-based problems (keep at 0).
Maximum Re-Submissions (Optional)
Set to 0 for unlimited submissions (recommended).
Tags (Optional)
Discovery Tags: These tags are helpful for searching and categorizing problems within your own library.
Insight Tags: Helps in tracking performance and getting key insights on specific problem areas or topics (e.g., JWT, Error Handling).
Attachments (Optional)
Upload related resources like:
6. Finalizing the Problem
Evaluation Details
Summarizes the mode and score.
Default for project-based problems is the Automated Testing Framework.
Action Buttons
Save Problem: Saves all progress.
Save and Clone: Duplicates the problem.
Lock: Finalizes the problem. No further edits.
Archive Problem: Hides the problem from test usage.
Try This Problem: Simulates candidate view in test mode.
Problem Analytics: Insights on problem attempts, correct submissions, and used in tests.
Note: Ensure all required fields (marked with a red asterisk *) are filled. Otherwise, the problem will remain incomplete and cannot be used in tests.
7. Understanding the Project Structure
Downloading .NET problem template
Download the below Sample Project Solution Zip for a more reference .NET: Laptop Service
Expanding Template
The .NET Core project template has the following project structure:
Standard components and Additional Files
In the project structure of the .NET Core Framework, the LaptopModel.Test folder, LaptopModel.WebAPI folder and LaptopModel.WebAPI.sln is a standard component.
Additional files like configuration.json, .gitignore, init.sql, and README.md are included to facilitate the feasibility and use of the .NET Framework within the VS Code environment on our platform.
Main Application Folder (LaptopModel.WebAPI)
(To be changed)
Purpose: serves as the core application layer in a .NET Core project-based architecture. It is responsible for housing the actual Web API implementation that handles the business logic, API endpoints, and application configuration necessary to expose services to the outside world.
Requirement: Contains reusable and structured components to define how external clients interact with the application (via REST APIs). Remove the existing components and add the components for your project.
Test Folder (LaptopModel.Test)
(To be changed)
Purpose: functions as the unit and integration testing suite for the .NET Core application, specifically targeting the LaptopModel.WebAPI project. It ensures the application behaves as expected under different scenarios by validating logic, input/output, and error handling.
Requirement: Contains testing components independently from real infrastructure (e.g., fake repositories, in-memory databases).. Remove the existing components and add the components for your project.
Configuration & Environment Files
gitignore
(Not to be changed)
Purpose: Specify files and folders to ignore in Git to prevent unnecessary tracking.
Requirement: Must include build files and sensitive environment variables.
Configuration.json
Purpose: Stores project-related configuration settings.
Requirement: Should contain only necessary configuration values to avoid unnecessary complexity.
Editable Sections:
Default_open_files
Purpose: Defines which files open automatically when the environment starts.
Requirement: Add or modify file paths to ensure candidates begin with the most relevant files
Read_only_files
Purpose: Specifies files that cannot be modified to maintain integrity.
Requirement: Update this list to include essential configuration and test files that should remain unchanged.
Non-Editable Sections
buttons, scoring, post_start, and preview_port must remain unchanged, as they control the environment setup and execution.
For more details, refer to this.
Global.json
(Not to be changed)
Purpose: Defines configurations for .NET versions.
README.md
(To be changed)
Purpose: Provides documentation for project setup, usage, and guidelines.
Requirement: This should be updated with relevant information about the project.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article