Sample Hackathon Questions

Q1. Build a real-time web-based chat application using Perl and CGI scripting.
Task:
1.​ Implement user authentication, allowing users to register, log in, and manage
sessions.
2.​ Enable instant messaging with chat rooms and private messaging, using AJAX
polling or WebSockets for real-time updates.
3.​ Store chat history in a database (MySQL/SQLite) for future retrieval.
4.​ Ensure a responsive UI with HTML, CSS, and JavaScript while prioritizing security,
input validation, and performance optimization.
5.​ Features include file sharing, emoji support, and user status tracking.

Q2. You organized an event and received multiple emails from participants containing their
name, email ID, and message.
Your task is to automate the extraction and storage of this data.
Task:
1.​ Retrieve event-related emails from the inbox .
2.​ Extract and structure the sender’s name, email ID, and message content.
3.​ Store the extracted data in an Excel file, CSV, or database for record-keeping

Q3. Lost & Found Management System

Problem Statement:
Colleges struggle with efficiently managing lost and found items. The manual process often
delays the recovery of valuable belongings. Your challenge is to build a robust MySQL
database system that tracks lost items, found items, and the claims process, while also
designing a full UX flow that outlines how users interact with the system.
What You Need to Deliver:
1. MySQL Database Design:
Create tables such as users, lost_items, found_items, and claims with appropriate
relationships and constraints.
2. SQL Queries:
Write queries to insert new lost/found reports.
Develop matching queries to automatically suggest potential matches between lost and
found items based on keywords or attributes.
Provide queries to update claim status and retrieve pending claims.
3. Full UX Flow:
Design the complete user journey (UX flow) for both students (reporting and checking
items) and administrators (verifying claims).
The UX design can be done on Figma or drawn on paper.

Q 4. Smart Canteen Inventory & Wastage Tracking

Problem Statement:
Canteens often over prepare food, leading to wastage, while struggling to track inventory
effectively. Your task is to create a MySQL-based system that manages food inventory,
tracks daily usage, and logs wastage events. Alongside the database, design a complete UX
flow that shows how staff can manage inventory and analyze wastage.
What You Need to Deliver:
1. MySQL Database Design:
Develop tables like food_inventory, daily_usage, and wastage with appropriate constraints
and relationships.
2. SQL Queries:
Write queries to update stock levels, monitor daily usage, and flag items for restocking.
Provide queries that analyze wastage trends and generate summary reports.
3. Full UX Flow:
Design the user journey for canteen staff—from inputting inventory data and logging
wastage to generating reports and alerts.
The UX design can be created in Figma or on paper.

Q5. Project Title: Build Automation Tool for Linux- RubyMake

Problem Definition

For build automation in Linux, Makefiles are commonly used but they rely on complex shell
scripting and syntax that can be difficult to manage, especially for Ruby-based projects.
While tools like Rake exist, they may not fully integrate with existing Makefile-based
workflows. Developers need a more intuitive, Ruby-driven alternative to automate builds,
resolve dependencies, and streamline project compilation while maintaining compatibility
with traditional Makefiles.

Objective

Develop a build automation tool that uses a [Link] instead of a traditional Makefile.
This tool should allow developers to define build tasks in pure Ruby, automate compilation,
dependency resolution, and testing, and integrate seamlessly with Linux environments.

Modules:
 1.​ Ruby-Powered Task Automation
○​ Define custom build tasks using Ruby syntax instead of shell scripting.
○​ Provide a simple DSL (Domain-Specific Language) for managing build steps.
2.​ Dependency Tracking
○​ Automatically detect and resolve dependencies.
○​ Check if source files have changed before recompiling.
3.​ Integration with Existing Tools
○​ Compatibility with Makefile-based projects (generate Makefile from
[Link]).
○​ Support for C, C++, and Ruby projects.
○​ Ability to call system commands (e.g., gcc, g++, ruby).
4.​ Customizable Build Workflows
○​ Allow users to define workflows (build, test, deploy).
○​ Support pre- and post-build hooks.
5.​ Command-Line Interface (CLI)
○​ A user-friendly CLI like make, with commands like:

#bash
ruby-make build
ruby-make test
ruby-make clean
6.​ Logging & Debugging
○​ Generate detailed logs of build steps and errors.
○​ Verbose and silent mode for debugging or quiet execution.

Technology:
●​ Language: Ruby
●​ OS: Linux (Ubuntu, Debian, CentOS, Arch)

Q6. Project Title: A User-Friendly CVS Frontend for Linux- RubyCVS

Problem Definition

CVS (Concurrent Versions System) is an older version control system still used in legacy
projects, but it lacks a modern, user-friendly interface. Developers managing CVS-based
projects often struggle with its complex command syntax, difficult branching model, and
lack of intuitive logging. Unlike modern VCS tools like Git, CVS does not provide simple
status tracking, history visualization, or automated workflows.
Many Linux developers and system administrators require a Ruby-based wrapper around
CVS that offers a simpler CLI, better logging, and Git-like usability without breaking
compatibility with existing CVS repositories.

Objective

