Privacy Policy

1. Who we are

KataJob is an interview-preparation tool. You can explore roadmaps, read questions, take quizzes, and track spaced-repetition review without an account; creating an account adds sign-in, email verification, optional two-factor authentication, and progress that follows you to another device.

Using KataJob without an account is not the same as leaving no trace. The first time you record progress we create a guest account for you on our servers and keep your work there — section 2 explains exactly when that happens and section 7 says how long it lasts.

This policy explains what data we hold, why we hold it, how long we keep it, and the choices you have. KataJob is a site name rather than a company — it is run by an individual based in Tbilisi, Georgia, reachable at [email protected], who is the data controller for everything described here.

2. Data we collect

Account data — when you register, we store your email address, your display name, and a securely hashed password (we never store the password itself).

Sign-in with a provider — you can sign in with Google, GitHub or LinkedIn instead of a password. From any of the three we take two things: the email address the provider vouches for, and a stable identifier for your account at that provider so we recognise you next time. We never receive your password at the provider, and we do not keep the access token the provider issues. Your display name is taken from the part of your address before the @ sign; we do not copy a profile name or a profile picture from any provider. Google and LinkedIn state whether an address is verified as part of the sign-in response. GitHub does not, so for GitHub only we make one further call to its /user/emails endpoint to find an address it has verified — that is the single case where we read more than the sign-in response itself returns, and we keep only the address it gives us.

Authentication & security data — to keep you signed in and your account safe, we process short-lived JWT access tokens, refresh tokens stored in HttpOnly cookies, one record per active session (the browser user-agent string, the IP address the session was created from, and timestamps), and, if you enable two-factor authentication, an encrypted TOTP secret plus single-use recovery codes stored as hashes. We also keep failed-sign-in counters to support temporary account lockout that protects against password-guessing.

Learning data — the learning items you create (the roadmaps you are working through), your per-question progress, your spaced-repetition review schedule, your quiz history, and any answers you write out yourself. All of it lives on our servers, whether or not you have signed up. Using KataJob without an account creates a guest account: the first time you do something that records progress — grading a card, saving a quiz, starting a roadmap, writing out an answer — we create an account for you and key that work to it. Reading and browsing on their own create nothing. Signing up later does not move or merge anything: it attaches your email and password, or a provider identity, to the account you already have, so the work you did as a guest is already on the account you just created.

Preferences — settings such as your reading width, your dashboard layout, your review timers and your keyboard shortcuts are stored on your account. Your browser also keeps a copy of some of them, along with your light/dark theme choice, so a page can render correctly before your account has loaded. That copy is a cache of settings; it holds no learning data, and clearing it loses nothing.

Feedback and bug reports — if you send a report from inside the product we store what you wrote (its type, title and description), any file you attach, and the question or topic the report names. Filing a report needs an account, and the report is linked to it: we email the address on that account to confirm we received the report and, when we resolve it, to tell you what was done.

Sign-in and activity records — we store the date and time you last signed in, and, separately, one record for each calendar day (counted in UTC) on which your account was active. An activity record is an account and a day, nothing else: not the pages you read, not how long you stayed, not what you answered. One is written when you sign in and each time your session is renewed as you keep using the site, for a guest account as well as a registered one. We read them to count how many accounts are in use over a day or a month and to see which accounts have gone unused. That is our own usage reporting: it is not advertising, and it is not shared.

Operational data — standard server logs needed to run and secure the service: the request path, method, status, timing, a request id, the IP address the request came from, and the browser user-agent. Where a log line names a user it uses the numeric account id, never an email address. If a page hits an error on your device we also record the error message, an opaque error code, the route it happened on, that request id, and which release of the site the server was running — never the stack trace. We do not run third-party advertising, analytics, or cross-site tracking of any kind.

Visit statistics — to know which pages are read and where visitors come from, our server counts page visits as it handles them. For each visit it records the page address without its query string (apart from any utm campaign tags the link carried, and with any account-specific id in the address replaced by a placeholder), whether the page was loaded in full or reached by moving within the site, the domain of the site that linked to the page, your country as reported by Cloudflare, your browser, operating system and device type, whether the visitor is a known search-engine or AI crawler, and a visitor code. The visitor code is computed from your IP address and browser with a key that is replaced every day and never stored, so that a visitor is counted once a day. The statistic itself holds neither your IP address nor your browser string — the ordinary server logs described above do, and are kept alongside it — and because the key for each day is thrown away, visitor codes from different days cannot be matched to each other. There is no cookie, no tracking script on the page and no third party involved. These records are part of the server logs and are kept for the same time (section 7).

