Skip to main content
CodeOath

Privacy policy · version 2026-09-29

Privacy Policy

Last updated: September 29, 2026

CodeOath (codeoath.in) is a product of Codzodd Technologies, a sole proprietorship of Juee Hem Mankad, registered in Ahmedabad, Gujarat, India (Udyam Registration No. UDYAM-GJ-01-0373494) ("we", "us"). CodeOath is a free public coding-practice and interview-prep platform — reference articles (the Blog), algorithm/SQL practice problems (Code Lab), and front-end component exercises (UI Challenges). It also offers CodeOath for Business, a paid candidate-assessment product for hiring teams, covered in section 10. This policy explains what data we collect and why.

Sections 1–9 describe the public learning site. There are no user accounts on the public learning site: you don't sign up, log in, or give us your name or email to use the Blog, Code Lab, or UI Challenges. Companies using CodeOath for Business do sign in, and their candidates take assessments through an emailed link — everything specific to that product, including proctoring and payments, is in section 10.

1. What we collect

  • Where analytics run. Analytics and advertising scripts run only on the public learning site. We do not run them on the assessment pages a candidate sees, or on the company dashboard and billing pages.
  • Basic site analytics, via Vercel Web Analytics: page views, referring site, approximate device type, and country-level location. This is aggregated and cookie-free — it doesn't build an individual profile of you or track you across other sites.
  • Analytics and advertising data, via Google Analytics and Google AdSense, gated by the same choice in the cookie banner shown on your first visit:
    • Accept — Google Analytics cookies track your activity on the site to help us understand usage patterns, and Google/its advertising partners may set cookies to serve ads personalized to your browsing activity.
    • Decline — Google Analytics sets no cookies and doesn't track your activity across visits. Google Analytics still receives a limited, cookie-free signal (the page address, approximate location and browser type), which Google uses only to give us aggregate usage counts. You'll still see ads (this is how the site stays free), but non-personalized rather than based on your activity elsewhere.
    • If you're visiting from the EEA, UK, or Switzerland, Google's own certified consent tool handles this instead, per GDPR/UK GDPR requirements, and takes precedence over the banner above.
  • Two small preferences stored only in your own browser (never sent to us): your ad/analytics-consent choice and your light/dark theme choice. Clearing your browser's site data for codeoath.in removes both.
  • Abuse prevention. When you run TypeScript, Python, C#, Java, Go, Rust or C++ code in Code Lab (or the sample question at /try), or send the contact form or a Custom Plan enquiry, we keep a hashed (not readable) form of your IP address for up to an hour, only to limit how many requests one visitor can make.
  • Contact and enquiry forms. If you write to us through the contact form, we receive your name, work email and message, and — if you choose to add them — your company, role and team size. If you send a Custom Plan enquiry, we receive your name, work email, company name, what you need, and your phone number if you choose to add it. Either way, we receive it by email at contact@codeoath.in, delivered through our email provider (Resend), use it only to reply to you and follow up your enquiry, and keep it for up to 3 years, in line with how long we keep other correspondence.
  • Code you write in Code Lab, UI Challenges, or the sample question at /try: JavaScript, SQL, and UI Challenge exercises run entirely inside your own browser — your code is never transmitted to us or stored anywhere. Where TypeScript, Python, C#, Java, Go, Rust or C++ execution is available, your submitted code is sent to our server solely to compile and run it against that problem's tests and return the result; it's processed transiently for that one request and not logged or stored afterward.

On the public learning site we don't require or collect your name, email, or any account information, because there's nothing there that needs one — apart from the contact and enquiry forms above, if you choose to use them.

2. Why we process this data

  • Vercel Web Analytics: our legitimate interest in understanding how the site is used, kept to aggregated, non-identifying data. This one isn't optional since it doesn't use cookies or identify you individually.
  • Google Analytics and advertising: your consent, given (or declined) via the cookie banner, or via Google's consent tool where that applies.

3. Who we share it with

  • Google (Analytics, AdSense, and Funding Choices), to measure site usage, deliver ads, and manage related consent, under Google's own privacy policy: policies.google.com/privacy.
  • Vercel, our hosting and analytics infrastructure provider, under Vercel's own privacy policy.
  • Contabo, a virtual-server hosting provider: we run our own code-execution server on a virtual server rented from Contabo and administer it ourselves. TypeScript, Python, C#, Java, Go, Rust or C++ code that is submitted for running or grading is processed there for that one request and deleted afterwards.

We don't sell your data, and we don't share it with anyone for their own marketing purposes.

