---
title: Capgemini Interview Questions & Process (2026 Guide for Freshers)
description: A 2026 guide to the Capgemini interview for freshers — the game-based aptitude assessment, pseudocode, technical and HR rounds, rejection reasons, and a 3-week prep timeline.
url: https://usegreenroom.app/blog/capgemini-interview-questions
last_updated: 2026-06-20
---
← Back to blog
India · Capgemini
# Capgemini interview questions and process
June 20, 2026 · 25 min read
Picture the campus placement hall at 9 AM: two hundred final-year students, one shared WiFi router visibly struggling, and a proctoring webcam that somehow makes everyone look like they're being interrogated. You open the Capgemini assessment, expecting the usual "train leaves station A at 60 km/h" aptitude questions you've drilled for weeks — and instead you're playing what looks suspiciously like a mobile game, matching falling shapes against a timer, while a tiny voice in your head asks, "is this actually testing anything, or did I accidentally open the wrong tab?" Three friends ahead of you in the queue, who spent their entire prep month on quant tricks and zero minutes on this, walk out twenty minutes later looking like they've seen a ghost.
That mismatch — prepping for the interview you expect instead of the one that's actually coming — is the single biggest reason strong candidates get filtered out at Capgemini before they ever speak to a human. Capgemini recruits freshers in large numbers every placement season, and its hiring funnel has a few quirks that catch people off guard if they walk in expecting a standard DSA-heavy tech interview. The online assessment leans on **game-based aptitude** rather than plain MCQs, weighs **pseudocode** far more heavily than most candidates expect, and includes a dedicated **English/communication test** before you ever speak to a human. Clear those filters, and the technical and HR rounds are forgiving of candidates who have solid fundamentals and can talk about their own work clearly — they are not looking for competitive-programming wizardry. This guide walks through every stage in the depth it actually deserves: what each part of the assessment is really measuring, the kinds of questions you'll see in the technical and HR rounds, why candidates with correct answers still get rejected, and a realistic week-by-week plan to prepare — so the only thing that surprises you on test day is how calm you feel.
## The Capgemini interview process
Capgemini's fresher hiring (largely through campus placements and the Capgemini Aspire / off-campus drives) typically runs through four stages, though the exact count varies by drive and year.
- **Online assessment** — a single sitting that bundles game-based aptitude, a pseudocode/logical-reasoning section, and an English communication test. This is the biggest filter: most rejected candidates are cut here, not in the interview.
- **Technical interview** — one-on-one or panel, covering core CS fundamentals (OOP, DBMS/SQL, basic data structures), a walkthrough of your academic or personal project, and often a simple coding or pseudocode question solved live.
- **HR interview** — sometimes combined with the technical round, sometimes separate. Covers your background, motivation for joining, and — distinctively for Capgemini — your flexibility on location, shift, and technology stack.
- **Offer and documentation** — background verification, offer letter, and (for campus hires) a joining-date communication that can be months after the interview, which is itself worth planning around.
The order and number of rounds shift slightly between the campus drive and the off-campus/Capgemini Aspire route, but the content tested — aptitude/pseudocode, fundamentals, project, fit — stays consistent. Knowing this structure in advance matters more than it sounds: candidates who don't know the assessment is heavily pseudocode-weighted often spend their prep time on generic quantitative aptitude and get blindsided.
## Online assessment in depth
### What do the game-based aptitude sections actually test?
Capgemini's assessment platform (commonly delivered through a gamified testing vendor) replaces some traditional quant/verbal MCQs with short interactive games — things like a card-matching or sequence-prediction game, a resource-allocation puzzle, or a reaction-time/pattern game with a timer. These aren't testing whether you can play games; they're proxies for **pattern recognition speed, working memory under time pressure, and decision-making consistency** — how quickly you spot a rule, and whether your accuracy holds up as the game speeds up or the rules get more complex. The practical implication is that these games reward calm, fast pattern-matching more than memorized formulas, so the best prep is timed practice on similar gamified-aptitude platforms (several free mock versions exist online) rather than re-deriving permutation-and-combination tricks. Don't overthink the game's "story" — focus on finding the underlying rule in the first 2-3 rounds and then executing it quickly and consistently.
### Why does pseudocode carry so much weight?
Capgemini's assessment is unusually pseudocode-heavy compared to other IT-services recruiters, because the role you're hiring into is overwhelmingly about reading and maintaining other people's code, not writing novel algorithms from scratch. Pseudocode and output-prediction questions test whether you can mentally trace execution — track variable values through loops, follow nested conditionals, and catch off-by-one errors — which is exactly the skill you'll use on day one debugging a client's codebase. Most candidates underestimate this section because it "looks easy" on a first read; the actual difficulty is in tracing carefully under time pressure without a compiler to check your work, and small mistakes (loop boundary, variable reuse) compound fast.
### Sample pseudocode question 1 — nested loop trace
```
SET total = 0
FOR i = 1 TO 3
FOR j = 1 TO i
total = total + j
END FOR
END FOR
PRINT total
```
Walk through it by hand rather than guessing: when `i = 1`, the inner loop runs once (`j = 1`), adding 1, so `total = 1`. When `i = 2`, the inner loop runs for `j = 1, 2`, adding 1 then 2, so `total = 1 + 1 + 2 = 4`. When `i = 3`, the inner loop runs for `j = 1, 2, 3`, adding 1, 2, 3, so `total = 4 + 1 + 2 + 3 = 10`. The output is `10`. The reasoning skill being tested is not "can you add numbers" — it's whether you maintain a running value correctly across two nested loop variables without losing track of which loop you're in, which is the single most common source of wrong answers on this question type.
### Sample pseudocode question 2 — conditional and array logic
```
SET arr = [4, 9, 2, 7, 5]
SET count = 0
FOR i = 0 TO LENGTH(arr) - 1
IF arr[i] MOD 2 == 0 THEN
count = count + 1
END IF
END FOR
PRINT count
```
Here you're tracing which elements are even: 4 is even (count becomes 1), 9 is odd, 2 is even (count becomes 2), 7 is odd, 5 is odd. The output is `2`. The trap most candidates fall into is misreading `LENGTH(arr) - 1` as the array length itself rather than the last valid index, which either causes an off-by-one skip or an out-of-bounds read depending on the language convention assumed — exactly the kind of boundary-condition slip the test is designed to surface.
### Sample pseudocode question 3 — function call and recursion-adjacent logic
```
FUNCTION double_if_positive(x)
IF x > 0 THEN
RETURN x * 2
ELSE
RETURN 0
END IF
END FUNCTION
SET result = 0
FOR i = -2 TO 2
result = result + double_if_positive(i)
END FOR
PRINT result
```
Trace each call: `double_if_positive(-2)` returns 0, `double_if_positive(-1)` returns 0, `double_if_positive(0)` returns 0 (since the condition is strictly `> 0`), `double_if_positive(1)` returns 2, `double_if_positive(2)` returns 4. Summing gives `0 + 0 + 0 + 2 + 4 = 6`. This question is testing whether you read the boundary condition exactly as written (`> 0`, not `>= 0`) rather than assuming — Capgemini's pseudocode questions frequently hinge on a single boundary operator like this, and skimming the condition is the most common reason correct-seeming answers turn out wrong.
### What does the English/communication test assess, and where do candidates lose marks?
This section typically includes grammar correction, sentence reordering, reading comprehension, and sometimes a short written response, and it exists because Capgemini staffs client-facing delivery teams where unclear written or spoken English directly costs the company credibility with clients. The most common point losses aren't exotic grammar rules — they're basic subject-verb agreement, tense consistency across a paragraph, and misreading comprehension passages too quickly under time pressure. Candidates who read regularly in English and who practice writing complete, grammatically clean sentences (not just "getting the gist") tend to clear this section comfortably; it rewards careful reading more than vocabulary size.
### Sample pseudocode question 4 — string and character logic
```
SET word = "PROGRAMMING"
SET vowels = 0
FOR i = 0 TO LENGTH(word) - 1
SET ch = word[i]
IF ch == 'A' OR ch == 'E' OR ch == 'I' OR ch == 'O' OR ch == 'U' THEN
vowels = vowels + 1
END IF
END FOR
PRINT vowels
```
Trace it letter by letter: P, R, O (vowel, count 1), G, R, A (vowel, count 2), M, M, I (vowel, count 3), N, G. The output is `3`. This one tests careful character-by-character scanning rather than any tricky logic — the actual difficulty Capgemini builds in is purely about not losing your place partway through a longer string, which is why writing out the trace on scratch paper (mentally checking off each letter) beats trying to do it entirely in your head under time pressure.
### Sample pseudocode question 5 — a two-variable swap trap
```
SET a = 5
SET b = 10
SET a = b
SET b = a
PRINT a, b
```
This one is a deliberate trap testing whether you catch a classic bug: after `SET a = b`, `a` becomes `10`. But then `SET b = a` sets `b` to the *new* value of `a`, which is now `10` — not the original value of `a` (5) that a naive swap would expect. So the output is `10, 10`, not `10, 5` as many candidates instinctively (and incorrectly) assume a "swap" would produce. The lesson Capgemini is testing here is whether you trace state *exactly as written* rather than pattern-matching to "oh, this looks like a swap" and assuming the intuitive outcome — a real swap requires a temporary variable, and this pseudocode deliberately omits one.
## Technical interview questions
### OOP concepts with examples
Expect the interviewer to ask you to define and *exemplify* each pillar, not just name it: encapsulation (bundling data and methods, e.g., a `BankAccount` class hiding its balance behind deposit/withdraw methods rather than exposing the variable directly), inheritance (a `Manager` class extending `Employee` to reuse and override behavior), polymorphism (a `draw()` method that behaves differently for `Circle` vs `Square` objects), and abstraction (an interface or abstract class that defines *what* a payment processor does without committing to *how*). The follow-up that trips people up is "why would you use this instead of just writing it directly" — interviewers want to hear you connect each concept to a maintainability or reuse benefit, not just recite the definition. If your project used any OOP language, be ready to point to one real class you wrote and explain which principle it demonstrates (our OOPs guide covers this in more depth).
### SQL and DBMS fundamentals
You should be able to write a basic `SELECT` with a `WHERE`, `GROUP BY`, and `JOIN` without hesitation, and explain the difference between an `INNER JOIN` and a `LEFT JOIN` with a concrete example (e.g., a `LEFT JOIN` from customers to orders still returns customers with zero orders, with `NULL` order fields). Expect conceptual questions too: primary key vs foreign key, what normalization solves (removing redundant data and update anomalies) and a rough idea of 1NF/2NF/3NF, and the difference between `DELETE` and `TRUNCATE` (DELETE is row-by-row and can be rolled back within a transaction; TRUNCATE deallocates the whole table's data and is typically not individually rollback-friendly). Interviewers are checking whether you can reason about data correctly, not whether you've memorized every normal form by number (our SQL guide goes through more examples).
### Project deep-dive questions an interviewer will actually ask
Almost every Capgemini technical round spends real time on your final-year or personal project, and the questions are rarely about the topic itself — they're about whether you understand what you built. Expect: "What was your specific role if this was a team project?", "Why did you choose this database/framework over the alternatives?", "What was the hardest bug you hit, and how did you find it?", "If you had to scale this to 10x the users, what would break first?", and "What would you do differently if you rebuilt it today?" The candidates who struggle here aren't the ones with simple projects — they're the ones who can recite what the project does but freeze the moment they're asked *why* a specific decision was made, which immediately signals the project wasn't really theirs.
### A simple coding question — what it's testing
You might be asked something like "write a function to check if a string is a palindrome" or "find the second-largest number in an array" — deliberately simple, solvable in under ten minutes on a whiteboard or shared doc. The point isn't algorithmic sophistication; it's whether you can translate a plain-English problem into working code without hand-holding, talk through your approach before typing, and handle an edge case (empty string, array with duplicates) when the interviewer nudges you toward one. Freezing on an easy problem because of nerves is a far more common failure mode here than not knowing the algorithm.
### Programming language and basics questions
Pick one language you're genuinely comfortable in (usually whatever you used most in coursework or your project) and expect questions on its fundamentals: difference between `==` and `.equals()` if it's Java, mutable vs immutable types, how exceptions are handled, and basic memory concepts like stack vs heap. Capgemini interviewers tend to go a layer deeper than "define this" — for example, after you explain exception handling, they may ask you to identify what happens if an exception is thrown inside a `finally` block, checking whether your understanding is real or surface-level.
Capgemini's pseudocode round and English matter as much as the interview.
### Basic data structures questions you should expect
Even though Capgemini's coding bar is low compared to a product company, you should be comfortable with arrays (searching, sorting conceptually, basic time complexity of linear vs binary search), linked lists (singly linked list traversal and insertion, since pointer/reference manipulation questions are common), and stacks/queues (LIFO vs FIFO, and a real-world example of each — undo functionality for a stack, a print queue for a queue). The interviewer's actual goal is checking whether you understand *when* to reach for each structure, not whether you can implement a self-balancing tree from memory — a candidate who says "I'd use a queue here because tasks need to be processed in the order they arrived" demonstrates more than one who can recite Big-O notation for ten different structures without being able to apply any of them.
### A typical live coding exchange, and how interviewers actually grade it
Most Capgemini coding questions are presented conversationally rather than on a strict judge, which changes what "doing well" looks like. If asked to find the second-largest number in an array, a strong candidate says their plan out loud first — "I'll track the largest and second-largest as I scan through once, updating both as needed" — before writing a single line, and only then translates that plan into code. A weaker candidate jumps straight to typing, gets partway through, and has to backtrack when an edge case (duplicate maximum values, an array with fewer than two elements) surfaces mid-write. Interviewers are explicitly trained to value the "think out loud, then code" sequence over silent typing followed by a working answer, because client-facing delivery work is mostly explaining your reasoning to other people — a skill the live coding round is quietly testing alongside the code itself.
## HR interview questions
### What does "fit" actually mean at Capgemini?
Capgemini hires at scale into a delivery-consulting model, which means "fit" is less about matching a specific personality type and more about whether you can be deployed flexibly across client accounts, technologies, and sometimes locations without friction. HR interviewers are listening for stability signals — can you commit to roughly the standard service-agreement period, do you understand this is client-services work (not a product-engineering role with full autonomy over what you build), and do you communicate calmly under the kind of ambiguity that comes from working on a client's codebase rather than your own. A candidate who's technically excellent but rigid about exactly what technology or city they'll work in is a real rejection risk here, regardless of test scores.
### "Are you flexible on location and technology?" — how to actually answer it
This question is asked almost verbatim in nearly every Capgemini HR round, and a flat "yes" without context reads as rehearsed, while a flat "no" or heavily hedged answer reads as a risk flag. The strongest answers acknowledge a genuine preference while showing openness — for example, naming the technology stack you're most excited to grow in, while being honest that you understand entry-level roles often mean working on whatever the client needs first. On location specifically, if you do have hard constraints (family, health), it's better to state them plainly and early than to say yes now and walk it back after the offer, which damages trust far more than an honest "yes, with X consideration" would have.
### Tell me about yourself, and why Capgemini
"Tell me about yourself" is not a request for your resume read aloud — it's a 60-90 second narrative that should land on why you're a good fit for *this* kind of role specifically: client-facing IT services, broad technology exposure, structured delivery work. "Why Capgemini" answers that name something specific (its presence in your target domain, the scale of its India delivery centers, a particular practice area) land far better than generic "great company, great culture" answers, because they show you actually looked the company up rather than reusing the same answer for every recruiter.
### Strengths, weaknesses, and handling pressure
Pick a strength you can back with a concrete example from your project or coursework, not an adjective alone — "I'm good at debugging" is forgettable, "I once spent two days tracing a race condition in my project's booking logic and built a logging habit because of it" is memorable. For weaknesses, choose something real and already-in-progress rather than a humblebrag ("I'm a perfectionist") — interviewers have heard the humblebrag version hundreds of times and it signals you didn't think about the question. For handling pressure, a short specific story (a deadline crunch, an exam period, a team conflict you helped resolve) beats a general claim about being "a calm person under stress" every time.
### Questions about availability, relocation, and notice period
Be ready for direct logistics questions — when you can join, whether you're open to a different city than where you interviewed, whether you have other offers in hand. Honesty here is not just an ethical default, it's strategically correct: Capgemini's HR teams interview at volume and have heard every form of vague non-answer, and a candidate who's clear and consistent about their actual constraints comes across as more trustworthy than one who agrees to everything in the room.
The core truth: Capgemini's filters reward pseudocode logic and clear English as much as the interview itself, and the HR round is really testing flexibility and stability signals, not charisma. Clear the assessment, explain your project like you actually built it, and answer the flexibility questions honestly, and you're through.
## Common reasons candidates get rejected
### Weak communication or confidence, even with correct technical answers
The single most common rejection reason in fresher IT-services interviews — Capgemini included — is not wrong answers; it's a candidate who knows the material but delivers it hesitantly, in fragments, or with long silences while thinking. Interviewers read hesitant delivery as uncertainty even when the underlying knowledge is solid, because in client-facing roles, how you communicate *is* part of the job, not separate from it.
### Inability to explain their own project clearly
A surprising number of candidates can describe what their project does but stumble the moment they're asked about a specific design decision, a bug they hit, or their individual contribution on a team project. This reads as the project not really being understood at a level deep enough to defend — which is exactly what the project deep-dive questions are designed to surface.
### Rigid or inflexible answers on relocation and technology
Flatly refusing to consider a different location or technology stack, or answering "are you flexible" defensively, signals a deployment risk in a company built around moving people across client accounts. This doesn't mean abandoning genuine constraints — it means presenting them as considerations rather than ultimatums.
### Weak pseudocode or logical-reasoning performance
Because the assessment is pseudocode-heavy, candidates who treat it as an afterthought and focus prep time only on "interview questions" often get filtered out before ever reaching a human interviewer. This is the most preventable rejection reason on this list, because it's purely a function of practice volume on output-prediction questions.
### Not researching the company at all
Generic answers to "why Capgemini" — or worse, confusing Capgemini's business with a different IT-services company — signal low genuine interest. Even ten minutes spent learning Capgemini's major service lines and a recent piece of news about the company meaningfully changes how an HR interviewer reads your motivation.
### Treating the HR round as a formality after clearing the technical round
A specific and avoidable mistake: candidates who relax noticeably once the technical interviewer says "good, that's all from me" and walk into the HR round half-checked-out, giving flat one-line answers because they assume the hard part is over. HR interviewers at scale-hiring companies like Capgemini have rejection authority too, and a candidate who visibly stops trying the moment the technical bar is cleared reads as someone who'll coast once they have an offer — the opposite of the sustained-engagement signal HR is actually screening for.
## A realistic prep timeline
### Week 1 — aptitude and pseudocode practice
Spend the bulk of week one on timed pseudocode and output-prediction practice (loops, conditionals, arrays, simple functions, exactly like the three examples above), alongside short daily sessions on gamified-aptitude practice platforms to get comfortable with the format and pacing rather than the content. Layer in 15-20 minutes a day of English practice — reading a short article and rewriting its summary in your own words is a better use of time than memorizing vocabulary lists.
### Week 2 — technical fundamentals and project narrative
Shift focus to OOP (with your own examples for each pillar, not textbook ones), core SQL queries and normalization concepts, and one pass through basic data structures. In parallel, write out a one-page narrative of your main project: your specific role, the toughest decision you made, the hardest bug, and what you'd change — then read it aloud once a day so the explanation becomes natural rather than memorized.
### Week 3 — mock interviews and HR rehearsal
Run full mock interviews that combine technical questions with HR questions, specifically rehearsing "are you flexible on location/technology" and "why Capgemini" out loud until your answer sounds considered rather than rehearsed-by-rote. This is also the week to do a final timed pseudocode practice set under exam-like conditions, since speed under pressure — not just correctness — is what the real assessment measures.
### What to do the night before, and the morning of
Don't cram new pseudocode patterns the night before — at that point you're more likely to introduce doubt than gain ground, and tired pattern-matching is worse than confident pattern-matching on slightly less material. Instead, re-read your one-page project narrative once, out loud, and review only the boundary-condition traps you've already gotten wrong in practice (off-by-one loop bounds, strict `>` vs `>=`, array length vs last index) since those are exactly the kind of small slip that resurfaces under fresh pressure. The morning of, do one short timed pseudocode set just to get your pattern-recognition "warmed up," the same way you wouldn't walk into a sprint cold — and have your "why Capgemini" and "are you flexible" answers loaded and ready, not because you'll recite them verbatim, but because having said them out loud recently means they'll come out steady instead of halting.
## How GeeksforGeeks, a friend's WhatsApp PDF, and ChatGPT stack up against actually rehearsing this out loud
Almost every fresher prepping for Capgemini reaches for the same three resources, and each one covers a different slice of what actually gets tested — none of them cover the part that decides most outcomes: how you sound saying the answer out loud, live.
**GeeksforGeeks-style question banks** are the default starting point, and reasonably so — they're comprehensive, free, and organized by topic, which makes them genuinely useful for building a checklist of what to study (OOP pillars, SQL joins, normalization). Where they fall short for Capgemini specifically is the pseudocode and output-prediction section: reading ten solved pseudocode traces is not the same skill as tracing a fresh one cold, under a countdown timer, with no compiler to check your work — and that's exactly the gap the real assessment is built to expose.
**The senior's WhatsApp-forwarded "Capgemini Questions PDF"** circulates every placement season, and it has real value as a study list — it tells you roughly what got asked last year. Its limits are equally real: it's frozen in time (Capgemini tweaks its assessment format periodically), it's one-directional (no way to check if your spoken answer to "why Capgemini" actually sounds genuine or rehearsed-flat), and it gives zero feedback when you confidently misjudge how the flexibility question should be answered.
**Typing your self-introduction into ChatGPT and asking it to "make this sound better"** produces a polished paragraph that you then have to memorize and recite — which is precisely the failure mode HR interviewers are trained to spot. A memorized, written-then-recited answer has a different cadence than a spoken, thought-through one, and experienced interviewers catch the difference within the first fifteen seconds. The skill Capgemini's HR round actually tests is *thinking on your feet while sounding composed*, not reciting a paragraph someone (or something) else wrote for you.
**Greenroom's difference is that it makes you produce the answer out loud and then questions you on it**, the same way an actual HR interviewer or technical panelist would. Ask Greenroom to mock a Capgemini-style round and it will ask "are you flexible on location and technology," listen to your actual spoken answer, and follow up if it sounds rehearsed or evasive — exactly the kind of probing a real interviewer does and a PDF or chatbot transcript cannot replicate. The honest tradeoff: Greenroom won't generate your pseudocode practice sets or teach you SQL from zero — pair it with a question bank for content coverage. What it adds is the rehearsal loop those resources skip entirely: saying it, getting pushed on it, and saying it better the next time.
## How to prepare
Practise pseudocode and output questions for the assessment, and rehearse your interview answers out loud rather than just reading them silently — the gap between recognizing a good answer and producing one fluently under interview pressure is exactly where most candidates lose points. [Greenroom](/) runs spoken mock interviews with technical and HR questions and gives feedback on clarity, not just correctness, so you can practice explaining your project and answering flexibility questions the way you'll actually need to in the room. Pair it with our aptitude prep guide and campus placement guide.
## Frequently asked questions
### What is the Capgemini interview process?
Capgemini's process includes an online assessment with a game-based aptitude section, a pseudocode test on logic and programming concepts, and an English/communication test, followed by a technical interview on core CS and your project and an HR interview on communication, fit and flexibility.
### Is pseudocode important for the Capgemini exam?
Yes, pseudocode is one of the most heavily weighted sections of the Capgemini assessment. Expect questions that ask you to predict the output of pseudocode or identify the correct logic, covering loops, conditionals, arrays and basic programming concepts. Practising output-prediction questions is essential.
### What technical questions does Capgemini ask in the interview?
Capgemini asks pseudocode and output-prediction questions, OOP concepts with examples, basic SQL and DBMS, a walkthrough of your project, and a simple coding question. The interview emphasizes clear fundamentals and the ability to explain your project, rather than hard algorithmic problems.
### How should I answer "are you flexible on location and technology"?
Acknowledge a genuine preference while showing openness rather than giving a flat yes or no — name the technology you're most excited to grow in, and be honest about any real constraints rather than agreeing to everything and walking it back later. Capgemini's HR teams are listening for deployment flexibility and trustworthiness, not just agreeableness.
### What are the most common reasons candidates get rejected at Capgemini?
The most common reasons are weak communication or confidence even when the technical answer is correct, an inability to explain their own project's decisions clearly, rigid answers on relocation or technology flexibility, weak performance on the pseudocode section, and not researching the company before the HR round.
### How do I prepare for the Capgemini interview?
Practise pseudocode and output-prediction questions and a clear English communication test for the assessment, then rehearse your self-introduction, project explanation and HR answers out loud. A voice-based mock interview that asks technical and HR questions and gives feedback on clarity helps you sound confident and structured.
Capgemini rewards pseudocode logic and clear communication. Greenroom lets you rehearse a real voice interview with feedback on clarity. Free to start.