DSA
Which Programming Language Should You Use in a Coding Interview? The Data
Data from 2,910 engineers and 79,429 real submissions: first-attempt pass rates for Java, Python and C++ in coding interview practice, by difficulty.

Across 2,910 engineers and 79,429 real, graded code submissions on Thita.ai, Java shows the highest first-attempt pass rate at 41.2%, C++ follows at 39.9%, and Python trails at 37.0% — even though Python is the second most-used language on the platform. This is a first-of-its-kind, data-backed look at how language choice actually correlates with first-attempt success in coding interview practice, straight from platform submission history rather than opinion or forum debate.
Why "which language should I use?" has never had real data behind it
Every "best language for coding interviews" thread ends the same way — a mix of "use what you know," "Python is fastest to write," and "C++ runs fastest so you look sharper on the whiteboard." None of it is backed by outcome data, because nobody outside a platform with real, graded submission logs across languages can measure it. Thita.ai's code execution history gives us that data for the first time. This post publishes it, with the full methodology linked at the bottom.
What "first-attempt pass rate" means here
For every (user, problem, language) combination with at least one real, executed submission, we look at that user's first graded submission in that language for that problem and ask: was it accepted? The first-attempt pass rate for a language is the share of those first attempts that passed, across every problem attempted in that language. This is the exact same definition used in our companion study on the hardest DSA patterns — only the grouping key changes, from pattern to language. It is not the eventual pass rate (almost everyone eventually solves a problem they stick with); it measures how often a submission in that language is correct the first time.
Which languages are actually used
Of the seven language values that appear in submission history, only three clear the k≥50-distinct-user publication bar used across every Thita.ai research post. The other four — JavaScript, Go, C, and a "design" track — are used almost exclusively for non-executed analysis submissions rather than real graded runs, so there isn't enough first-attempt data to publish a rate for them responsibly.
| Language | Share of submissions | Share of users | First-attempt pass rate | Median attempts to pass |
|---|---|---|---|---|
| Java | 41.5% | 36.7% | 41.2% | 2 |
| Python | 30.4% | 35.0% | 37.0% | 2 |
| C++ | 28.1% | 33.1% | 39.9% | 2 |
(Share of users doesn't sum to 100% — a user who submits in more than one language is counted once per language they used. n_users=2,910, n_submissions=79,429 across all languages before the k≥50 suppression; 1,069 Java users, 1,018 Python users, 963 C++ users, each individually above the k=50 floor.)
Java is both the most-used language on the platform and the one with the highest first-attempt pass rate. Python is a close second in raw usage but has the lowest first-attempt pass rate of the three. C++ is used least of the three but posts a pass rate almost as high as Java's.
Pass rate by language and difficulty
Splitting first-attempt pass rate by problem difficulty (Easy / Medium / Hard, technical_problems.difficulty) shows the Python gap concentrated at the easier end, and a reversal at the hard end:
| Language | Easy | Medium | Hard |
|---|---|---|---|
| Java | 40.7% | 40.8% | 50.1% |
| C++ | 40.9% | 39.1% | 40.9% |
| Python | 34.4% | 38.2% | 48.8% |
On Easy problems, Python's first-attempt pass rate (34.4%) is nearly 6.5 points behind Java and C++ — consistent with Python being forgiving enough that engineers reach for it on problems they haven't fully thought through first, then iterate. On Hard problems the pattern flips: Java (50.1%) and Python (48.8%) both post higher first-attempt pass rates than on Easy or Medium, while C++ stays roughly flat around 41%. That is very unlikely to mean Hard problems are objectively easier to nail on the first try in Java or Python than in C++ — see the confounders below before drawing that conclusion.
Two of the nine language x difficulty cells (Java/Hard: 108 users, Python/Hard: 81 users) are close to the k=50 floor — real signal, but on a thinner base than the Easy/Medium cells (600–800 users each), so treat the Hard-tier numbers as more provisional.
Read this as descriptive, not causal
This is observational platform data, not a controlled experiment, and several confounders cut against a simple "use Java, skip Python" takeaway:
- Self-selection. Engineers choose their language before they choose which problems to attempt. A Java-primary engineer who only ever solves problems in Java is a different (and possibly more experienced, or more deliberately-practicing) population than a Python engineer who reaches for Python on unfamiliar problems specifically because it's faster to sketch in.
- Problem mix isn't identical across languages. Nothing forces a user's Java attempts and Python attempts to be the same set of problems — someone comfortable in Python may disproportionately attempt problems they find easier, and vice versa. The by-difficulty cut above only partially controls for this; it doesn't control for which specific problems within a difficulty tier each language's users chose.
- Verbosity and compiler feedback differ by language. Java and C++ both fail loudly at compile time before a test case even runs (a
compilation_errorstatus, which counts as a real, failed attempt in this study). Python fails later, at runtime or on a wrong answer. That changes what a "first attempt" typically looks like structurally, independent of the engineer's actual algorithmic correctness. - Fluency, not language design, is doing most of the work. These numbers say nothing about which language is inherently better for interviews — only how first attempts in each language perform, in aggregate, across the specific population of engineers who chose that language on Thita.ai.
The practical takeaway isn't "switch languages" — it's that whichever language you use, practicing the patterns that actually get asked (try Two Sum if you want a concrete starting point) matters more than the language wrapper around your solution. Fluency in your chosen language, applied to the right patterns, is what first-attempt pass rate is really measuring.
Methodology
Data sources. user_code_submissions (user_id, problem_id, language, status, submitted_at only — never submitted_code or error_message) and technical_problems (id, difficulty) for the difficulty cut. code_runs (1,704 rows at snapshot time) was inspected but has no language or problem_id column of its own and is two orders of magnitude smaller than user_code_submissions, so it was not joined into this study.
Definitions. A submission counts as a real attempt if its status reflects an executed, graded run (accepted, wrong_answer, compilation_error, partial, runtime_error, timeout, execution_error, failed, etc.) — statuses that never executed code (analysis_mode, analysis_only, canvas_submitted, no_template, no_template_analysis) are excluded, matching the hardest-patterns study's definition exactly. First-attempt pass rate is computed per (user, problem, language) triple: a user solving the same problem in two languages produces two independent triples, one per language. "Passed" means status accepted, passed, or success.
The suppression rule (k-anonymity). Any cell — a language row, or a language x difficulty cell — with fewer than 50 distinct users is suppressed entirely from this post and from the published data file, applied uniformly to every statistic in that cell (submission share and user share included, not only the pass rate). JavaScript, Go, C, and the "design" track were suppressed at the language level (2–33 distinct users each, and almost entirely non-executed analysis_only/analysis_mode/canvas_submitted statuses rather than real attempts). Two of nine language x difficulty cells (Java/Hard, Python/Hard) cleared the floor but sit closer to it (81–108 users) than the six larger cells (600–800 users).
Exclusions. Problems with no difficulty set on technical_problems are excluded from the by-difficulty cut only (none in this snapshot). No per-user or free-text data was ever read beyond in-memory aggregate counts.
Limitations. This is a single snapshot (2026-09-07), not a longitudinal or controlled comparison; see "Read this as descriptive, not causal" above for the confounders that matter most (self-selection into language, non-identical problem mix per language, and language-specific failure-mode timing). We plan to refresh this snapshot on the same quarterly cadence as our other data posts.
What we never publish. Individual user IDs, submitted code, error messages, or any cell — at any granularity — with fewer than 50 distinct backing users.