What we collect, why, who else touches it, how long it is kept, and how to get it back or get rid of it.
Last updated 5 August 2026
codetest.dev is operated by Alberich Labs LLC, 418 Broadway, Ste N, Albany, NY 12207. You can reach us at support@codetest.dev.
In this policy "we" and "us" mean Alberich Labs LLC, the company you contract with and the one responsible for the commitments below. "codetest.dev" is the service we operate, and the domain your email and receipts come from.
Two different sets of people have data here, and our responsibilities to them are not the same.
Customers are the people who sign up, create an organisation and run assessments. We decide how their account data is handled, and this policy is our commitment to them directly.
Candidates never sign up. They open a link a hiring team sent them and write code. That hiring team decides to collect a candidate's work, what it is used for and how long it is needed; we run the software that collects it, on their instructions. In data-protection terms the hiring organisation is the controller, and Alberich Labs LLC — operating codetest.dev — is the processor acting on that organisation's behalf. Practically: if you are a candidate, the team who invited you is the right first place to send a question about your data, and we will act on what they ask us to do.
From customers, when you create an account: your name, your email address, a hashed form of your password, and the name of your organisation. If you subscribe, Stripe holds your payment details and we hold only the identifiers that let us ask Stripe about your subscription.
From candidates, while an assessment is in progress: the name and email address the hiring team entered on the invite, snapshots of the code as it is typed, each submission and its results, and two activity signals — when the candidate pastes into the editor, and when they switch away from the tab.
That is the complete list of what is captured about a candidate. There is no webcam, no screen recording, no keystroke capture and no lockdown browser, and nothing runs on a candidate's machine outside the browser tab they opened.
We do not use third-party analytics or advertising trackers. The only cookies we set are the ones that keep a signed-in customer signed in.
Customer data exists to run the account: to sign you in, to keep your organisation's work separate from everyone else's, to bill you, and to send you the messages the product owes you.
Candidate data exists to run the assessment the hiring team set, and to show that team the result. Code snapshots mean nothing is lost if a laptop dies mid-assessment. Paste and tab-switch events are shown to the reviewer as context beside the code — they are not a score, and nothing in the product decides anything on their basis.
We do not sell data, and we do not use anyone's code or submissions to train models.
How long candidate code, submissions and activity events are kept is set by the hiring organisation that invited the candidate, because that organisation decides what to collect and why. They may choose any period between 3 months and 24 months, or to keep it indefinitely; 12 months is what applies unless they change it.
Every candidate is told what applies to them, by name, on the screen they accept before starting — including when the answer is that their work is kept indefinitely — and that choice is recorded against their assessment, so a later change to the setting does not alter what they were told. Where a period is set, a scheduled job deletes the code, the submissions and the activity events together once it elapses. Deletion is permanent and there is no recovery.
Data belonging to a customer account is kept for as long as the account is open. When you close it, everything that identifies you is destroyed immediately — not at the end of some window: your name, your email address, your avatar, your password and your two-factor credentials, along with your membership of every organisation. What is left behind is an emptied record with nothing in it that points to you, and we keep that indefinitely. It exists so that the interview scorecards and sessions you wrote stay attached to your organisation's hiring record, where your colleagues' notes sit beside yours and still make sense; they need an author to point at, and that record is what they point at. This is described in full under "Closing an account" below.
A hiring team can withdraw or archive an assessment at any time, which stops the link working immediately. That hides the work; it is not a deletion.
Alberich Labs LLC uses four other services to run codetest.dev. Each of them processes data only to provide the service described, and none of them is given data for their own purposes.
The database — the system of record for everything the product stores — runs in the United States, in Amazon Web Services' us-east-2 region, operated by Neon. We have not selected a storage region for Vercel, Stripe or Resend; each handles the data described above on its own infrastructure and under its own terms. If your organisation needs data held in a particular jurisdiction, ask us before you sign up: today the answer is the United States, and we would rather tell you that plainly than let you discover it later.
| Service | What we use it for | What it holds |
|---|---|---|
| Neon | Hosts the Postgres database the product runs on. | Everything the product stores: accounts, organisations, assessments, candidate code, submissions and activity events. |
| Vercel | Hosts and serves the application, and runs submitted code in an isolated sandbox at grading time. | Request logs, and the candidate's submitted code while it is being graded. |
| Stripe | Takes payment for subscriptions. Card details go to Stripe and never reach us. | Customer billing name, email and payment details. No candidate data. |
| Resend | Delivers the product's email — invites, password resets and account notices. | Recipient name and email address, and the contents of those messages. |
A customer can close their own account from Settings, without asking anyone. When you do, your name, email address, avatar, password and the identifier linking you to Stripe are destroyed, your organisation memberships and any two-factor credentials are removed, and every signed-in device is signed out immediately.
What is not destroyed is the emptied record itself: your account is anonymised rather than removed outright. Interview scorecards and sessions you created stay with the organisation you created them for — that is your team's hiring record, not yours alone — and they need an author to point at, so past work shows as written by a former member rather than by you. There is nothing left in that anonymised record that identifies you.
One thing can stop you: if you are the only owner of an organisation, closing your account would leave it with its data, its members and nobody able to administer it. Hand ownership to someone else or archive the organisation first, and then you are free to go.
Candidates have no account to sign in to, by design, so there is a separate route: the link on the screen you see when you finish, and in your invite email, or /data-request directly. Ask for a copy of your data or ask for it to be deleted; the request goes to the hiring team who invited you, because under the roles described above the decision is theirs, and we carry out what they instruct.
If either route does not work for you, write to support@codetest.dev and a person will read it.
Passwords are stored hashed, never in a readable form. Traffic is encrypted in transit. Every query the product makes is scoped to a single organisation, so one customer's data is not reachable from another's account. Organisations can require two-factor authentication for all of their members.
We hold no security certification and do not claim one. If a security review is part of your buying process, ask us and we will tell you plainly where things stand.
If this policy changes materially we will tell customers by email before the change takes effect. The version a candidate was shown when they accepted an assessment is recorded against that assessment and is not rewritten by a later edit.