4. Where data is processed

Vercel and Google both operate global infrastructure, so data may be processed outside India (including in the US and EU) as part of their standard operations. The same applies to the providers used for CodeOath for Business (Supabase, Resend, Razorpay, Zoho Books — our Zoho account is hosted in the US — and Cloudflare, whose bot check runs on the company sign-in form). Code execution for grading runs on a server we operate ourselves.

5. How long we keep it

Vercel Web Analytics data is retained per Vercel's standard retention window; Google Analytics data (when you've accepted) is retained per Google's default retention settings. Your ad/analytics-consent and theme preferences live only in your own browser until you clear them — we don't hold a copy. We don't retain any other personal data from visitors to the public learning site, because we don't collect any. Retention for CodeOath for Business data is in section 10.

6. Your rights

Because the public learning site doesn't hold accounts or a server-side profile of you, most of what you'd normally ask us to access, correct, or delete simply isn't held anywhere on our end — clearing your browser's site data removes your local preferences directly, and Google's own ad settings (adssettings.google.com) let you control ad personalization directly with them.

For anything else — including rights you may have under India's Digital Personal Data Protection Act 2023 or, if you're in the EU/UK, the GDPR/UK GDPR — email contact@codeoath.in. We aim to reply to any message within 3 working days, and a formal request about your personal data (access, correction or deletion) is completed within 15 business days.

7. Cookies

Covered in §1 above. Companies that sign in to CodeOath for Business also receive a strictly necessary session cookie that keeps them signed in; it is not used for tracking or advertising. Two more short-lived, strictly necessary cookies help a company that is signing in get back to the right place: one remembers a plan it chose for up to an hour, the other remembers the page to return to for 15 minutes. Both are HttpOnly, and neither is used for tracking. See Google's own policy for how it uses advertising cookies: policies.google.com/technologies/ads.

8. Children's data

CodeOath is a general-audience coding education site and isn't directed at children under 13. We don't knowingly collect personal data from children; since the public learning site has no accounts or sign-up forms, none is collected from anyone in the ordinary course of using it. CodeOath for Business is intended for working-age job candidates and hiring professionals and is not directed at children.

9. Security

The site is served entirely over HTTPS, with security headers (including a Content Security Policy) applied site-wide. Code you write for JavaScript, SQL, and UI Challenge exercises in the public Code Lab runs sandboxed inside your own browser and never reaches our servers. In a company's assessment, the code a candidate submits is sent to our servers to be scored: JavaScript and SQL answers are run in isolated sandboxes there, and TypeScript, Python, C#, Java, Go, Rust or C++ answers run in an isolated environment for that single request and aren't persisted by the code-execution server. The connection between our web host and that code-execution server is encrypted (HTTPS) and authenticated with a secret token. The candidate's submitted answer is kept as part of the assessment record described in section 10.

10. CodeOath for Business (assessments, proctoring, and payments)

CodeOath for Business lets a hiring company ("company") build assessments and invite job candidates ("candidates") to take them. Two different groups of people are involved, and they relate to us differently:

For a candidate's data, the hiring company is the party responsible under applicable data protection law for why it is collected and how it is used (its Data Fiduciary, under India's DPDP Act) — it decides who to invite and why, and what to do with the results. We act on the company's instructions to run the assessment it built (its Data Processor), and we design the proctoring tools every company uses. Company users' own account data, billing records, and everything about the public learning site are ours directly — we're the party responsible for those.

  • Company users (recruiters and hiring managers) sign in to a dashboard.
  • Candidates never create an account. They receive an emailed invite link containing a unique, hard-to-guess token, and their attempt is tied to that link rather than to a login.

What we collect

From company users:

  • Name, email address, and company name, provided when signing in with Google, Microsoft, or an emailed one-time code.
  • Their role in the company (admin, member or reviewer) and, for admins, what the company is hiring for.
  • Invitation emails show the name and email of the company team member who sent them, and replies go to that person.
  • The assessments and custom questions they create.
  • A record of which version of our Terms of Service and Privacy Policy they accepted, and when.
  • Billing records: which plan was purchased, the amount and date, and payment references from our payment provider. We do not collect or store card, UPI, or bank details — see "Payments" below.

