Build a Task Management API - Week of 12 Oct 2026

Problem definition

You are building a backend service for a task management application. The API must accept HTTP requests to manage tasks (create, retrieve, update, delete) and store them persistently in a database. Each task has a title, description, status (todo, in-progress, done), and creation timestamp. The API must validate input (non-empty title, valid status values) and return appropriate HTTP status codes (200, 201, 400, 404). Out of scope: user authentication, frontend UI, real-time notifications, and task prioritization. Every line under Success criteria is in scope for this challenge. Evaluation considers all of those topics, so your code should demonstrate as many skills and topics as possible.

Task brief

Build a working task management API using Version Control, Programming Fundamentals, Object-oriented Programming, Data Structures & Algorithms, Database Fundamentals, API Development Fundamentals, Security Fundamentals, Software Design Principles, Debugging & Troubleshooting, AI Assisted Software Development, Containerization (Docker), and Package & Dependency Management. The API must support CRUD operations on tasks, persist data to a database, validate all inputs, and run inside a Docker container. Use clean code patterns, handle errors gracefully, and document how to build and run your application.

Version Control

Use Version Control to initialize a Git repository for the task management API, track code changes through commits and branches, and collaborate by creating and merging pull requests. This skill ensures the team can manage the codebase reliably, review changes before integration, and maintain a clear history of all modifications to the backend service.

Programming Fundamentals

Programming Fundamentals teaches you to write clean, functional backend code for the task management API. You will use variables, operators, control flow, and functions to implement request handlers, validate input, and manage task data structures. This skill ensures your code is readable, maintainable, and handles errors gracefully.

Object-oriented Programming

Apply Object-oriented Programming to structure the task management backend API by designing classes and objects that represent core entities (Task, TaskRepository, TaskService) and enforce clean separation of concerns. Use inheritance, polymorphism, and interfaces to build a maintainable, extensible codebase that handles HTTP requests, validation, and database persistence with well-encapsulated responsibilities.

Data Structures & Algorithms

Implement Data Structures and Algorithms to efficiently manage and retrieve tasks in the backend API. Use appropriate data structures to store tasks in memory or database, apply sorting and searching techniques to handle task queries, and optimize time complexity for all CRUD operations to ensure the API responds quickly even as the task list grows.

Database Fundamentals

Implement Database Fundamentals by designing and building a relational database schema for the task management API, then writing SQL queries and application code to perform CRUD operations reliably. You will create tables, write queries to retrieve and modify task data, and optimize database access patterns to support the backend service.

API Development Fundamentals

API Development Fundamentals teaches you to build a working REST API for the task management backend. You will implement HTTP endpoints that handle create, read, update, and delete operations on tasks, validate incoming data, and return appropriate status codes and JSON responses. This skill demonstrates core backend competencies needed to deliver a production-ready service.

Security Fundamentals

Implement Security Fundamentals into the task management API by adding user authentication, role-based access control, secure password handling, and input validation. This skill ensures that only authorized users can access and modify their own tasks, and that all incoming data is validated before processing.

Software Design Principles

Apply Software Design Principles to structure your task management API backend with clear separation of concerns, minimal code duplication, and straightforward logic. Your implementation must demonstrate how proper design patterns make the codebase maintainable, testable, and ready for team collaboration and deployment.

Debugging & Troubleshooting

Implement Debugging & Troubleshooting practices into your task management API to identify and resolve runtime errors, logic bugs, and integration issues. You will add structured logging, use breakpoints to inspect state during execution, interpret stack traces to pinpoint failures, and apply root cause analysis to fix defects before deployment.

Ai Assisted Software Development

In this skill, you will use AI assistants to accelerate backend API development for the task management application. You will learn to write effective prompts, generate and validate code, debug issues, refactor for quality, and test thoroughly—while understanding AI limitations and using it responsibly. This hands-on practice demonstrates how to leverage AI tools as a collaborative partner in professional software engineering.

Containerization (Docker)

Add Containerization to your task management backend so the API and database can be packaged, deployed, and run consistently across environments. You will write a Dockerfile to build the application image, configure Docker Compose to orchestrate the API and database services, and verify that the containerized application handles all task operations correctly.

Package & Dependency Management

Implement Package & Dependency Management for the task management API backend. Set up a reproducible build environment using your chosen language's package manager, declare all external dependencies with appropriate version constraints, lock dependency versions for consistency, and demonstrate secure dependency practices. This ensures the team can reliably build, test, and deploy the application without manual dependency resolution.

