FAQ

Frequently asked questions

Honest answers to the hard questions about what CriticCode is, how it works, and whether it belongs in your hiring process.

The basics

What is CriticCode?

CriticCode is a code review assessment for engineering hiring. Candidates receive a one-time link, see multiple implementations of the same feature, and rank them from best to worst with written reasoning. You get their score and their explanation. No setup, no live coding, no waiting days for a take-home to come back.

Why does this exist?

LeetCode tests whether someone can recall algorithms under time pressure. Take-home projects test whether someone can write code over a weekend, increasingly with AI doing most of the work. Neither tells you if the person can look at code and know whether it's any good.

That skill, spotting a race condition, recognising an N+1, knowing when an abstraction is premature, is what actually determines engineering quality day to day. CriticCode tests that directly.

How does it work?

You select one or more assessments, enter the candidate's details, and pay. Your candidate receives an email with a one-time link. They read each challenge (a short description of a feature or problem) and then see several implementations of it. They order them from best to worst and write their reasoning for each choice.

Once they submit, you can see their score (how closely their ranking matched the correct one) and read their full reasoning.

How long does it take?

Around 10–20 minutes for a typical assessment. Candidates are told upfront. There's no time limit, so technically they can take as long as they need, but the format is designed to be read and evaluated, not researched or built.

The challenges

How are the challenges created?

Each challenge is a realistic scenario, e.g. authentication, caching, background jobs, API design, and is written to represent the kind of code that actually shows up in production codebases. Each scenario has several implementations that span the quality spectrum: one that is clean, idiomatic, and correct; others with meaningful flaws like missing error handling, hidden race conditions, poor abstractions, or subtle security issues. Some examples are technically correct and functionally equivalent, but might not scale well or be maintainable. And vice versa, sometimes a more maintainable solution is not the most performant, but the right trade-off for the scenario.

The correct ranking is set by the CriticCode team and reviewed for each language and framework. It reflects widely held engineering best practices, not personal preference. Before any challenge goes live, it is reviewed by experienced engineers working in that language or ecosystem to verify that the ranking is correct, the flaws are genuine, and the scenario is representative of real work, not a contrived gotcha.

Isn't code quality subjective?

For matters of taste, yes. For the things we test, mostly no. We are not asking candidates to opine on tabs versus spaces or where to put the opening brace. We ask them to distinguish code that has an N+1 query from code that doesn't. Code that catches and handles errors from code that silently swallows them. Code that will break under concurrency from code that won't.

Reasonable engineers with experience broadly agree on these things. That's the target signal.

What languages and technologies are covered?

New assessments are added regularly. You can see the full list on the catalog page.

Can I create my own challenges?

Yes. CriticCode supports custom assessments, so you can write challenges specific to your stack, your codebase, or the specific problems your team works on. One custom assessment is included on the free tier during early access.

AI and integrity

What stops candidates from just asking AI to rank the code?

We've built in technical friction that handles most casual attempts. But unfortunately, no web-based assessment is fully AI-proof and we'd rather be upfront about that than oversell it.

The real defence is using CriticCode as one layer in your process, not the whole thing. A good follow-up discussion is where it earns its keep. For high-stakes hires, doing it in person is a strong addition. Ask a candidate to walk you through their reasoning and the picture becomes clear fast.

Isn't this the same problem as every other assessment format?

Honestly, yes. No asynchronous assessment is cheating-proof — take-home projects can be handed to AI, LeetCode answers are a Google search away. This isn't a new problem, sadly.

What we optimise for is signal quality when candidates engage honestly, which the majority do. And because the format requires written reasoning rather than just a correct output, the responses that come back tend to be more revealing than most other formats and AI answers are easier to spot.

Results and scoring

How is the score calculated?

The score is the percentage of snippets where the candidate's ranking matched the correct ranking exactly. A score of 100% means they placed every snippet in the right order. However, this is a blunt instrument. Treat it as a rough orientation, not a verdict.

What if a strong engineer scores poorly?

It happens, and it matters what the reasoning says when it does. A candidate who scores 40% but writes a precise, well-argued case for why they ranked things differently (identifying real trade-offs and making a coherent case for their ordering) is a very different situation from a candidate who scores 40% and writes three words per answer.

Score alone is a starting point. The reasoning is the substance. Read both before making a judgment.

What does a high score with weak reasoning tell me?

It tells you the candidate got lucky, guessed well, or pattern-matched without understanding. Treat a high score with thin reasoning the same way you'd treat a completed take-home with no explanation of the decisions made. Push harder in the interview.

For candidates

Is this fair to candidates?

We think so. It's shorter than most alternatives, there's no live coding pressure, no environment setup, no ambiguous brief, and no multi-day commitment. Candidates are not asked to produce code, they're asked to read it and respond. That's a more realistic test of what most engineering work actually involves.

We're also not testing obscure language trivia or algorithm recall that has little bearing on day-to-day work. The scenarios are grounded in practical, recognisable situations.

Can a candidate retake the assessment?

No. Each invitation link is single-use and expires after seven days. If you want to send a new invitation, that's a separate invite. This is intentional, the assessment is designed to capture a first-read response, not a rehearsed one.

Do candidates need an account?

No. They receive a link by email, open it in a browser, complete the assessment, and submit. Nothing to install, no login to create.

Pricing and access

How does pricing work?

You pay per candidate, not per seat or per month. The base price covers one assessment. Each additional assessment in the same invitation adds a small flat fee. No subscription, no expiring credits, no annual contracts. If you're not hiring, you don't pay.

Still have a question?

Reach us at support@critic.codes. We read everything.