Repository-based questions: what they are and how to practise them

By Bhimana Sai Pradeep · Published 22 October 2026

Bugnik is an independent practice site. It is not affiliated with Amazon, HackerRank or any employer, and its problems are original, written in the same format. This guide is based on the public sources listed at the end.

In short: a repository-based question (also called a repo-based or code repository question) gives you a whole multi-file project instead of a single function to write. You read the README, run the tests, then fix the bugs or finish a feature so the tests pass, usually against a clock and usually in a browser IDE. Part of the grading often uses tests you can't see.

These questions now appear in online assessments (OAs) alongside algorithm questions. The best-known example is the code repository question in the Amazon OA, which runs on HackerRank. This guide covers the format in general: what you get, how it's scored and a way of working that holds up under time pressure.

What you get

• A repository: several source files, often a web API or service in a mainstream framework. HackerRank's 2026 library mentions MERN, Node.js, Django and Spring Boot projects.
• A README: what the system does, the rules it must follow and your task. HackerRank tells candidates to start there.
• Read-only files: usually the tests and build files. You must not change them; the fix goes in the application code.
• A Run Tests button: runs the tests you're allowed to see, as often as you like.
• Autosave and resubmission: on HackerRank your latest saved code counts, and you can resubmit until time is up.

Bug fixing vs feature building

HackerRank lists two kinds of code repository task:

• Bug fixing: the project builds (or almost builds) but behaves wrongly. Some tests fail; your job is to find the lines that disagree with the README and correct them without breaking anything else. Several bugs are usually seeded in one repository.
• Feature building: a function, endpoint or rule is missing or stubbed out. The README says what it must do; you implement it in the style of the code around it.

How repository-based questions are scored

Scoring is done by tests. In HackerRank's task setup, each task has a test_command (what runs when you click Run Tests) and a separate scoring_command (what produces your score). Because the two can differ, don't assume the tests you can see are everything that will be checked. Hidden tests typically probe the edges the README describes: boundary values, empty input, duplicates, ordering and error codes.

That has a practical consequence: a fix that makes a visible test pass by special-casing its input will fail the hidden ones. Fix the rule, not the example.

A debugging loop that works under time pressure

1. Read the README first. Note every rule with a number or an edge in it (“inclusive”, “at least”, “must be unique”). Those are where bugs hide.
2. Run the tests before changing anything. A build error comes first, because it blocks every test. Then list the failing test names.
3. Take one failure at a time. Read the test: what input, what expected output. Follow the call into the code instead of reading the whole repository.
4. Find the disagreement. Compare the line you land on with the README rule. Make the smallest change that makes them agree.
5. Run all the tests again. A fix can break another test, and some failures share one cause.
6. When everything visible passes, go back to the README edges and check them yourself before submitting.

A short example

A made-up warranty-claims project (the same one shown on Bugnik's home page) has a rule in its README: a claim is covered if it is filed within the coverage period, including the last day. One test fails:

Coverage.LastDayIsCovered   expected true, got false

The test calls Warranty::covers, which ends with:

int days = daysBetween(purchased, claim.filedOn);
return days < coverageDays_;

“Including the last day” means <=, not <. One character, found by reading the test name, the README rule and one function, not the whole project. Most repository bugs look like this: small, local and contradicting a rule written down somewhere.

Bugs that come up again and again

• Boundary comparisons: < vs <=, off-by-one loops.
• The wrong field or variable: two similar names, and the code uses the other one.
• Integer division where a percentage or average needs decimals.
• Missing null, empty or not-found handling, so the API returns the wrong status code.
• An error mapped to the wrong HTTP status code.
• Build errors: a missing import, a changed method name, a header and source file that disagree.
• Copying a value instead of updating the original, so a change is lost.

Checklist before you submit

• The project builds and every visible test passes.
• You re-read each README rule with an edge in it and checked the code for it.
• You didn't edit tests, the README or read-only files.
• No fix depends on a specific test's input.
• Your last change is saved.

Where to practise repository-based questions

Algorithm sites train a different skill. To practise this one, you need multi-file projects with real tests and a clock. Bugnik's practice problems are exactly that: C++ and Spring Boot repositories with seeded bugs or a feature to finish, visible tests in the browser and hidden tests on submit. A good first one is the delivery slot scheduler in C++ or the inventory reservation API in Spring Boot; for a feature-building task, try the pickup locker network.

Sources

• Code Repository Questions (HackerRank knowledge base) (task types and the hackerrank.yml task fields)
• Preparing for your Amazon OA (HackerRank candidate knowledge base) (README, read-only files, Run Tests, autosave and resubmitting)
• January 2026 release notes (HackerRank) (stacks used in code repository assessments)