DevQuiz

Overview

DevQuiz was built by an international group of Codecademy community members who wanted to practice collaborative software development.

Around five or six developers contributed at different stages, with the final phase continuing with a smaller group of three. The application is intentionally focused so the team could practice defining requirements, coordinating implementation, reviewing pull requests and delivering a shared product.

Problem

DevQuiz gives developers a simple way to practice programming concepts through short, timed quizzes. Users select a topic, answer a fixed number of questions and receive immediate feedback and a final score.

The team also needed a shared definition of the MVP, application behavior, feature dependencies and implementation tasks. That structure made it possible for contributors with different levels of experience and availability to work on the same product.

Solution

DevQuiz provides a quiz flow based on programming topics. After a user selects a topic, the application prepares a validated set of questions and starts a timer. The user receives feedback after each answer and sees the results when the quiz ends or time expires.

The team kept the scope small to deliver a complete MVP within the collaborative project timeline.

Key Features

• Programming-topic selection and timed quizzes.
• A fixed number of randomized questions and answers.
• Immediate answer feedback and score calculation.
• Results and quiz exit flows.
• QuizAPI integration with local fallback quizzes.
• API response normalization and validation.
• Loading and error states.
• Keyboard-accessible answer interaction.
• Responsive UI based on a Figma design.
• Vercel Serverless Function proxy for protecting the external API key.

Technical Approach

DevQuiz is a React frontend built with Vite. Application state controls the three main screens—topic selection, quiz and results—so the project does not need React Router.

Questions come from QuizAPI. Responses are normalized and validated before they reach the quiz interface, and local fallback data keeps the core flow available when the external API fails or returns too few valid questions.

The frontend calls a Vercel Serverless Function instead of QuizAPI directly. The proxy keeps the external API key out of the browser while preserving the lightweight frontend architecture.

The interface follows a custom Figma design and uses global styles, CSS variables and CSS Modules. Semantic controls and keyboard interaction were included during implementation to support accessibility.

My Contributions

I helped turn the product idea into a plan the team could implement and review.

My contributions included:

• Structuring the overall project.
• Defining the PRD.
• Creating the development roadmap.
• Translating ideas into concrete features and requirements.
• Defining expected application flows and behavior.
• Considering implementation implications before features were accepted into scope.
• Reviewing pull requests against the agreed documentation.
• Providing technical and product feedback during reviews.
• Implementing parts of the application logic.
• Implementing the Vercel backend proxy.
• Contributing to API response handling and validation decisions.
• Participating in accessibility and UX decisions.
• Helping keep the project within the agreed MVP scope.

I evaluated proposed features against the product scope, their technical implications and their effect on existing application flows.

Engineering Decisions

Defining the project before implementation

The team documented application behavior and the roadmap before dividing the work. This created a shared reference for implementation tasks and pull request reviews.

Keeping navigation local

The application has a short, linear flow and does not need independent URLs for each screen. Application state and conditional rendering handle navigation without adding React Router.

Protecting the API key with a serverless proxy

Calling QuizAPI from the browser would expose its API key. A Vercel Serverless Function acts as a small proxy, keeping the credential on the server without requiring a separate backend application.

Validating external API data

QuizAPI responses are normalized and validated before they reach the quiz screen. Only questions with the structure required by the application continue through the preparation flow.

Adding local fallback quizzes

Local fallback quizzes keep the core experience working when QuizAPI fails or returns too few valid questions. They improve MVP reliability but create a second question dataset to maintain.

Accessibility as part of the interaction model

Answer options use appropriate semantics and keyboard interaction in addition to mouse interaction. Including these requirements during implementation avoided redesigning the quiz controls later.

Custom visual system

The interface follows a custom Figma design. Shared CSS variables and global values keep the visual language consistent while CSS Modules scope styles to individual screens.

Challenges

The main challenges were keeping the MVP focused and coordinating contributors with different levels of experience, availability and development pace.

Feature ideas were evaluated according to their implementation impact and relevance to the current milestone. The project also reinforced that AI-assisted development requires developers to understand the code they introduce so others can review, integrate and maintain it.

What I Learned

DevQuiz gave me practical experience reviewing other developers’ work and writing feedback that was specific, actionable and constructive.

I also learned how to write specifications with enough detail to remove ambiguity without prescribing every implementation decision. Keeping the project moving required deciding which features mattered for the current milestone and postponing the rest.

Most importantly, the project strengthened my ability to translate product ideas into engineering considerations such as state, components, APIs, edge cases, accessibility and testing.

Future Improvements

A future version could replace QuizAPI and the local fallback dataset with a dedicated DevQuiz backend that owns the question data.

This would give the application control over question quality and structure, remove the external availability dependency, simplify normalization and validation, and provide a stronger foundation for new topics or quiz modes. The current architecture is appropriate for the MVP; owning the data would be the next step if the project grows.