Client round interview questions, with sample answers

"The closest is my current project for [a US retail client]. We maintain their order management system, built on [Java, Spring Boot and Oracle], and I work mainly on the [returns and refunds] module. From your job description, your project also handles [order workflows and integrations with payment providers], so the domain and most of the stack would be familiar. The part that would be new for me is [Kafka], which I've used in a side project but not yet in production."

Name the overlap honestly, and name the gap yourself before they find it.

"I'm one of [five] developers on the team. I pick up stories from the sprint backlog, write the code and unit tests, and raise pull requests that the tech lead reviews. For the last six months I've also been the main point of contact for [the refunds module], so when the client's QA team finds a defect there, it comes to me first and I fix it or explain the behaviour."

"I start at [10 am], check overnight emails and any failed builds, then join our stand-up at [10:30]. Most of the day goes into my sprint stories. Our client overlap is from [6:30 pm to 8 pm IST], when we have a short sync with their team, demo anything that's ready, and clear doubts on upcoming stories. Before I log off, I update the ticket with what I finished and what's pending, so the client sees progress when their day starts."

"I make the overlap hours count: I bring my questions to the daily sync prepared, with screenshots or a short write-up, so one call answers them. Outside the overlap, I write updates that someone can understand without a call: what I did, what's blocked, and what I need from them. If something is urgent outside the overlap, I agree in advance with the client on how to reach them, so it doesn't wait a whole day."

"As soon as I know, not on the due date. I'd say: 'The [export feature] will take two days more than planned, because the [vendor's API] returns data in a different format than the spec. I've already written the conversion; what's left is testing it with real data. I can deliver it on [Thursday] instead of Tuesday, or deliver the main export on Tuesday and the edge cases on Thursday. Which works better for you?'"

Give the reason, what you've done, a new date, and an option. A delay with a plan sounds responsible; a delay discovered on the deadline sounds careless.

"I write down my understanding as a short list: what the feature does, the inputs, the outputs and the edge cases I can think of. Then I send it to the client's business analyst or product owner and ask them to confirm or correct it. If a decision is needed quickly, I bring it to the next sync. Once it's confirmed, I add the agreement to the ticket, so there's no confusion later about what was asked."

"I'd be honest that I haven't used [Terraform] in a real project yet. I have used [AWS CloudFormation], so the idea of infrastructure as code isn't new. In my first week I'd go through the official getting-started guide, read your repository's existing modules to see how your team uses it, and ask for one small, low-risk task so I learn on real code with a reviewer. When I learned [Kafka] last year, I followed the same approach and was making changes on my own within a few weeks."

"I write unit tests for the logic I change and run the full test suite before raising a pull request. I test the main scenarios and the edge cases myself in our test environment, not just the happy path. Every change goes through a peer review, and I attach a short note on what I tested. If I'm unsure whether something affects another module, I ask its owner before merging rather than after."

"Last [March], refunds stopped processing for about an hour after a release. I was on support that week. First, we rolled back the release, which restored refunds, and I informed the client's support lead within fifteen minutes. Then I found the cause: a configuration value that was correct in testing but missing in production. I added a startup check that fails the deployment if the value is missing, and we added that check to our release checklist. It hasn't happened again."

The order matters: restore service, inform the client, fix the cause, prevent a repeat.

"I'd explain my concern with facts, privately or in a small call, not in a big meeting. For example, a client developer once wanted to skip pagination on a report to save time. I showed that the report would load about [50,000] rows at once and timed the page with real data. We agreed to add pagination, and to deliver the rest of the report first so the deadline held. If we still disagree after discussing it, it's their product, so I go with their decision and note my concern in the ticket."

"I'm comfortable with it; I join our weekly demo with the client's [operations team]. I avoid jargon, start with what changed for them, and show it on screen rather than describing it. For example, instead of saying 'we added an index', I'll say 'the order search now loads in under a second instead of eight'. If I'm asked something I don't know, I say I'll confirm and follow up the same day."

"First, I write a clear message to that person with exactly what I need, so they can answer as soon as they're back. Then I check whether anyone else can answer it, such as our tech lead or the client's documentation. Meanwhile, I move to the next task in the sprint that doesn't depend on the answer, so the day isn't lost. And I mention the blocker in the stand-up, so the team knows it's there."

"Every ticket I close has a short note on what changed and why. For anything larger, such as a new integration, I update the module's README or the project wiki with the setup steps and known issues. When I hand over work, I record a short walkthrough or write a handover document, so the next person doesn't have to start from zero."

"Three reasons. I've spent [two] years in the same domain, so I understand your workflows. I know most of your stack and I'm clear about the part I'll need to learn. And I communicate early: you'll hear about problems from me before they become your problem. I'd like to be the person on the vendor team you don't have to chase."

Ask two or three of these:

• "What are the main priorities for the next three months?"
• "How is the team split between your side and ours, and who would I work with most closely?"
• "What are your overlap hours, and how do you prefer to receive updates?"
• "What does a successful first month look like for someone in this role?"
• "What's the biggest challenge the project is facing right now?"