DEV Community: Maksym Shykov

A Free Donut Alternative for Slack (and When to Pick Donut Instead)

Maksym Shykov — Tue, 20 Oct 2026 07:00:00 +0000

We make CoffeeSlack, a Slack app that pairs teammates for a coffee chat. Donut is the established product in this space, so this is a comparison written by the challenger. We are not a neutral source, which is why it starts with the cases where you should pick Donut.

Where Donut is the better choice

You want calendar scheduling. Donut integrates with Google Calendar. Our introduction carries a link that opens a prefilled 30-minute event (Google Calendar, or a download for Outlook and Apple), and whoever clicks it gets the event on their own calendar. We do not read anyone's availability: the suggested slot is the next working day at 14:00 in the recipient's time zone, and both people are expected to move it.
You want more than coffee. Donut also runs Watercooler prompts, Celebrations, a recognition and rewards store, onboarding Journeys and HRIS sync. We do one thing. If you are buying a culture platform, we are the wrong shape.
You are on Microsoft Teams. Donut supports Teams. We are Slack only.
Procurement needs SOC 2, SSO or SCIM. We have none of them and do not claim otherwise. If your security team gates the purchase, this is not a close call.
You want a vendor with a track record. Donut has been doing this since 2016. CoffeeSlack is new and small, and you would be early.

What both do

	Donut	CoffeeSlack
Random 1:1 pairings in Slack	Intros, matched within a channel	Pairs everyone who opted in, within the channels you pick
Rhythm	Configurable per channel	Weekly, every two weeks, monthly, or a custom nth-weekday window
Conversation starters	Built in	Built in; an admin can replace them with their own list
Odd number of people	Handled	The last three become a trio, so nobody sits out

Two real differences

We ask people to join, rather than enrolling the channel. Each person types /coffee to take part, and joining covers a calendar month. Nobody is paired without joining, and anyone can leave a round from the dashboard without asking an admin. Your first month will be smaller than your channel. That is the trade, and it buys you people who chose to be there.

