How to Write a Coding Assignment That Earns Full Marks

A coding assignment is marked on more than whether the program runs. Most briefs also assess readability, testing, documentation and a short written explanation of your approach.

This page shows how to write a coding assignment from specification to submission: the parts of a complete submission, a step-by-step process, an example function with tests, a README outline and a checklist.

Structure of a Coding Submission

How to Write a Coding Assignment, Step by Step

1. Read the specification twice. List every required feature, input format, output format and constraint. Note anything ambiguous and ask early.
2. Plan before coding. Sketch the main functions or classes, and write pseudocode for the tricky parts.
3. Build in small steps. Get the simplest version working, commit it, then add features one at a time.
4. Test as you go. Write a test for each function as soon as it exists, including edge cases.
5. Refactor. Rename unclear variables, split long functions and remove dead code.
6. Document. Add docstrings, comments that explain why, and a README.
7. Write the report. Explain design choices, complexity, testing and limitations.
8. Test on a clean setup. Run the instructions from your README exactly as a marker would.

Writing Readable Code

Readable code is part of the mark on most modules, and it makes your own debugging easier. Use descriptive names, keep functions short and do one job per function.

def binary_search(arr: list[int], target: int) -> int:
    """Return the index of target in sorted arr, or -1 if absent.

    Time: O(log n). Space: O(1).
    """
    lo, hi = 0, len(arr) - 1
    while lo <= hi:
        mid = (lo + hi) // 2
        if arr[mid] == target:
            return mid
        if arr[mid] < target:
            lo = mid + 1
        else:
            hi = mid - 1
    return -1

Comments should explain why, not what. "Increment i" adds nothing; "use a heap so each insertion is O(log n) rather than O(n)" tells the reader about a design decision.

Testing: Normal, Edge and Error Cases

Markers look for tests that would catch real faults. Cover typical input, the boundaries and invalid input, not just the example in the brief.

def test_binary_search():
    assert binary_search([1, 3, 5, 7], 5) == 2    # found
    assert binary_search([1, 3, 5, 7], 4) == -1   # absent
    assert binary_search([], 1) == -1             # empty list
    assert binary_search([2], 2) == 0             # one element
    assert binary_search([1, 3, 5, 7], 7) == 3    # last element

Each line tests a different case, and the comments say which. Run them with pytest, JUnit or your language's equivalent, and include the command in your README.

Writing the README

The README is often the first thing a marker opens. It should let someone run your code without asking you a question.

• Project name and a one-line description.
• Requirements: language version and libraries, with a requirements file or equivalent.
• How to run: the exact command, with an example input.
• How to test: the command that runs the test suite.
• Input and output formats.
• Known limitations or unfinished features.

Writing the Report

The report explains the thinking that the code cannot show. Keep it focused and evidence-based.

• Design: the main components and why you structured them that way.
• Algorithm: how the core logic works, with pseudocode or a diagram if it helps.
• Complexity: time and space in Big O notation, with a one-line justification.
• Testing: what you tested, how and what you found.
• Reflection: limitations and what you would improve with more time.

Note the figure of 17: since 2¹⁷ = 131,072 is greater than 100,000, binary search needs at most 17 comparisons.

Using Libraries and Code from Elsewhere

Follow your module's rules on outside code. Where reuse is allowed, credit the source in a comment and in the report, and respect the license. Never paste in code you cannot explain; you may be asked about it.

Coding Assignment Checklist

• Every requirement in the specification is met and tested.
• Code runs from the README instructions on a clean setup.
• Names are descriptive; functions are short and do one job.
• Docstrings on public functions and classes.
• Tests cover normal, boundary and invalid input.
• Report covers design, complexity, testing and limitations.
• No leftover debug prints or commented-out code.
• Outside code credited where allowed.

How STEM Donkey Helps with Coding Assignments

Send the specification, any starter code, the language and version, the libraries you may use and the marking rubric. A writer matched to your topic prepares a custom solution: readable code, a test suite, a README and a short report covering design and complexity.

Use it to study a working approach and check your own work. The price is shown before you pay, and free revisions within the scope of your original request are available.