The problem
At a service firm, most projects run through a client interview before staffing — a conversation with the US client's engineers or manager to confirm the fit, and in the large majority of cases you cannot skip it. Everyone on the project goes through some version of it, from the newest engineer to the lead, whether or not the role ever involves a US visa. Service-delivery work trains a specific way of talking about that work: narrate the full system so the client sees you know it end to end, credit the delivery team, lead with thorough context, and stay deferential to the client's side. Those are reasonable norms inside a vendor relationship. In the staffing conversation they work against you. Asked what they did on the last project, the service-trained engineer walks through the architecture in depth and frames every decision as the team's, and the US stakeholder comes away sure the system was delivered but unsure what this specific person will own on theirs. A genuinely capable engineer reads as support staff rather than someone who will drive a piece of the work.
The key insight
The client interview is not a test of whether you know the system — it is whether the US stakeholder can picture you owning a slice of their project without being managed through it. That reframes what to say. Shrink the architecture tour to a sentence or two of context, then name the decisions that were actually yours and what changed because of them. The client does not need the full data flow; they need to know that when something breaks on their project at 2am, you are the kind of engineer who diagnoses it and moves. Deference reads as uncertainty to a US interviewer, so trade it for a peer's directness — you are there to solve their problem, not to be granted the work. The habits are trainable once you can see them; what makes them stubborn is that they are professional in the world the engineer was trained in.
Before and after
Same engineer, same project. The weak version is a process-and-system tour where the team follows the client and nothing is owned — the service-delivery default. The strong version gives one sentence of context, two decisions that were the engineer's, a number, and a peer-level interaction with the client. That is the version that gets someone staffed on the harder work.
How Arpan helps
Arpan gives you the feedback that solo practice can't. The free Diagnostic scores your answers across Ownership Language, Quantified Impact, STAR Structure, Conciseness, Engagement, and Professional Tone — the exact dimensions US stakeholders evaluate in a client conversation — and delivers word-for-word rewrites of every answer so you can see the gap clearly. Pro turns that into a practice loop: every answer rewritten across 25 voice interviews and 5 on camera over 90 days, pattern detection that surfaces which delivery habits are costing you points, and your Cultural Readiness Score™ after every session, so you can see where the score moves.
FAQ
Is the client interview really a behavioral interview?
I'm early in my career — will the client actually interview me?
How do I talk about client work without breaching confidentiality?
Get started
Hear yourself the way a US hiring manager does.
In 5 minutes, you will hear yourself the way a US stakeholder does. Pick from five interviewers — engineering managers at Big Tech, at Mid-size Tech, at a Series B Startup, and at a Global Capability Center, plus an engineering director at a US Tech Company — then answer as many behavioral questions as the time allows. Arpan scores your answers across six dimensions, shows you exactly where each one lands, and gives you word-for-word rewrites of every answer so you can see the gap clearly. No payment, no commitment.
Start the free Diagnostic →