Develop a Ruby-based command-line interface (CLI) tool that acts as a user-friendly

frontend for CVS, simplifying common version control tasks, improving repository
management, and offering a more intuitive workflow for developers.

Modules:
1.​ Simplified CVS Commands
○​ Replace complex CVS commands with intuitive Ruby-based commands, e.g.:

sh
ruby-cvs init ​ # Initialize a CVS repository
ruby-cvs add [Link] # Add a new file
ruby-cvs commit -m "Fix bug" # Commit changes
ruby-cvs status ​ # Check repository status
ruby-cvs log ​ # View commit history
○​ Alias traditional CVS commands (cvs add, cvs commit, cvs diff, etc.).

2.​ Improved Change Tracking

○​ Implement a git log-like history for CVS commits.
○​ Show file differences using diff with color-coded output.
○​ Track uncommitted changes (ruby-cvs status).
3.​ Automation & Integration
○​ Auto-checkout and auto-commit reminders.
○​ Scheduled repository backups to prevent data loss.
○​ Integration with crontab for periodic commits.
4.​ Logging
○​ Generate human-readable logs for CVS repositories.

Technology:
●​ Language: Ruby
●​ Database : SQL
●​ OS: Linux (Ubuntu, Fedora, Arch, Debian)
Q7. Traffic Violation & Fine Management System

Domain: Road Safety​

Concepts Used: Web App, SQL, C++, Data Structures, OOP

Project Description:

A web-based system that tracks and manages traffic rule violations, maintains fine records,
and allows users to pay fines online.

Features & Implementation Details:

1. Violation Database Management:

• SQL stores data on registered vehicles, owners, and fines.

• C++ program processes violations using trie data structures for fast license
plate lookups.

2. Fine Calculation & Payment System:

• Violations are classified (speeding, wrong parking, etc.), and fines are
calculated.
• Stack-based transaction log maintains a record of payments and reversals.

3. User & Authority Dashboard:

• Users can check their violations and pay fines via a Flask/Django web app.

• Authorities can update records and approve payments.

Q8. Healthcare Appointment Scheduling System

Domain: Healthcare Management​

Concepts Used: Web App, SQL, C++, Data Structures, OOP

Project Description:

A web-based system that allows patients to book, reschedule, and manage medical
appointments while maintaining waiting lists, provider schedules, and real-time
notifications.

Features & Implementation Details:

1. Appointment Booking System:

• SQL database stores available slots, booked slots, and patient details.
• Binary search tree (BST) optimizes searching for the next available slot.

2. Waitlist Management:

• Priority queue ensures patients with urgent needs get slots first.
• SMS/email notifications alert patients when a slot opens.

3. Healthcare Provider Schedule Optimization:

• Graph representation of time slots helps ensure non-overlapping bookings.

• Doctors' schedules are dynamically updated.

4. Security & Compliance:

• Role-based authentication (RBAC) restricts access to patient records.

• Encryption (TLS/SSL) secures all data exchanges.

Q9. Email Notification System for Internet Speed Monitoring

Project Overview

The "Email Notification" system is designed to track internet speed throughout the month
and send an email notification to the internet service provider at the end of each month.
The email contains a report on how many times the internet speed dropped below 5 Mbps
each day.

Key Features & Implementation Details

1. Internet Speed Monitoring

●​ The system continuously checks the internet speed at regular intervals using a
speed test tool (speedtest-cli).
●​ If the speed falls below 5 Mbps, the system logs the time and date of the incident.

2. Data Storage & Processing

●​ The system stores daily logs of internet speed drops in a database or a local file.
●​ At the end of the month, it aggregates the data to calculate the total occurrences for
each day.

3. Email Notification System

●​ The system generates a summary report of internet speed drops for the entire
month.
●​ Using Spring Boot and JavaMail API, it automatically sends an email to the internet
service provider.
●​ The email includes:
○​ The total number of times the speed dropped below 5 Mbps for each day.

○​ The worst-performing days with the highest number of slow-speed

occurrences.

4. Scheduling & Automation

●​ A scheduled job (using @Scheduled in Spring Boot) triggers the email at the end of
each month.
●​ The system runs in the background without manual intervention.

Technology Stack
 ●​ Programming Language: Java (Spring Boot)
●​ Email Service: JavaMail API (SMTP)
●​ Speed Test Tool: speedtest-cli
●​ Database: MySQL or local file storage (CSV, JSON)
●​ Scheduler: Spring Boot @Scheduled for automation

Q10. Employee Directory Management System

Project Overview

This system models an organization’s employee hierarchy using a graph-based structure,

where each employee is connected to their respective manager. It allows managing
employees, updating hierarchies, and retrieving reporting paths efficiently.

Key Features & Implementation Details

1. Employee Hierarchy Representation (Graph Using HashMap)

●​ Stores employee-manager relationships using an Adjacency List (HashMap of Lists).

●​ Enables fast lookups and modifications in the organizational structure.

2. Add, Update & Remove Employees

●​ Adding Employees: Employees are stored with ID, name, and manager ID.
●​ Updating Manager: The employee’s manager can be updated in the graph.
●​ Removing Employees: If an employee is removed, their subordinates are assigned to
their manager.

