Skip to content
Test Candidates

Programming tests

What these tests are, what they deliberately are not, and how to use them in a technical hiring process.

Last updated 21 September 2026

The largest family in the library: tests on programming languages, frameworks and the tools around them.

The test library filtered to a family, with cards showing each test's skills, duration, format and difficulty.

What the programming range covers

Languages such as Python, Java, JavaScript, TypeScript, C, C++, C#, Go, Rust, Ruby, PHP, Swift, Kotlin, R and Bash. Frameworks and platforms including React, Angular, Node.js, Django, Laravel, Spring, Flutter, Ruby on Rails, iOS, Android, WordPress and Drupal. Data and web foundations including SQL, MySQL, PostgreSQL, HTML5, CSS, REST APIs, Linux and Selenium.

These are multiple-choice tests

This is the most important thing on this page, and the thing most likely to catch you out if you have used other tools.

Candidates do not write code and nothing is executed. There is no editor, no test runner and no take-home task. Each test is a set of multiple-choice questions about the language or framework, answered under a clock.

Say that plainly to your engineering team before you send one out. An engineer who expects a coding exercise and sees a quiz will lose confidence in the process, and they would be right to ask.

What they are good for

Screening at the top of a funnel. When forty people applied and you can review five, a short test on the language the job is actually written in narrows that honestly and consistently.

Checking a claim. A CV that lists ten technologies is worth a quick check on the one that matters.

Breadth across a stack. Knowing whether someone who is strong in a language also knows the database and the deployment tooling around it.

What they are not good for

Judging how someone builds software. Design, testing, debugging under pressure, reading someone else's code and working with other people are not in here and cannot be. A multiple-choice score does not establish technical competence, and the test's own guide says exactly that.

Use these to decide who to spend an hour with. Use a real exercise, a pairing session or a conversation about their own work to decide who to hire.

Practical advice on programming tests

  • Test the language the job uses, not the one you like.
  • One test is usually enough. A stack test plus a language test is reasonable; four is an endurance event.
  • Pair it with a reasoning test if you are hiring juniors, where knowledge is thin but learning speed matters.
  • Read the answer-by-answer chart, not just the score. A strong candidate who ran out of time looks very different from one who guessed throughout.

Something specific to your codebase

The library cannot know about your own systems. Write your own multiple-choice test if you need that. See build a custom test.