Language and stack

You must choose exactly one language from: Python, JavaScript/TypeScript, Java, C#, or Go. Your README must name the chosen language and provide step-by-step instructions to build and run the application. You may use any framework, database, and dependency manager appropriate for your language. Include a Dockerfile so the application runs in a container.

Scenario

Your team is building a productivity tool for a startup. The product manager has asked you to deliver a working backend API that the frontend team can integrate with. The API must be reliable, well-structured, and ready for deployment. You have one day to complete a working prototype that demonstrates solid software engineering practices and can be containerized for deployment.

Deliverables

1. A working API that handles task CRUD operations with HTTP endpoints (POST /tasks, GET /tasks, GET /tasks/{id}, PUT /tasks/{id}, DELETE /tasks/{id}).
2. A persistent database (SQL or NoSQL) that stores tasks and survives application restarts.
3. A Dockerfile and README with clear instructions to build, run, and test the application in your chosen language.

Success criteria

AI evaluation scores every topic bullet below. Aim to demonstrate as many of these skills and topics as possible in your repository.

Version Control

• Repository Setup (beginner): The learner repo is initialized as a Git repository with a README that names the chosen language and documents how to run the app.
• Basic Commands (beginner): The learner has used git add, git commit, and git push to track and push at least three meaningful commits to the remote repository.
• Commits (beginner): Each commit has a clear, descriptive message that explains what code changed and why (for example, "Add POST endpoint for task creation" or "Fix task status validation").
• Branching (beginner): The learner created at least one feature branch (not main) and checked it out to develop a feature or fix.
• Merging (beginner): The learner merged a feature branch back into main using git merge, resulting in a linear or merge-commit history visible in git log.
• Conflict Resolution (intermediate): If merge conflicts occurred, the learner resolved them by editing the conflicted files, staging the resolution, and completing the merge with a clear commit message.
• Pull Requests (intermediate): The learner created at least one pull request on the remote platform (GitHub, GitLab, etc.) that shows a diff of changes, includes a description of the work, and was reviewed or merged before final submission.

Programming Fundamentals

• Variables & Data Types (beginner): Code declares and uses typed variables (strings for titles, integers for timestamps, enums or strings for status) to represent task properties consistently.
• Operators (beginner): Code uses arithmetic, comparison, and logical operators to validate task input (e.g., checking title length > 0, comparing status against allowed values).
• Expressions (beginner): Code evaluates expressions to compute task metadata (e.g., setting creation timestamp, formatting response payloads).
• Control Flow (beginner): Code uses if/else or switch statements to route requests (GET, POST, PUT, DELETE), validate status values, and return appropriate HTTP codes (200, 201, 400, 404).
• Functions & Methods (beginner): Code defines reusable functions for creating, retrieving, updating, and deleting tasks; each function has a clear purpose and accepts parameters for task data.
• Collections (intermediate): Code uses arrays, lists, or dictionaries to store multiple tasks in memory or query results; iteration and filtering work correctly (e.g., retrieving all tasks, finding a task by ID).
• Exception Handling (intermediate): Code catches and handles errors (invalid input, missing task, database failures) and returns meaningful error messages or appropriate HTTP status codes instead of crashing.
• File Handling (beginner): Code reads from or writes to a file or database file to persist tasks between application restarts; at least one CRUD operation demonstrates persistence.

Object-oriented Programming

• Classes & Objects (beginner): Task entity class exists with properties for title, description, status, and timestamp; instances are created and used throughout the API.
• Constructors (beginner): Task class has a constructor that initializes all required properties; constructor validates non-empty title and valid status values at instantiation.
• Encapsulation (beginner): Task class properties are private or protected; public getter and setter methods control access and enforce validation rules.
• Inheritance (intermediate): TaskRepository or service layer uses inheritance (e.g., base Repository class or abstract Service) to share common CRUD logic across entity types; child classes override or extend behavior appropriately.
• Polymorphism (intermediate): Multiple handler or service classes implement a common interface or base method signature (e.g., create, retrieve, update, delete); the same method call produces different behavior depending on the concrete class.
• Abstraction (intermediate): Abstract base class or interface defines contract for repository or service operations; concrete implementations hide database-specific logic and HTTP handling details from callers.
• Interfaces (intermediate): Repository or service layer defines an interface (or protocol) that specifies create, retrieve, update, delete method signatures; at least one concrete implementation satisfies the interface.
• Composition (intermediate): TaskService or controller class composes a TaskRepository instance and a validation helper object as dependencies; these composed objects are injected or initialized in the constructor and used to fulfill API requests.

