Alva Coding Test: Work in the GitHub Repository and Verify Your Submission

You can finish an Alva coding task locally and still leave the assessment incomplete. Your change may exist only on your laptop, the pull request may target the wrong branch, or your assigned Alva workflow may require a separate submission action. Treat those as distinct outcomes to verify.

An Alva coding test is repository work. Prepare to read the task, run the starter project, make a focused change, and leave evidence another engineer can review. The invitation, repository README and actual assessment screen define your assignment. This matters because Alva's current official help pages describe different timing and submission flows.

Evidence boundary: this is a provider-workflow guide based on Alva and GitHub documentation. Research did not establish two independent same-cycle candidate reports, so it makes no employer-specific question, duration, cutoff or scoring prediction. The mini-project below is original practice, not an Alva task. Rehearse unfamiliar-codebase reasoning with Debug Search and Stock Behavior in a Library Application.

Identify your Alva coding test flow before starting

Official sources agree that the task is accessed through GitHub and that candidates should read its instructions. They do not currently present one consistent timer description. Do not choose the description you prefer and assume it applies to your invitation.

Official help page	Timing and submission description	What to verify in your assignment
Starting and Submitting Your Coding Test	Describes no in-app timer; README defines delivery, commonly a PR; return to Alva and check Completed.	Repository instructions and the actual assessment status.
Candidate Experience for Coding Tests	Describes optional timed tests, a nonpausable timer starting at Start Coding test, an unmerged PR and Submit Results.	Whether a timer and separate submission control appear in your assigned flow.

The practical inference is to resolve the assignment's start trigger before pressing it. Confirm GitHub access and your chosen environment first. If instructions conflict with the screen, ask the hiring contact or Alva support for clarification before starting a timed attempt. A preparation guide cannot determine which configuration your employer selected.

For the timed flow, Alva says committed code is shared for review if time expires, and later submissions are marked late with their lateness visible to the hiring team. That is a fallback behavior described by that source, not a reason to rely on expiration instead of deliberate submission. Neither official page establishes a universal hiring pass mark.

Also distinguish the coding test from Alva's logic test. Preparing matrix patterns does not prepare repository setup, application behavior, or a code-review discussion.

Establish GitHub access and the correct starter branch

Before the assignment, make sure you can sign into the intended GitHub account and perform an ordinary clone, commit and push in your own practice repository. This is a logistics rehearsal; do not start a real timed test merely to inspect its files.

Official Alva setup guidance recommends a preconfigured starter project and GitHub Codespaces. The hiring team can restrict the available stack; a general list of supported languages does not guarantee a free choice in your invitation. Follow the branch created for the starter project and complete the repository access invitation as directed. Alva codebase setup

A local environment can also work when the assignment allows it and you know how to configure it. Record runtime versions, install dependencies from the provided manifest, and use the project's documented commands. Avoid replacing the starter with a preferred framework before establishing what the evaluator expects.

Read the repository identity carefully: owner, repository name, branch, and task description. A public boilerplate repository may help you understand a stack, but it is not automatically the private repository assigned to you. Alva's public GitHub organization contains multiple starter projects; their presence does not reveal your employer's task.

The baseline goal is modest: understand the files, reproduce the current behavior, and know where the change belongs. If the project cannot start, record the exact failing command and error. Separate environment setup from a functional defect before rewriting code.

Turn the README into an acceptance contract

Read the delivery instructions before implementing the feature. Translate the README into observable outcomes: inputs, outputs, persistence, error behavior, supported environment, and submission steps. When a detail is unspecified, identify the assumption instead of silently inventing a requirement.

Alva's employer documentation explains that organizations can customize duplicated tests, including their task repository and review scorecard. That is official evidence of configurable assignments. It does not tell you which rubric your hiring team uses. Coding Test Library customization

Here is an original practice assignment you can use independently: a small inventory API accepts an item identifier and quantity, returns the updated stock, and rejects negative quantities. A seeded defect allows two identical identifiers to appear as separate records. Your change must preserve the existing response shape and startup command.

Before coding, write five checks:

• A new identifier creates one record with the requested quantity.
• An existing identifier updates that record rather than creating a duplicate.
• Zero is accepted if the practice specification allows it.
• A negative quantity returns the specified error and leaves stock unchanged.
• Restart and persistence behavior follows the practice project's stated contract.