3. Find Reporting Path to CEO (Using BFS)

●​ Retrieves the shortest path from a given employee to the CEO.

●​ Ensures quick lookups even for large organizational structures.
4. Find Direct Reports of a Manager

●​ Fetches all immediate subordinates of a given manager.

●​ Useful for viewing team structures.

Q11. Secure Remote Command and Audit System (RPC + SQL + Linux Security)

Problem statement: Design and implement a Secure Remote Command and Audit System
that allows users to execute commands on remote Linux machines securely through RPC
(Remote Procedure Calls). The system should authenticate users, validate commands for
security, and log all actions and results into an SQL database for auditing purposes. The
goal is to provide a robust platform for remote administration while ensuring
accountability and traceability of all actions.

Functional Requirements:

1)User Authentication & Authorization:

· User Authentication: Users should authenticate with a secure username and

password system.

· Role-Based Access Control (RBAC): Different roles (e.g., admin, user) should have
varying levels of access to commands. Admins can execute all commands, while users
have restricted access to predefined commands.

2)Remote Command Execution:

· Command Execution via RPC: Implement an RPC service that will accept user
commands, execute them on the target remote Linux machine, and return the results.
Commands can include administrative tasks such as creating files, listing directory
contents, or checking system health.

· Command Validation: Validate and sanitize commands to prevent command injection

attacks and unauthorized actions. Only allow safe commands to be executed.

3)login and Auditing:

· Action Logging: Log all executed commands, including user information, timestamp,
and the results (success or failure).

· Audit Trail: Store logs in an SQL database. Logs should capture:

 o User who executed the command
o Command issued
o Timestamp of execution
o Execution status (success or failure)
o Output of the command or error messages

· Allow administrators to query the logs for auditing purposes.

4)Command Restrictions:

· Whitelisting: Only a predefined set of safe commands (e.g., ls, cat, uptime) can be
executed by non-admin users. Admins can execute any Linux command, including
potentially dangerous ones (e.g., rm, shutdown).

· Blacklist Dangerous Commands: Restrict commands that can cause harm, such as file
deletion or system shutdown, unless explicitly authorized.

5)SQL Database Schema:

Create tables for managing users, commands, and audit logs

Use Cases:

1. User Login:

a. Input: Username and password.

b. Action: Authenticate user. If successful, issue a token for subsequent
RPC calls.
c. Output: Token for further authenticated actions or failure message.

2. Execute Command:

a. Input: Command name, parameters, and token.

b. Action: Authenticate using the token. If the user is authorized to run the
command, execute it on the remote machine.
c. Output: Command result, status, and output logged in SQL database.

3. Audit Command Logs:

a. Input: Query parameters (e.g., username, date range).

b. Action: Retrieve and display command logs from the command_logs
table for auditing.
 c. Output: List of commands executed, including the user, command,
status, and output.

4. Failed Login Attempts:

a. Input: Username and password.

b. Action: Log failed login attempts in the login_attempts table.
c. Output: Alert if multiple failed attempts are detected.

Q12. FTP File Backup and Remote Execution via Telnet

Problem Statement: The goal of this project is to develop a system that automates the
process of file backup to a remote FTP server and then verifies the integrity of the backup
through a remote script execution using Telnet. This system will automate the backup and
verification processes for remote servers, reducing human intervention and ensuring the
success of file backups.

The system needs to:

1. Upload a file from a local machine to a remote FTP server.

2. Execute a verification script on the remote server using Telnet to confirm the success
of the backup.

3. Handle successful and failed backup scenarios effectively and generate relevant
messages.

This system can be used for automating backups in environments where files need to be
uploaded to an FTP server regularly, and there is a need for validation or monitoring after
the backup is performed.

Functional Requirements:

1. FTP Upload Functionality:

a. The program should allow the user to specify a local file that will be
uploaded to an FTP server.
b. It should establish a connection to the remote FTP server, log in using
the provided username and password, and upload the specified file.
c. It must handle file uploads securely (basic FTP is acceptable for
simplicity, but FTPS/SFTP is recommended for security in a real-world
scenario).
 2. Telnet Verification:

a. After the FTP file upload, the program should connect to a remote server
via Telnet.
b. Once connected, it should execute a script (e.g., verify_backup.sh) that
checks if the uploaded file exists or meets specific conditions (e.g., file
size or checksum).
c. The Telnet session should handle success or failure cases based on the
output of the verification script.

3. Feedback:

a. The program should output messages indicating whether the FTP upload
and the Telnet verification succeeded or failed.
b. Appropriate error handling should be incorporated to handle cases like
incorrect login credentials, server unavailability, or file not found on the
remote server.

4. Logging and Monitoring :

a. The program could generate a log file with the results of the FTP and
Telnet operations (including timestamps, file upload status, and
verification results).

Use Case:

1. A company regularly backs up configuration files to a remote server.

2. After the file is uploaded via FTP, the system verifies the presence and integrity of the
backup using a Telnet command to run a script on the remote server.

3. If the verification fails, the system alerts the administrator.