We report whether the coffee happened. Every introduction DM carries three buttons (we met, not yet, we didn't meet) and the dashboard turns those into a response rate per round. Most tools in this category report how many introductions went out. That is a different number, and an easier one.

What we do not do

No availability lookup; nothing reads either calendar to find a time that works for both people.
No group size setting: two people, plus one trio when the count is odd.
No interest or profile matching: we match on channel membership and on not repeating a recent pair.
No introduction emails yet: pairs are introduced by Slack DM only.

Cost

CoffeeSlack is free for every team right now, with no card and no cap on participants. We intend to charge later: one flat price per company rather than per person, with a free band that fits a 50-person company. For Donut's current plans and any non-profit or community pricing, read their pricing page yourself rather than trusting a competitor's summary.

Try both

Put CoffeeSlack on a different channel from your Donut one (two coffee bots on the same channel would just mean two DMs for the same people), run both for a month, and keep the one that sticks.

Full version with the details: coffeeslack.com/alternatives/donut.

Originally published at coffeeslack.com.

Calendar Invites Without OAuth: Five Things That Bit Us

Maksym Shykov — Sat, 17 Oct 2026 07:00:00 +0000

Our Slack bot introduces two people and asks them to have a coffee. The obvious next step is putting that meeting in their calendars, and the obvious way is the Google Calendar API: per-user OAuth, a consent screen, refresh tokens to store and revoke, and the same work again for Microsoft.

We shipped it without any of that: a Google template URL and an .ics download, both built on the server and carried in the message. The person clicking creates the event in their own calendar, so we hold no tokens and ask for no access. Here is what that costs, and the five things that bit us.

Why not just call the API

Reading free and busy times is a second identity system. Our only sign-in is Slack. Calendar access would mean per-user consent for two providers, stored third-party refresh tokens (a materially larger thing to protect than anything else we hold) and a new paragraph in the privacy policy. It also only pays off once both people in a pair have connected. Below that it degrades to a link with a suggested time, which is exactly what we built. So we built that first and kept the option.

1. Leaving the time out does not leave the time blank

Google's template URL takes the event as query parameters:

https://calendar.google.com/calendar/render
  ?action=TEMPLATE
  &text=Coffee chat with Dana
  &dates=20260922T130000Z/20260922T133000Z
  &details=Paired by CoffeeSlack
  &add=dana@example.com

We assumed omitting dates would open the editor with an empty time. Tested against a real calendar, it does not: Google pre-fills the next slot from "now", one hour long. A click at around 21:00 on a Friday was offered a Friday coffee at 21:30. A default you choose beats the one Google chooses, so we always send a slot, which is what dragged time zones into a feature that looked like it could avoid them.

2. A Z timestamp renders in each reader's own zone

We sent dates=20260922T130000Z/20260922T133000Z and opened it in a browser two hours ahead of UTC. It rendered as 15:00 to 15:30, with the 30-minute length intact. That is one URL that is correct for both people in a pair even in different countries. The time zone we look up is only ever used to pick a reasonable hour: an unknown zone degrades the suggestion, it never makes the link wrong.

3. Turning 14:00 local into an instant takes two passes

To offer "2pm in their own time" you need the moment at which the clock in some zone reads 14:00. The tempting version reads the offset once:

const guess = Date.UTC(year, month - 1, day, 14, 0);
return guess - offsetAt(guess, zone);   // wrong near a DST change

Treating the wall time as UTC can land the guess on the far side of a daylight-saving change from the real moment, so the offset you read is the other one. Resolving twice fixes it:

const first = guess - offsetAt(guess, zone);
return guess - offsetAt(first, zone);

Searching all 418 zones for a disagreement between the two versions found exactly three: Pacific/Auckland, Pacific/Chatham and Antarctica/McMurdo (which runs on New Zealand time, and which we missed the first time). All at 14:00, and only on the two Saturdays in 2026 when their clocks change. Our slot rule never returns a Saturday, so the bug could not be reached. We kept the second pass anyway, because the defect belongs to the helper, not to the rule that happens to dodge it.

Two smaller things in the same corner. Asking for an unknown zone throws, and the zone name comes from someone's chat profile, so it needs a try and a fallback. And some builds render midnight as hour 24, which quietly shifts a date by a day unless you take it modulo 24.

4. The .ics line limit is 75 octets, not 75 characters

RFC 5545 says a line should not exceed 75 octets, and a continuation begins with a single space or tab. Counting characters instead of bytes works on every name you will test with and breaks on the first one written in Cyrillic or containing an emoji, which arrives cut in half. Walk back off the UTF-8 continuation bytes before you split:

while (end > start && end < bytes.length
       && (bytes[end] & 0xc0) === 0x80) end -= 1;

The leading space on a continuation costs an octet too, so every chunk after the first gets 74.

Escaping has an order: the backslash goes first, or you escape the backslashes you just introduced. Then semicolon, comma, and newline to a literal backslash-n. And the trap we actually shipped into a branch: in JavaScript '\;' is not an escaped semicolon, it is a semicolon. The line that looked like it escaped them compiled, ran and did nothing, so a name like Smith; Jane would have broken the property in two. A linter caught it. The test we had written did not, because it asserted against a string built with the same mistake. Two wrongs agreeing is the normal way this survives review. The fix was to assert by character code instead of writing the expected value as a literal.

Finish with CRLF between every line and one at the end. Outlook is the client that minds.

5. Where you put the token decides who logs it

A calendar client fetches the file with no headers we control, so the URL itself has to be the credential. The first version put the token in the path:

/calendar/coffee.ics/<token>     first version
/calendar/coffee.ics?token=...   second version

We moved it because two pieces of our own code already had an opinion. Our request log records the path and drops the query, under a comment saying the query string can carry secrets. Our error reporter redacts query parameters named token, and only query parameters. A token in the path would have been written to our log on every fetch and shipped to the error reporter on every 5xx. A reviewer found it; the author did not.

And that was still not enough. Our platform writes its own request log. The application never sees it and cannot configure it, and on Cloud Run the field it records is the full URL including the query string. So the token we had just moved into the query was sitting in that log on every fetch: 104 of them, in clear text, behind a fix that had been reviewed and merged as complete. Nothing leaked. Every one of those fetches was our own probing, all in the hour after the deploy and before the first real link went out. We know that from the timestamps rather than the status codes, because the rate limiter answers before the token is read, so a 429 never tells you whether the token was valid.

The repair is a logging exclusion, because the platform can drop a matching entry but cannot redact a field inside one. Two things worth carrying:

Anchor the match. Our first filter matched the path as a substring, so anyone could suppress their own log entry by hanging that string off the end of any other URL: a tool for hiding from the logs, shipped as a security fix. Anchor on host and path, and test that a crafted URL fails to match.
Know what the exclusion costs. The platform log was the only copy of the client address, user agent and response size. On a public route those are exactly the fields you want when something goes wrong. If it starts to matter, log them yourself from inside the route, where you can leave the secret out on purpose.

The general shape is the part worth keeping: your logging and error reporting encode a belief about which half of a URL is secret, and it is usually right. Your platform holds its own belief, it is usually simpler, and it has not read your comments.

What we deliberately left out

No ATTENDEE, ORGANIZER or METHOD in the .ics. Depending on the client, ATTENDEE reads as an invitation or as an ordinary appointment, and it puts a colleague's address in a file in a Downloads folder. Inviting the other person is the Google link's job, where the person clicking is the one inviting.
No signature on the token. The identifier carries 48 bits from a random-bytes call, so forging one means guessing those bits. An HMAC adds a secret to rotate and forget (ours sat unset for 26 days once) while protecting nothing: the only person who benefits from forging a pair member's copy is the pair's other member, who was sent the same details anyway.
No availability lookup. That needs the API, which needs the OAuth, which is the project we did not do. The slot we suggest is a guess both people are expected to move.

When this is the wrong approach

Everything above depends on a person being there to click. If you need to know when someone is free, or to put an event in their calendar while they are asleep, none of this helps and you are back to the API and the consent screen. What it buys is the 80 percent case at none of the cost, and the option to do the rest later.

The Google behaviour described here was checked against a live calendar on 21 September 2026. It is not documented anywhere we could find, so it can change without warning. Check it yourself before relying on it.

This is the bot it went into: CoffeeSlack pairs teammates for a coffee chat in Slack. Free for every team, no card.

Originally published at coffeeslack.com.

How ATS Resume Parsing Actually Works

Maksym Shykov — Thu, 15 Oct 2026 07:00:00 +0000

What happens between uploading a CV and a recruiter seeing it: text extraction, section segmentation, entity extraction and search indexing — and where each stage breaks.

Short answer

An ATS parses a CV in four mechanical stages: it extracts the text, splits it into sections by their headings, pulls out entities such as email, dates and job titles, and indexes the result for recruiters to search. Nearly every piece of CV formatting advice exists because one of those stages breaks.

Most CV advice treats the applicant tracking system as a black box with opinions. It is simpler than that. Parsing runs in stages, each one mechanical, and almost every piece of real formatting advice is downstream of a specific stage failing.

Stage 1 — Text extraction

The file is opened and characters are pulled out of it. For a DOCX this is mostly reading XML. For a PDF it is harder: a PDF does not store lines or paragraphs, it stores fragments of text with coordinates. Reconstructing “this fragment and that fragment are on the same line” is geometry, and it is where multi-column layouts fall apart — two columns can be stitched into one nonsensical line.

Here is what that looks like. A two-column CV, as a reader sees it, and the text a line-by-line extractor — my checker included — actually gets back.

What the reader sees:

EXPERIENCE                        SKILLS
Engineering Manager, Acme         Kubernetes, Go
Jan 2020 – now                    Terraform, AWS

What the parser receives:

EXPERIENCE SKILLS
Engineering Manager, Acme Kubernetes, Go
Jan 2020 – now Terraform, AWS

Every line is now a hybrid. The Experience heading shares a line with Skills, your job title has two skills glued to it, and the date range is followed by cloud-related skills. Nothing was lost — it was just put back together in the wrong order, which for a parser is the same thing.

Fails when: the page is an image, the text is outlined, or the layout is multi-column.

Stage 2 — Section segmentation

The text is cut into regions by looking for headings. This is why the boring heading beats the clever one: a parser matching against a list of known words finds Experience, Work Experience and Employment History. It does not find Where I've Made a Dent.

To make this concrete: these are the exact English headings my checker looks for. It accepts a short line — 45 characters or fewer, in any capitalisation — that contains one of them, so Relevant Work Experience counts as Experience.

Section	Headings it accepts	Points
Experience	“experience”, “employment history”, “work experience”, “work history”, “professional experience”	8
Education	“education”, “academic background”	6
Skills	“skills”, “core competencies”, “technical skills”, “expertise”	6
Summary	“summary”, “profile”, “objective”, “about me”, “about”	5
Achievements	“achievements”, “key achievements”, “accomplishments”, “highlights”	4 (bonus)
Projects	“projects”, “selected projects”, “side projects”	3 (bonus)
Certifications	“certifications”, “certificates”, “courses”, “licenses”, “certifications & courses”	3 (bonus)

Commercial parsers use longer lists, but the principle is identical — and none of them has your invented heading on it.

Fails when: headings are creative, styled only by colour, or absent.

Stage 3 — Entity extraction

Within each section the parser looks for specific things: an email is a pattern, a phone number is a pattern, a date range marks the start of a role. Job title and employer are inferred from position relative to the date.

This is why dates matter more than people expect. A dated line is the anchor that tells the parser “a new job starts here”. Undated roles collapse into whatever came before them, and your three years somewhere land inside the previous employer's entry.

Fails when: dates are missing, written only as “2 yrs”, or drawn as a graphic timeline.

Stage 4 — Indexing and search

The extracted fields go into a database. A recruiter then searches it — by title, by skill, by location. Your CV is not being judged at this point; it is being queried.

Which reframes the keyword question. The goal is not to stuff terms in to please an algorithm. It is to make sure the words a recruiter would plausibly type appear somewhere you have honestly earned them. If you led Kubernetes migrations and never wrote the word “Kubernetes”, you will not be in that result set.

Fails when: the vocabulary of your CV and the vocabulary of the job ad have no overlap.

What this implies

Formatting advice is not superstition — each rule maps to a stage above.
Keyword advice is about vocabulary overlap, not density. Never claim a skill you lack.
Nothing in this pipeline evaluates you. It moves you into a searchable shape, or fails to.

See it from the parser's side. The free CV score checker has an Extracted data tab that shows exactly what came out of your file — the name, contact details, links, and each role it managed to identify. If something is missing there, it will be missing for the employer too.

Frequently asked questions

Can an ATS read a two-column resume?

Often not in the right order. Text extraction rebuilds lines from positions on the page, so two columns can be stitched together line by line, mixing a job title with a skills list. A single-column layout avoids the problem entirely.

Do applicant tracking systems read headers and footers?

Some parsers skip those regions or treat them unreliably. Keep your name, email and phone number in the main body of the page so they are extracted whichever parser reads the file.

Does hiding keywords in white text help?

No. White text is still text: it is extracted into the parsed profile a recruiter reads, where it looks like an attempt to game the search. Use the job ad’s vocabulary only where you have genuinely earned it.

Originally published at cv.shykov.dev. The checker mentioned here is free, open source and runs entirely in your browser: cv.shykov.dev.

PDF or DOCX for an ATS: Which Should You Send?

Maksym Shykov — Mon, 12 Oct 2026 16:47:05 +0000

Send a PDF, unless the application form asks for something else. The reasoning, the one PDF that will fail every time, and what to do when the employer names a format.

Short answer

Send a text-based PDF unless the application asks for another format — then send exactly what it asks for. The only PDF that reliably fails is one with no real text in it, such as a scan or an export with outlined fonts, and you can test for that in seconds.

The longer answer is worth two minutes, because the usual advice (“always use Word, ATS cannot read PDFs”) is a decade out of date.

Why PDF is the default now

It looks the same everywhere. A DOCX re-flows depending on the fonts and Word version at the other end. Your careful two-page layout can arrive as three ragged pages.
Modern parsers handle it. PDF text extraction is a solved problem; the major systems have supported it for years.
It is harder to mangle. Nobody accidentally edits your PDF between upload and review.

The one PDF that fails every time

A PDF is a container. It can hold real text, or it can hold a picture of text. If you exported from a design tool with the text outlined, or scanned a printout, or screenshotted your CV and saved it as a PDF, then the file contains no text at all. A parser reads it as a blank document.

The test takes three seconds: open the PDF and try to select a line of text with your cursor. If you cannot highlight it, neither can the ATS.

A 30-second test for any PDF

Selecting text proves the text exists. Two more steps show whether it comes out usable:

Select a line. If nothing highlights, the page is an image. Re-export from the original document.
Search for your email with Ctrl F / ⌘ F. If the viewer cannot find it, a parser will not either — often because it lives in a header, an image, or a text box.
Select all, copy, and paste into a plain-text editor (Notepad, or TextEdit in plain-text mode). What you see is close to what a parser receives. If two columns come out interleaved line by line, or your job titles appear far from their dates, fix the layout before you worry about anything else.

Exporting from Word, Google Docs or Pages with their normal Download as PDF or Export to PDF produces text-based PDFs. The risky routes are “print to image”, scanning, and design tools with an option to convert text to outlines.

When DOCX is the right answer

The form says so. If the upload field lists .doc/.docx only, that is the answer. Do not out-clever the form.
A recruiter asked for it. Agencies often re-brand your CV onto their template, which needs an editable file.
The employer runs an older system. Rare now, but harmless to comply with.

Things that matter more than the extension

Format is the easiest decision you will make about your CV. These are the ones that actually move the needle:

One column. Multi-column layouts can be read in the wrong order, interleaving two unrelated lines.
No text inside images. A logo is fine; your job title rendered as a graphic is not.
No critical detail in the header or footer. Some parsers skip those regions. Put your email in the body.
Real bullet characters, not manually drawn dashes inside a table cell.
A sensible filename — Firstname_Lastname_CV.pdf. A human sees it in a folder of hundreds.

Not sure which category your file falls into? Drop it on the free CV score checker — it reads both PDF and DOCX in your browser and tells you straight away whether there is extractable text, how many pages a parser sees, and which sections it managed to identify.

Frequently asked questions

Can an ATS read a PDF resume?

Yes, as long as the PDF contains real text. Modern applicant tracking systems extract text from PDFs routinely. A scanned or image-only PDF has no text to extract and reads as blank.

Should I send .doc or .docx?

Prefer .docx, the current Word format, unless the employer specifically asks for .doc. Better still, send a text-based PDF unless the form limits you to Word files.

How do I know if my PDF is text-based?

Open it and try to highlight a line with your cursor, then search for your email address. If you can select text and the search finds your email, the PDF is text-based.

Originally published at cv.shykov.dev. The checker mentioned here is free, open source and runs entirely in your browser: cv.shykov.dev.

ATS Resume Checkers That Do Not Upload Your CV

Maksym Shykov — Mon, 12 Oct 2026 16:17:26 +0000

Most resume checkers require you to upload your CV and hand over an email address. Here is what happens to the file, why it matters while you are still employed, and how a local-only check differs.

Short answer

A browser can read and score a PDF or DOCX without sending it anywhere, so an upload is a design choice, not a technical necessity. You can verify a checker yourself in under a minute: open the browser’s Network panel, drop your CV in, and look for a request that carries the file.

A CV is one of the most sensitive documents most people own. It carries your full name, your personal email, your phone number, your home city, and a complete timeline of who has employed you. Handing it to a website is a bigger decision than it feels like.

It matters most in the situation people are usually in when they reach for a resume checker: job hunting while still employed. At that point the document is not just personal data, it is evidence of intent.

What “upload your resume” usually means

When a tool asks you to upload, the file leaves your device and lands on a server. From there, some combination of the following is normal and often disclosed in the terms:

The file is stored, sometimes indefinitely, and tied to the account you created.
The text is sent to a third-party language model for scoring or rewriting.
The email you registered with enters a marketing sequence.
Aggregate data feeds a recruiting product sold to employers.

None of that is necessarily malicious. It is simply the business model: the check is free because you and your document are the product. But it is worth knowing before you click, rather than after.

The questions worth asking of any checker

Does the file leave the device? If there is no upload, most other questions stop mattering.
Is an account required? An email wall exists to capture the email, not to improve the score.
Is scoring deterministic or generated? If a model writes the feedback, your CV was sent to that model.
Can you read the rules? A published rubric can be argued with. A hidden one cannot.
What is the deletion path? If the answer is a support email, assume the file stays.

How a local-only check works

Modern browsers can read a PDF or DOCX without any server involved. The file is opened into memory, the text is extracted by a JavaScript library, the checks run over that text, and the result is rendered — all inside the tab you already have open. Close the tab and the document is gone.

The trade-off is real and worth stating: a local checker cannot compare you against a database of other candidates, and it cannot rewrite your bullets for you. What it can do is tell you whether a parser will read the document correctly, and which specific lines are weak — which is the part that actually affects whether your application arrives intact.

How to check that a checker really does not upload

“We never store your file” is a promise. Whether the file leaves your machine at all is something you can watch happen — or not happen — in any desktop browser:

Open the checker, then open the browser’s developer tools: F12 on Windows and Linux, ⌥ ⌘ I on a Mac.
Switch to the Network tab and clear it, so only new requests show.
Drop your CV into the checker and wait for the result.
Look through the new requests. An upload is a POST or PUT whose request size is roughly the size of your file. Scripts and fonts the page loads for itself are not uploads.

If no request carries the file, the file did not leave. This works on any site, including the one I built — which is the point: the claim should be checkable by you, not taken on trust.

My tool adds a second, browser-enforced guarantee. Its Content-Security-Policy header sets connect-src 'self' data: blob:, which means the browser itself refuses any network connection to another domain, and the one domain it may talk to serves static files only — there is no endpoint to receive a CV.

That is the local kind of checker. The free CV score checker parses your PDF or DOCX in the browser with pdf.js and mammoth, scores it with fixed rules, and has no backend that could receive a file. It is MIT licensed, so the claim is checkable rather than promised.

Frequently asked questions

Is it safe to upload my resume to an online resume checker?

It depends on what happens to the file, which is usually described only in the terms. Uploaded CVs are commonly stored, tied to an account, and sometimes sent to third-party language models. If you are job hunting while employed, prefer a checker that never receives the file.

How can a website read my CV without uploading it?

Browsers can open a file you select into the page’s own memory. JavaScript libraries such as pdf.js and mammoth then extract the text, and the checks run on your device. Nothing needs a server.

How do I know a resume checker is not uploading my file?

Open the browser’s developer tools, go to the Network tab, clear it, then drop your CV in. An upload typically shows up as a POST or PUT request roughly the size of your file. If there is none, the file stayed on your device.

Originally published at cv.shykov.dev. The checker mentioned here is free, open source and runs entirely in your browser: cv.shykov.dev.

What Is an ATS Score, and What Does It Actually Measure?

Maksym Shykov — Mon, 12 Oct 2026 16:16:16 +0000

An ATS score measures how cleanly a machine can read your CV — not how good a candidate you are. Here is what the number covers, what it cannot see, and the myth to ignore.

Short answer

An ATS score estimates how cleanly applicant tracking software can pull your text, contact details, sections and dates out of your CV. It says nothing about whether you fit the job. Above roughly 85, nothing important is getting lost — spend the time on the content instead.

An applicant tracking system is the software an employer uses to receive, store and search applications. Before a recruiter reads your CV, the system parses it: it pulls out your name, your contact details, your job titles, your dates and your skills, and writes them into database fields. An ATS score is an estimate of how well that step will go.

That is a narrower claim than it sounds, and the narrowness is the point. The score does not know whether you are right for the job. It measures one thing: whether the document survives being read by a machine.

The myth worth dropping first

You have probably read that “75% of resumes are rejected by an ATS before a human sees them.” That figure has been repeated for over a decade and has no credible source behind it. Applicant tracking systems are search and storage tools. They rank and filter on criteria a recruiter sets; they do not autonomously bin three quarters of applicants.

The real risk is duller and more fixable. If a parser cannot find your email, your application arrives with an empty contact field. If it cannot read your job titles, you do not appear in the recruiter's search for “engineering manager”. Nobody rejected you — you were never in the result set.

What a score can reasonably measure

Every honest ATS score is a heuristic built from a handful of checks. On this site the rubric is fixed at 100 points and published, so you can see exactly where each point comes from. In five groups:

Parseability (25) — is there real, selectable text, or is the page an image?
Contact details (15) — email, phone, and a link written out as visible text.
Sections (35) — headings a parser recognises: Experience, Education, Skills, Summary.
Format (15) — page count, dated roles, real bullet structure.
Content (10) — quantified impact and verb-led bullets.

And check by check — this table is the one the scorer runs, not a summary of it:

Check	Group	Points
Machine-readable text	Parseability	15
Clean text encoding	Parseability	10
Email address	Contact	5
Phone number	Contact	5
LinkedIn / website link	Contact	5
Experience	Sections	8
Education	Sections	6
Skills	Sections	6
Summary	Sections	5
Achievements / Projects / Certifications	Sections	10
Page count	Format	5
Dated history	Format	5
Bulleted structure	Format	5
Quantified impact	Content	5
Strong action verbs	Content	5

Two details are easy to miss. A missing phone number or summary only costs its own points — they are warnings, not failures — while a missing Experience, Education or Skills heading fails outright. And the last Sections row is a bonus: an Achievements heading is worth 4, Projects 3, Certifications 3.

Sections carry the most weight because they are what turns a wall of text into structured data. A parser that finds a heading called “Experience” knows the entries beneath it are jobs. Without it, it is guessing.

What no score can measure

Whether your experience matches the role. That is the recruiter's judgement.
Which specific ATS the employer runs. Vendors parse differently, and none publish their rules.
Whether your writing is persuasive. A perfectly parseable CV can still be dull.

Treat a score above roughly 85 as “nothing here will get lost in transit” and move on to the content. Chasing the last few points is almost always wasted effort.

Why two checkers give you two different scores

There is no standard ATS score. Each checker invents its own rubric, weights it however it likes, and — usually — does not tell you what it is. A 62 on one site and an 81 on another are not a contradiction; they are two different tests. The useful question is never “which number is right” but “which specific check failed, and do I agree it matters?” That is only answerable when the rules are published.

Check yours in a few seconds. The free CV score checker scores a PDF or DOCX entirely inside your browser — the file is never uploaded, there is no account, and no language model is involved. You can read the exact scoring rules in the public source.

Frequently asked questions

What is a good ATS score?

On this checker, 85 or above means a parser will read the document cleanly and nothing important is lost. 70 to 84 is good with a few specific fixes left. 50 to 69 needs work, usually a missing section heading or contact detail. Below 50 something structural is wrong, most often text the parser cannot extract.

Do employers see my ATS score?

Not a score from a checker like this one. It is computed on your device and sent nowhere. The employer’s own system may rank applications against the job, but that ranking uses its rules and the recruiter’s search terms, not any third-party score.

Why does my CV get a different score on every checker?

Because there is no standard. Each checker defines its own checks and weights. Compare the individual checks that failed rather than the headline numbers.

Is it true that 75% of resumes are rejected by an ATS?

That figure has circulated for over a decade without a credible source. Applicant tracking systems store and search applications; recruiters set the filters. The real risk is a CV the parser misreads, which then fails to appear in a recruiter’s search.

Originally published at cv.shykov.dev. The checker mentioned here is free, open source and runs entirely in your browser: cv.shykov.dev.

DEV Community: Maksym Shykov

A Free Donut Alternative for Slack (and When to Pick Donut Instead)

Where Donut is the better choice

What both do

Two real differences

What we do not do

Cost

Try both

Calendar Invites Without OAuth: Five Things That Bit Us

Why not just call the API

1. Leaving the time out does not leave the time blank

2. A Z timestamp renders in each reader's own zone

3. Turning 14:00 local into an instant takes two passes

4. The .ics line limit is 75 octets, not 75 characters

5. Where you put the token decides who logs it

What we deliberately left out

When this is the wrong approach

How ATS Resume Parsing Actually Works

Short answer

Stage 1 — Text extraction

Stage 2 — Section segmentation

Stage 3 — Entity extraction

Stage 4 — Indexing and search

What this implies

Related

Frequently asked questions

PDF or DOCX for an ATS: Which Should You Send?

Short answer

Why PDF is the default now

The one PDF that fails every time

A 30-second test for any PDF

When DOCX is the right answer

Things that matter more than the extension

Related

Frequently asked questions

ATS Resume Checkers That Do Not Upload Your CV

Short answer

What “upload your resume” usually means

The questions worth asking of any checker

How a local-only check works

How to check that a checker really does not upload

Related

Frequently asked questions

What Is an ATS Score, and What Does It Actually Measure?

Short answer

The myth worth dropping first

What a score can reasonably measure

What no score can measure

Why two checkers give you two different scores

Related

Frequently asked questions