.NET problem creation [Project Based Back-end]

Created by Shubham Kumar, Modified on Mon, 16 Jun at 6:48 PM by Shubham Kumar

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

  • 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:

  1. 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.


  1. 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.


  1. 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.

  1. 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

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article