From candidates, once they open their invite link and choose to begin:

  • The email address the company invited, their answers to multiple-choice questions, and the code they write for coding questions, along with the scores calculated from them. Answers are also saved automatically every few seconds while the candidate works, so that a page reload or a lost connection does not lose them. A submission that arrives more than 2 minutes after the candidate's time limit (extended by any time the test was paused for a silent microphone) is recorded and shown to the company but is not scored. If an invite runs out of time before the assessment is finished, we email the candidate (and the company's admin) to say it has expired.
  • Camera and screen snapshots. While the assessment is running we capture a still image from the candidate's camera and a still image of their screen about every 30 seconds, plus one extra screen snapshot at each confirmed switch away from the assessment tab (up to 25 per assessment). These are periodic still images, not continuous video, and are reduced in size (about 480 pixels on the longest side). Because the whole screen is captured, anything visible on it, such as notifications or messages, can appear in an image, and candidates are asked to close private applications and switch off notifications first. Other people's voices or messages that are in the room or on the screen can be captured in the same way. The candidate must share their entire screen (not a single window or tab) and, where the browser makes this detectable, may have only one monitor connected.
  • Microphone check. Before a candidate's timer starts, they are asked to say a short sentence so their microphone can be checked. What they say is analysed in their browser and discarded, never sent to us; we perform no voice or speaker identification and build no biometric profile from it. We store only whether the check passed, was skipped, or wasn't run, and the microphone's sample rate.
  • Microphone monitoring. The candidate's microphone is analysed in their browser to detect sustained speech from anyone in the room, not just the candidate, and candidates are told not to read the questions aloud since the check cannot tell voices apart (a candidate who needs to read aloud or uses assistive technology is told to ask the hiring company for an accommodation first). Audio is held only briefly in the browser's memory and discarded; it is not continuously uploaded. Only if that check triggers is a short clip (roughly 8–16 seconds) saved for the company to listen to and judge for themselves. This is a volume-and-pattern heuristic, not speaker identification.
  • Microphone-silent periods. The candidate's browser also checks whether the microphone delivers any sound signal at all. This is separate from the speech check above and does not record or interpret what is said. If there is no signal for 30 seconds the test is paused and the attempt's timer stops until a signal returns (if the microphone was disabled or unplugged, the candidate has to press "Reconnect microphone" to resume, since reconnecting needs their own action); if the test has been paused for 5 minutes in total, the assessment ends and the attempt is marked as disqualified. We record when each pause began and ended and how long the test was paused, taken from our server's clock, and that the microphone had already had no signal for 30 seconds before the pause began. The company sees these as periods with no audio signal from the microphone, a signal for a person to review and not proof of misconduct (a muted headset and a faulty one look the same).
  • Tab switching. If the candidate switches away from the assessment tab, they get one warning and one screen image is captured at that moment (up to 25 per assessment). If they return within 10 seconds the assessment continues; if they stay away longer, or switch away a second time, the assessment ends and the attempt is marked as disqualified for the company to review. Every switch is recorded for the company, whether or not it led to a warning.
  • Paste attempts. Pasting into the code editor is blocked during an assessment. We record that an attempt happened and roughly how many characters, never the pasted content.
  • Consent record. When a candidate grants camera, screen and microphone access after clicking the button to begin, we record the time and the version of the consent notice they were shown.

Camera, screen, and microphone access are all required to begin an assessment. The candidate is told what is collected and why before any of them is requested, and cannot proceed without granting all three.

Why we process it

  • Company user data and billing records: to provide the service the company signed up for, and to keep accounting records.
  • Candidate answers and scores: to run the specific assessment the company built, on that company's behalf.
  • Proctoring data (snapshots, microphone check, microphone-silent periods, tab-switch and paste records): to help the company judge whether the person taking the assessment is who they say they are and is working under normal conditions. These are signals for a human at the company to review, not automatic proof of misconduct. Candidate consent is requested before any of it starts.

Who we share it with

  • The company that sent the invite — and only that company. Within the company, its administrators and its HR members can see a candidate's answers, scores and proctoring captures (camera and screen images and audio clips); the technical reviewers it adds can see answers and scores but never the camera, screen or audio captures. Our database enforces this at the row level: a company can only ever read its own candidates' data.
  • People the company chooses, through a share link. A company administrator can create a read-only link to a candidate's report and send it to people the company chooses, including people who do not have a CodeOath account, after confirming that it is entitled to share the report. The report shows the candidate's email address, the assessment name, the score and result, a short integrity summary and the candidate's answers. It never includes camera or screen images, audio clips, or the recruiter's notes or decision. The link expires (the company picks 7, 14, 30 or 90 days), the company can cancel it at any time, search engines are told not to index it, and we record only an approximate view count and when it was last opened. We also keep a record that a link was created and that the company confirmed it was entitled to share the report; that record holds only one-way codes of the invite and the link, and outlives the candidate's own data so we can show who shared what if there is a dispute. The company is responsible for who it shares a link with.
  • Supabase, our database, sign-in, and file-storage provider. Proctoring images and audio clips are kept in a private storage bucket, not a public one.
  • Resend, which delivers our invite, reminder, invite-expiry, and notification emails.
  • A code-execution server we operate ourselves, which compiles and runs candidates' code to grade it. Submitted code is used only for that grading.
  • Razorpay (payments) and Zoho Books (invoicing), for company purchases — see "Payments" below.
  • Cloudflare (Turnstile), a bot check on the company sign-in form. It receives the visitor's IP address and browser signals to decide whether they are a person, under Cloudflare's own privacy policy, and may process them outside India. It runs only on the company sign-in page, not on the public learning site or on candidate pages.
  • Vercel, our hosting provider.