Bot protection — to stop automated copying of the public question, topic and roadmap pages, our server counts how many of them each IP address (and, for IPv6, each block of addresses) reads per minute, hour and day. Those counts are kept only in the server's memory: they are never written to disk or to the logs, and they are gone at the next restart. A visitor who reads faster than a person would is shown a human check (Cloudflare Turnstile) before the next page. Only then does Cloudflare see anything beyond its usual role as our edge: to tell a person from a script, it processes technical signals from your browser, and we send it your IP address with the check's answer to confirm the result. When the server limits or checks a visitor, its log records what happened (for example that a check was passed, or that an automated client was refused), the page, and the same daily visitor code the visit statistics use, not your IP address. If an address keeps reading past the limits without passing the check, or opens a link that is hidden from people and that search engines are told not to follow, the record also names its network range (the first three parts of an IPv4 address, or the first 48 bits of an IPv6 one) so that we can block that range at Cloudflare. These records are kept with the server logs (section 7).

3. How we use your data

We use the data above only to operate the service: to authenticate you and keep your session secure, to save and sync your learning progress, to schedule reviews, to send the transactional emails described below, to enforce security controls (such as lockout, rate limiting and two-factor), to triage the bug reports and feedback you send us, to measure how many people visit and which pages they read (the visit statistics in section 2), to protect the public pages from automated bulk copying (the bot protection in section 2), and to maintain and improve the platform.

We do not sell, rent, or trade your personal data, and we do not use it for behavioral advertising.

4. Cookies

We use cookies that are strictly necessary to run the service. There are four, and only the first carries a sign-in credential:

• refreshToken — secure, HttpOnly and same-site. This is what keeps you signed in, and it is the reason a guest account survives a page reload.
• katajob_session — a flag rather than a token: it says only that a session may exist, so the app can skip a pointless sign-in check for a visitor who has none. It is readable by the page scripts, which is precisely why it carries nothing else.
• katajob_rid — the id of the page request, kept for 15 minutes. Deliberately readable by the page scripts so an error screen can show you the id of the request that failed. It identifies a request, not a person.
• kj_pass — set only if you pass the human check described in section 2, and kept for 24 hours (15 minutes if the check service could not be reached). It is HttpOnly and signed by our server, and it holds a random pass id, its expiry time, the number of pages it allows and a short hash of your browser's user-agent string, so that it works only in the browser that passed the check. Its one use is to let you keep reading without being checked again. It is not used for tracking or analytics, and it is not linked to your account.

Access tokens are held only in memory for the current session, not in a cookie. While access to the site is restricted, one further strictly necessary cookie (katajob_gate) records that you passed the access prompt so you are not asked again; it exists only for as long as that restriction does.

We do not set third-party advertising, analytics, or cross-site tracking cookies.

5. Email

We send transactional email only — for example, address verification and password-reset messages, and the confirmation and resolution notices for reports you file. These are delivered through our email provider, Resend, which processes the recipient address and message content solely to deliver the email on our behalf. We do not send marketing email without separate consent.

6. Service providers

We rely on a small number of processors to run the service. Naming them is more useful than naming a category, so here they are:

• Railway — hosts the application and its database, and holds a copy of the server logs described above.
• Cloudflare — the edge that every request to the site passes through, Email Routing for mail sent to our published addresses, and Turnstile, the human check described in section 2. Turnstile is used only when a visitor is checked.
• Resend — delivers the transactional email described above.
• Google — mail forwarded by Cloudflare arrives in a Gmail inbox we read and reply from.

We also run our own monitoring server, which holds a second copy of the server logs. These providers process data only on our instructions and under appropriate agreements. A current list is available on request at [email protected].

7. Retention

We keep your account and learning data for as long as your account is active. A session lasts one day for a normal sign-in and thirty for a "remember me" one. Revoking a session ends it at once, but its record — with the IP address and browser user-agent described in section 2 — is kept until thirty days after the session would have expired, and a daily sweep then deletes it. The record of a session that simply runs out is deleted the same way, thirty days after it expires.

Guest accounts have a time limit, because nobody is there to close them. A guest account that has gone unused for 180 days is deleted, and everything keyed to it goes with it. So is a guest account whose data a real account has already taken over, seven days after the takeover. Clearing your cookies makes a guest account unreachable to you, and the same sweep is what eventually removes it.

An account whose email address is never confirmed is deleted after seven days — or up to fourteen, if a confirmation link you asked for is still waiting to be used. If it began as a guest account with progress on it, the progress stays with the guest account and only the unconfirmed address is removed.

The sign-in and activity records described in section 2 are kept for as long as the account exists. They are how we tell that an account is still in use, so there is no shorter window after which they expire; they are deleted with the account, whether you delete it yourself or the sweep above reclaims a guest account.