Data Structures & Algorithms

• Arrays (beginner): Task list is stored and retrieved using an array or equivalent ordered collection; GET /tasks returns all tasks as a JSON array.
• Lists (beginner): Tasks can be added and removed from the collection; POST /tasks appends a new task, DELETE /tasks/{id} removes it by index or identifier.
• Stacks (beginner): Undo or rollback functionality uses a stack data structure to store previous task states; pushing state on update, popping on undo request.
• Queues (beginner): Task processing or notifications use a queue to handle requests in FIFO order; background worker processes tasks from queue without blocking API responses.
• Hash Tables (intermediate): Task lookup by ID uses a hash table or dictionary for O(1) retrieval; GET /tasks/{id} returns the task in constant time regardless of list size.
• Sorting (intermediate): GET /tasks supports sorting by creation timestamp or status; results are sorted in ascending or descending order as specified by query parameter.
• Searching (intermediate): GET /tasks supports filtering by status or title substring; search returns only matching tasks using binary search or linear scan with early termination.
• Time Complexity (intermediate): All CRUD operations (create, read, update, delete) complete in O(1) or O(log n) time; no nested loops over the full task list; API response time remains under 100ms for 10000 tasks.

Database Fundamentals

• Relational Databases (beginner): README documents the chosen database system (PostgreSQL, MySQL, SQLite, or equivalent); schema file or migration defines tasks table with id, title, description, status, and createdAt columns.
• SQL Basics (beginner): Application executes raw SQL or ORM queries to insert, select, update, and delete tasks; queries are visible in source code or logs.
• CRUD Operations (beginner): API endpoints POST /tasks, GET /tasks/:id, PUT /tasks/:id, and DELETE /tasks/:id all function correctly; each operation persists or retrieves data from the database.
• Joins (intermediate): If the schema includes a related table (e.g., task categories or tags), queries use SQL JOIN or equivalent ORM syntax to fetch related data in a single query; test case or integration test demonstrates the join.
• Indexes (intermediate): Schema or migration file includes at least one CREATE INDEX statement on a frequently queried column (e.g., status or createdAt); README explains why the index was added.
• Transactions (intermediate): At least one multi-step operation (e.g., updating task status and recording a timestamp in a separate audit table, or bulk delete with rollback on error) uses explicit transaction syntax (BEGIN, COMMIT, ROLLBACK or equivalent ORM transaction wrapper); test case verifies rollback behavior on failure.

API Development Fundamentals

• HTTP Basics (beginner): API listens on a configured port and responds to GET, POST, PUT, and DELETE requests with valid HTTP responses.
• REST Principles (beginner): Endpoints follow REST conventions using resource-based URLs (e.g., /tasks, /tasks/{id}) and HTTP verbs to represent actions.
• CRUD APIs (beginner): All four operations work: POST /tasks creates a task, GET /tasks/{id} retrieves it, PUT /tasks/{id} updates it, and DELETE /tasks/{id} removes it.
• Request & Response (beginner): API accepts JSON request bodies with task fields (title, description, status) and returns JSON responses containing the task object and metadata.
• Status Codes (beginner): API returns 201 for successful creation, 200 for successful retrieval/update, 400 for invalid input, and 404 when a task is not found.
• JSON (beginner): All request and response payloads are valid JSON; task objects include title, description, status (todo, in-progress, done), and creation timestamp fields.
• API Validation (intermediate): API rejects requests with empty or missing title, rejects invalid status values outside the allowed set, and returns 400 with a descriptive error message for each validation failure.

Security Fundamentals

• Authentication (beginner): API endpoints require a valid authentication token or credential; unauthenticated requests to protected routes return 401 Unauthorized.
• Authorization (beginner): A logged-in user can only retrieve, update, or delete tasks they created; attempting to access another user's task returns 403 Forbidden.
• Input Validation (beginner): API rejects requests with missing or invalid title, description, or status fields; returns 400 Bad Request with a descriptive error message.
• Password Security (beginner): User passwords are hashed using a standard algorithm (bcrypt, PBKDF2, or equivalent) before storage; plaintext passwords are never logged or returned in API responses.

Software Design Principles