These checks distinguish a working feature from a attractive rewrite. If identifiers are case-sensitive, do not lowercase them as a convenience. If quantity means “replace stock,” do not implement “add stock.” Those decisions belong in the contract, not in an undocumented helper.

Build the smallest coherent implementation that satisfies the stated task. Avoid introducing authentication, deployment machinery, or a new database merely to make the project look more complete. Explain an omitted extension when it would affect the design, but deliver the required behavior first.

Preserve build, startup and automated-test boundaries

The evaluator needs to run your app. A correct handler is of little use if the expected build script is missing or the test runner points to a different port.

For its documented manual setup, Alva identifies root build/start scripts and Cypress configuration as important integration points: backend apiUrl and frontend baseUrl must correspond to the actual application endpoints. It also warns that the GitHub Actions environment can differ from local setup. Apply these instructions when those files and that workflow exist in your assigned repository; do not transplant an old Cypress configuration into a different test harness. Alva setup instructions

In the inventory rehearsal, verify the documented start command without depending on an IDE's hidden configuration. Then run the supplied tests and your focused regression check. If the project uses environment variables, explain required variable names and safe example values; keep credentials outside the repository.

A useful verification log records the command, result, relevant runtime version and tested commit. “Tests pass” is weaker than “the duplicate-ID regression and supplied suite pass on this revision.” If a dependency or remote service blocks a check, state the unverified boundary instead of describing the entire project as tested.

Do not weaken assertions, remove test files, or rename evaluator-facing interfaces just to obtain a green indicator. A failure can reveal either a defect or a misunderstanding of the contract. Trace it to the requirement, then change the implementation or document the unresolved ambiguity.

Make the final change reviewable

A pull request is a comparison between branches. Check its base and head branches and read the entire diff before presenting it. GitHub's documentation explains how the comparison and PR creation work; those general mechanics do not replace the assessment's repository instructions. Creating a pull request

For your own rehearsal repository, these read-only commands help inspect the work:

git status --short
git branch --show-current
git log -1 --oneline
git diff --stat
git diff --check

They expose different evidence. A clean working tree does not prove the right commit reached the remote. An empty unstaged diff does not prove a pull request contains the intended changes. Inspect the GitHub comparison after pushing and confirm that the remote commit matches the one you tested.

Keep the PR description short and concrete. For the original inventory project, a useful description explains the duplicate-record trigger, the resulting single-record behavior, and the checks run. Add a trade-off only if it affects the implementation: for example, an in-memory index accelerates lookup but must be rebuilt when stored records load.

Be ready to explain every changed line. If AI assistance is permitted, inspect and test its suggestions like any other proposed code. If the rules are silent, verify permission; repository-based work does not itself authorize outside assistance. Do not upload private assessment material to an unapproved service.

Verify three separate completion checkpoints

The following original ledger helps distinguish code completion from delivery completion. It is a preparation aid, not a screenshot or promise about every Alva interface.

Checkpoint	Evidence to inspect	What it does not establish
Local behavior	Required commands and focused tests on the final revision.	That the hiring team can access your work.
Remote review	Expected commit and diff in the assigned repository; PR when required.	That a separate Alva submission action happened.
Assessment completion	Required submission steps finished and the assigned status checked.	A passing score or an offer.

Follow the specific README delivery steps. In the flow that requires a PR and Submit Results, leave the PR unmerged and complete the separate Alva action. In the guide that directs README-based delivery, return to Alva and verify Completed. If the status does not update, recheck the required steps and use support with the repository/PR reference and the visible status.

Do not repeatedly create PRs or merge the work to force a status change. First determine whether the existing PR points to the intended branch and whether the platform expects another action. Preserve a concise record of the final commit, PR and completion screen for your own follow-up, while respecting assessment confidentiality.

Sources and Further Reading

• Alva: Starting and Submitting Your Coding Test
• Alva: Candidate Experience for Coding Tests
• Alva: How to set up the codebase
• Alva: Coding Test Library customization
• Alva Coding Tests public GitHub organization
• GitHub: Creating a pull request

Research checked October 4, 2026. Official help pages describe differing flows; verify your own invitation, README and assessment screen. No same-cycle employer process is claimed.