We never sell candidate or company data, and we never use candidate data for anything beyond the assessment they were invited to.

Payments

Company purchases are paid through Razorpay. You enter card, UPI, or bank details on Razorpay's checkout, which handles them under its own terms and privacy policy; those details never reach CodeOath and we do not store them. We keep the resulting billing record (plan, amount, date, and Razorpay's payment reference). To issue an invoice for each payment we create a customer record in Zoho Books containing the company name and the account email address, and Zoho Books emails the invoice to that address.

How long we keep it

Candidate assessment data — answers, scores, proctoring snapshots and clips, the record of any microphone-silent pauses, and the record of when consent was given — is deleted automatically 180 days after the assessment is completed, by a scheduled nightly job. An invite that was never completed (for example, one that expired unused or was abandoned part-way), together with the candidate's email address and anything captured from a partial attempt, is deleted the same way 180 days after it expired.

Three days before candidate data is deleted, we email the company's admin so they can download the reports they need first. If we cannot deliver that email, we keep trying and hold the deletion for up to 7 more days, after which the data is deleted regardless. The company is responsible for exporting anything it needs, and for how it keeps and protects anything it exports. A company that erases a candidate's data itself, or asks us to, is not delayed by this. A company can delete its own candidates' data sooner at any time, either with the "Delete this candidate's data" button on the invite's page (available to the company's admin) or by asking us. This cannot be undone — we cannot recover data once it has been deleted, and it is the company's responsibility to keep whatever record it needs first, for example for a hiring dispute with that candidate. It removes the images, audio clips, answers, score, events and the invite itself, and never returns the invite to the company's allowance.

We keep a record that an erasure was carried out (who did it, when, and how many records) for as long as we keep our billing records. It holds no candidate address, only a one-way code made from it, so we can show a request was acted on without keeping the address. An erasure is refused, and nothing is deleted, if that record cannot be written. Deleting an assessment template does not delete the invites already sent from it, or the candidates' data attached to those invites — each invite keeps its own copy of what it needs, independent of the template. Company accounts are kept for as long as the account exists. Billing and invoice records are kept for as long as we need them for accounting and tax purposes.

We keep a record of the invite units your company has sent and had returned (how many, and when; it contains no candidate data) while your plan is active and for 30 days after it ends, and until the candidate records those invites relate to have been deleted, whichever is later. After that we delete the detailed record and keep one summary line per plan (the dates and the totals) with our payment records.

Candidates' rights

The company that invited you is responsible for your assessment data and is the right place to start — since it requested the assessment, and decides what happens with it. You can also email contact@codeoath.in directly. We aim to reply within 3 working days and complete a formal request within 15 business days, either handling it ourselves (as with deletion) or passing it to the company where the decision is legally theirs. Because candidates don't have an account with us, there is no self-service page for these requests.

Security

Traffic between your browser and codeoath.in is served over HTTPS (the link between our web host and the code-execution server is described in section 9). Every database table that holds company or candidate data uses row-level security so a company can only see its own data, and proctoring files live in a private storage bucket. Candidates have no account, which removes account-takeover risk for them.

11. Changes to this policy

We'll update the "Last updated" date above whenever this changes, and note anything material here.

12. Contact

CodeOath, a product of Codzodd Technologies, a sole proprietorship of Juee Hem Mankad (Udyam Registration No. UDYAM-GJ-01-0373494) contact@codeoath.in · +91 79849 67246

Grievance Officer: Juee Hem Mankad, contact@codeoath.in, +91 79849 67246. If you have a complaint about how your personal data is handled, write to this address and we'll acknowledge it and respond within the timeframes above.

See our Terms of Service for the rules that govern using CodeOath.