• Separation of Concerns (beginner): API routes, business logic, and data access are in separate modules or classes; a judge can identify distinct layers (e.g., controller/handler, service, repository/data access) in the learner repo.
• DRY (beginner): Common validation logic (e.g., title non-empty, status enum check) and HTTP response formatting are reused across endpoints; no duplicate validation or response code appears in multiple route handlers.
• KISS (beginner): Each function or method has a single, clear responsibility; conditional logic is straightforward and avoids unnecessary nesting or over-engineered abstractions.
• SOLID Principles (intermediate): The codebase follows at least three SOLID principles: Single Responsibility (each class/module has one reason to change), Open/Closed (new task statuses or fields can be added without modifying existing route handlers), and Dependency Inversion (high-level modules depend on abstractions, not concrete implementations); a judge can trace how these are applied in the learner repo.
• Dependency Injection (intermediate): Services and data access components are injected into route handlers or controllers rather than instantiated directly; the learner repo includes a clear dependency setup (e.g., constructor parameters, service locator, or framework-provided DI container) that allows swapping implementations without changing route code.

Debugging & Troubleshooting

• Breakpoints (beginner): The learner repo includes a debugger configuration file or documented instructions showing how to set breakpoints in the chosen language and inspect variables during API request handling.
• Debugging Techniques (beginner): The learner repo demonstrates at least two distinct debugging techniques (such as print statements, logging output, or debugger inspection) applied to trace a specific bug in task creation or retrieval logic.
• Logging (beginner): The API logs all incoming HTTP requests, task operations (create, read, update, delete), and validation errors with timestamps and request/response details; logs are written to stdout or a file and are human-readable.
• Stack Traces (intermediate): When the API encounters an error (such as invalid input, database failure, or missing task), the error response includes or logs a complete stack trace showing the call chain; the learner demonstrates reading the stack trace to identify the exact line and function where the error occurred.
• Root Cause Analysis (intermediate): The learner repo includes a brief document or code comments explaining at least one bug found during development, the stack trace or log evidence that revealed it, and the fix applied; the fix must address the underlying cause, not just mask the symptom.

Ai Assisted Software Development

• Working with AI Assistants (beginner): Learner repo contains evidence of AI tool usage in at least three distinct tasks (code generation, debugging, testing) via commit messages, code comments, or a log file naming the AI assistant used.
• Prompt Writing Fundamentals (beginner): Learner provides a README section or separate file documenting at least two example prompts used to generate or fix code, each showing clear context, specific requirements, and expected output format.
• Code Generation (beginner): AI-generated code for at least two API endpoints (create task, retrieve task) is present in the repo and functions correctly per the API specification.
• AI-assisted Debugging (beginner): Learner repo includes a commit or code comment showing an AI-identified bug fix with explanation of the issue and how the AI helped resolve it.
• AI-assisted Refactoring (intermediate): Learner repo shows refactored code (e.g., extracted helper functions, improved error handling, reduced duplication) with a commit message or comment crediting AI assistance and explaining the improvement.
• AI-assisted Unit Testing (intermediate): Learner repo includes unit tests for at least two API endpoints, generated or refined with AI assistance, that pass and cover both success and failure cases.
• AI-assisted Documentation (beginner): API documentation (README, docstrings, or separate file) is present and generated or improved with AI assistance, covering endpoint paths, request/response formats, and status codes.
• AI Output Validation (intermediate): Learner repo demonstrates validation of AI-generated code through manual review comments, test execution logs, or a checklist showing the learner verified correctness, security, and alignment with requirements.
• AI Limitations & Hallucinations (beginner): Learner repo includes a comment, commit message, or documentation section describing at least one instance where AI output was incorrect or incomplete and how the learner corrected it.
• Responsible AI Usage (beginner): Learner repo includes a brief note or comment acknowledging appropriate use of AI (e.g., for scaffolding and iteration, not for bypassing learning) and confirming the learner understands the code and can maintain it.

Containerization (Docker)