Each data export (section 8) leaves a record of when it started, when it finished and how large the archive was. That record is what enforces the limit of one export every 24 hours. We keep each one for a year, after which a daily sweep deletes it, and it is deleted with the account if that comes first. The records are part of the export itself, so the archive lists the exports taken before it.

Operational logs are kept for 7 days by Railway and 30 days on our own monitoring server, then deleted. The bot-protection counts described in section 2 never reach them: they live only in the server's memory and are gone at its next restart.

Deleted data can persist in our encrypted backups for up to 30 days after it leaves our live database: the database can be recovered to any point in roughly the last 27 days, and a nightly encrypted archive is kept for 30. After that it is gone. Backups are used only to recover the service from a disaster.

8. Your rights and choices

You can access and update your account details, manage your active sessions, enable or disable two-factor authentication, and reset your learning data — progress, schedules and quiz history — from your account settings.

Account deletion is available as a self-service action. Deleting your account (via your account settings, which calls DELETE /api/users/me) cascades: it removes your account record, your credentials, sessions and two-factor secrets, the sign-in and activity records described in section 2, the record of your data exports, and every piece of learning data keyed to the account — progress, schedules, review history, quizzes, the roadmaps you started, and the answers you wrote yourself.

Deleting asks you to prove the account is yours, and three proofs are accepted: your password, a code from your authenticator app or one of your recovery codes, or — if you signed in with a provider and have neither — a single-use link we email to the address on the account. Exactly one of the three, each time: being signed in is not on its own enough to delete an account.

One thing survives that deletion, deliberately. Bug reports and feedback you filed stay, so the problems they describe can still be fixed, but they are stripped of everything that links them to you: the account reference is cleared, so nothing left on the report points back to you, and we stop emailing about it. If you need the report itself removed rather than unlinked, ask us and we will delete it.

Two things outlast the deletion briefly. Our internal records of the deletion itself, which carry your email address so every step can be completed, are removed about a week after the deletion completes, and if a step fails it is retried automatically until it does. Copies in our encrypted backups are gone 30 days after that, as section 7 describes.

A guest account cannot use self-service deletion. It has no email address and no password, so there is no way for it to prove the account is yours. To walk away from one, clear KataJob's cookies and site data from your browser: the account becomes unreachable, and it is deleted once it has gone unused for 180 days, as section 7 describes.

Depending on your location you may also have rights to access, correct, export, or restrict processing of your data. Export is self-service: your account settings will build you a ZIP archive of what the account holds — your profile and preferences, the days it was active, its security metadata (which sessions exist, when you last signed in, whether two-factor is on), all of your learning data including the answers you wrote out, and the reports you filed. The archive holds JSON and CSV files and a README that says what each file contains. It proves the account is yours first, with your password, a code from your authenticator app or one of your recovery codes, or — if you signed in with a provider and have neither — a single-use link we email to the address on the account. That link confirms only the export: it cannot delete the account or change anything on it, and the link a deletion sends cannot be used to export. The README states the archive's omissions: the password hash, the two-factor secret and recovery codes, the value of any session or email token, the bytes of files attached to a report, and server logs. One export is available every 24 hours; for anything else, write to [email protected].

The remaining rights have no button and are handled by request: correction, restriction, and a copy of the attachment bytes the export leaves out. Write to [email protected] and we will fulfil it.

9. Security

We protect your data with measures appropriate to its sensitivity: passwords are stored only as salted BCrypt hashes, two-factor secrets are encrypted at rest with AES-256-GCM and recovery codes are kept as hashes, the cookie that keeps you signed in is HttpOnly and same-site, repeated failed sign-ins trigger a temporary lockout, and requests are rate limited. No system is perfectly secure, but we aim to apply current good practice and to fix issues promptly.

10. Children

KataJob is intended for use by adults preparing for technical interviews and is not directed to children. You must be at least 16 to use it, and we do not knowingly collect data from anyone younger. If you believe a child has given us data, write to us and we will delete it.

11. International transfers

The providers named in section 6 all operate across multiple regions: Railway hosts the application and database, Cloudflare serves every request from whichever of its locations is nearest you, and Resend and Google carry our mail. Your data may therefore be processed outside the country you are in. Where required, we put appropriate safeguards in place for international transfers. Details are available on request.

12. Changes to this policy

We will update this policy as the product and our data practices evolve. Material changes will be communicated before they take effect, and the "last updated" date below will change.

13. Contact

Questions about this policy or your data can be sent to [email protected], which reaches the person who runs the site — section 1 says who that is. This policy is governed by the law of Georgia: the country, not the US state.