• What is Containerization (beginner): A Dockerfile exists in the repository root that packages the application and its runtime dependencies into a single image.
• Docker Architecture (beginner): The learner repo includes a docker-compose.yml file that defines and connects at least two services (API and database) on a shared network.
• Docker Images (beginner): Running docker build on the Dockerfile produces a valid image with no errors; the image can be listed via docker images.
• Docker Containers (beginner): Running docker run or docker-compose up starts a container that exposes the API on a specified port and accepts HTTP requests without crashing.
• Dockerfile Basics (beginner): The Dockerfile includes a FROM statement specifying a base image, a WORKDIR directive, COPY or ADD to include application code, and a CMD or ENTRYPOINT to start the application.
• Building Images (beginner): The docker build command completes successfully and produces an image tagged with a meaningful name; the build log shows all layers cached or executed without errors.
• Running Containers (beginner): A container started from the built image runs the API service; curl or a similar tool can reach the API endpoint and receive a valid HTTP response.
• Environment Variables (beginner): The Dockerfile or docker-compose.yml defines at least one environment variable (such as DATABASE_URL or PORT); the running container reads and uses this variable correctly.
• Docker Volumes (beginner): The docker-compose.yml includes a volume definition that persists the database data; stopping and restarting the containers preserves previously created tasks.
• Docker Networks (beginner): The docker-compose.yml defines a network that allows the API container to communicate with the database container using a service name as the hostname.
• Docker Compose (intermediate): The docker-compose.yml file is syntactically valid, defines all required services with correct image or build directives, port mappings, environment variables, and volumes; running docker-compose up -d starts all services and docker-compose down stops and removes them cleanly.
• Container Debugging (intermediate): The learner can run docker logs to view application output; docker exec -it sh or bash allows interactive inspection of the running container; the API responds to all CRUD task operations (POST, GET, PUT, DELETE) with correct status codes and data while running in a container.

Package & Dependency Management

• Package Managers Overview (beginner): Repository includes a language-appropriate dependency manifest file (package.json, requirements.txt, pom.xml, go.mod, or csproj) that lists all direct dependencies used by the API.
• Semantic Versioning (beginner): All declared dependencies use semantic versioning format (major.minor.patch) in the manifest; version strings are valid for the chosen package manager.
• Version Constraints (intermediate): Dependency manifest uses appropriate version constraint operators (caret, tilde, ranges, or equivalent) to allow patch/minor updates while preventing breaking changes.
• Installing Dependencies (beginner): Running the package manager install command (npm install, pip install, mvn install, go mod download, dotnet restore) successfully resolves and installs all declared dependencies without errors.
• Dependency Lock Files (intermediate): Repository includes a lock file (package-lock.json, Pipfile.lock, pom.xml with resolved versions, go.sum, or packages.lock.json) that pins exact dependency versions; lock file is committed to version control.
• Updating Dependencies (intermediate): Running the package manager update command updates dependencies to versions allowed by constraints; lock file is regenerated and reflects the new pinned versions.
• Transitive Dependencies (intermediate): Lock file includes all transitive dependencies (dependencies of dependencies) with pinned versions; running install from lock file reproduces the exact same dependency tree.
• Private Package Repositories (beginner): If any private packages are used, the manifest or configuration file documents the repository URL or authentication method required to access them.
• Publishing Packages (beginner): Repository includes metadata (name, version, description, author, license) in the manifest that would allow the API package to be published to a public or private registry.
• Dependency Security & Vulnerability Scanning (intermediate): Running a security scanner (npm audit, pip audit, mvn dependency-check, go list -json, dotnet list package --vulnerable) completes without critical vulnerabilities; any flagged issues are documented or remediated.
• License Management (beginner): Repository includes a LICENSE file; all direct dependencies have compatible open-source licenses documented or verified via package manager.
• Dependency Best Practices (intermediate): Manifest declares only necessary dependencies; unused or redundant packages are not included; dependency tree is minimal and justified for the API functionality.

How to submit

1. Before you start, register on the SahkaarX platform and connect your GitHub account.
2. When the challenge begins, SahkaarX creates a private repository under your GitHub account and notifies you in the app and via push notification.
3. Clone the repository, implement your task management API, commit your work regularly, and push to the repository.
4. Submit your solution in the app by clicking Submit; include a link to your private GitHub repository.

What happens after you submit

When the challenge window closes, an automated AI-powered review analyzes your repository for code quality, design patterns, error handling, and adherence to the requirements. You will then participate in a mandatory in-app conversation where you explain your implementation, design decisions, and how you handled key challenges. This conversation verifies your understanding of your own code. If human judges are assigned, they review your repo score and conversation transcript before final results are published; otherwise results finalize automatically after the conversation.

Intellectual property

You retain full ownership of the code and work you submit. SahkaarX may host, evaluate, display on leaderboards, and operate the challenge using your submission. Your GitHub repository remains private under your account; you control access and can modify or delete it at any time after the challenge ends.