DEV Community: NeuraPath Academy

From client site to FDE: a practical guide for engineers in Indian IT services

NeuraPath Academy — Mon, 12 Oct 2026 18:16:28 +0000

You already do half of a Forward Deployed Engineer's job. Here is how to describe it, how to close the AI gap in 90 days, and how to get picked, internally or outside.

I first published this on Medium. Cross-posting here because a lot of the people asking me about this role are on DEV.

By Pankit Kumar, Senior Data Scientist and Lead Instructor at NeuraPath Academy

If you've ever sat in a client's office at 11 at night because a batch job failed and the business head wants to know why the morning report is empty, you know a particular kind of pressure. The runbook doesn't cover what broke. The person who built the integration left two years ago. The client's firewall team won't open a port until a ticket is approved, and the approver is on leave. You find a workaround, explain it to someone who only wants a time estimate, and by 2 a.m. the report is back.

Then you update a tracker that calls all of it "Resolved P1 incident."

I have spent ten years building production systems in regulated pharma and clinical settings, and now I teach people moving into Forward Deployed Engineering. The engineers in Indian IT services who come to me usually have more real-world deployment experience than the product engineers they compete with. What they lack is the language to describe it, a modern AI layer on top of it, and proof that anyone outside their account can see.

This piece is for services engineers with two to eight years behind them. My earlier piece explained what an FDE is; this one is about making the move.

Why your background is closer than you think

Palantir, which coined the role, explains the difference in its post Dev versus Delta. A product engineer builds "one capability, many customers." A forward deployed engineer, a Delta in their vocabulary, works on "one customer, many capabilities."

Think about your last account. One client: their SAP, their legacy Oracle, their half-finished cloud migration, their security reviews. You touched all of it because the client needed it to work.

Akshay Kokane, who moved from a backend role at Microsoft to an FDE role at Salesforce, writes that after the recruiter call he googled "what is an FDE" and realised he had been doing the job unofficially. I hear a version of that from most services engineers I counsel.

The demand side is real too. Salesforce describes its FDEs working in pods, and Sarah Khalid put the business reason plainly in their post on the role: "Without FDEs, we risk having thousands of customers stuck in pilot purgatory," meaning signed up but never successfully deployed. If you have ever watched a client buy a platform and then never use it, you have seen pilot purgatory.

Translate your work into FDE language

The problem is vocabulary. Services résumés are written for services recruiters, and they use words that sound like process compliance to an FDE hiring manager. Here is the translation I use with learners.

What you call it in services	What an FDE hiring manager hears
Onsite coordination	Customer discovery: sitting with users and finding the real requirement behind the stated one
Production support, P1 calls	Owning production: diagnosing failures in an environment you don't control
Change requests	Iterating with a client: shipping, getting feedback, shipping again
KT sessions	Handover and enablement: making the client's team self-sufficient
UAT	Acceptance with the customer: agreeing what "done" means and proving it
Requirement gathering	Scoping: turning a vague business problem into something buildable
Status calls with client managers	Stakeholder communication: explaining technical risk to non-technical people
Environment and access issues	Working inside real constraints: firewalls, approvals, data residency

None of this is spin. The right-hand column describes what you achieved instead of the ticket category it was filed under.

Rewrite your résumé bullets

Most services résumés describe tasks. FDE résumés describe outcomes for a specific customer. These are illustrative examples, so don't copy them; use them as a pattern for your own facts.

Before: Handled production support for a banking client's loan processing application.

After: Owned production for a loan-processing system used by a retail bank's branch staff; cut repeat P1 incidents by tracing three recurring failures to a single upstream data feed and fixing the validation.

Before: Worked on change requests as per client requirements.

After: Shipped twelve change requests over six months for an insurance client's claims team, sitting with two adjusters weekly to reprioritise based on what was slowing them down.

Before: Conducted KT sessions for the client team.

After: Wrote the runbook and ran handover for a reporting pipeline so the client's internal team could operate it alone; support tickets to our team dropped to near zero within a quarter.

Before: Participated in UAT and defect fixing.

After: Defined acceptance criteria with the client's finance lead for a reconciliation tool, then fixed the gaps that UAT exposed before go-live.

Two rules matter more than the wording. Every number must be true and defensible in an interview, because a good interviewer will pull on it. And keep confidential client names out unless your employer allows it; "a large Indian private bank" works fine.

The gap, stated honestly

Services experience gets you halfway. Three things usually stand between you and an FDE offer.

The first is the modern AI layer. Look at what employers are asking for. On our FDE jobs board, as of 12 October 2026 we had 138 open roles at 84 companies, pulled from employers' own careers pages, which is a fraction of all postings. AI agents came up in 55 of them, LLMs in 31 and RAG in 30, next to the older staples: AWS in 38, Python in 36, APIs in 35, Azure in 33. If you have never called an LLM API, built a retrieval pipeline or written an evaluation for one, that is your biggest hole.

The second is end-to-end ownership. Large services accounts slice work: one person does the ETL, another the API, a third the deployment, and a manager talks to the client. FDE roles expect one person to carry a problem from first conversation to production. If you have only owned a slice, you need one project where you owned everything.

The third is public proof. Everything you have built sits behind a client NDA, so a hiring manager cannot see it. Het Trivedi got his FDE role at an AI startup after a co-founder read his blog post about deploying a model. One honest write-up can do more than a polished résumé.

Experience requirements are less scary than people assume. Of the 43 postings on our board that stated a minimum, 2 asked for a year or less, 15 asked for 2 to 3 years, 13 for 4 to 6, and 13 for 7 or more. The median was five years. A services engineer with three to six years is squarely in range.

A 90-day plan at 8 to 10 hours a week

This assumes a full-time job and roughly an hour a day on weekdays plus a longer weekend block. Each stage ends with something you can show.

Weeks 1 to 2: get comfortable with LLM APIs. Pick one provider, write a small Python script that takes a messy input from your domain (a support ticket, an invoice description, a log line) and returns structured JSON. Handle the failures: bad JSON, timeouts, rate limits. Deliverable: a GitHub repo with the script, a README and ten test inputs.

Weeks 3 to 5: build retrieval over real-looking documents. Write or generate a set of synthetic documents that resemble something you know, such as an internal SOP, a policy manual or a product FAQ. Build a RAG pipeline that answers questions with citations to the source passage. Deliverable: a working app plus a short note on where it gives wrong answers and why.

Weeks 6 to 7: add evaluations. This is the step most people skip and most hiring managers ask about. Create 30 to 50 question-answer pairs, score your system against them, change one thing (chunk size, prompt, retrieval count) and measure again. Deliverable: a results table showing before and after, including the changes that made things worse.

Weeks 8 to 10: turn it into an agent that does something. Give the system one or two tools, such as creating a ticket or querying a small database, with guardrails on what it is allowed to do. Log every step. Deliverable: a recorded five-minute demo where you walk through a request, the tool calls and one failure case.

Weeks 11 to 12: deploy it and write it up. Put it somewhere a stranger can use it, even a free tier. Then write a post the way you would write a client post-mortem: the problem, what you tried, what broke, what you measured, what you would do next. Deliverable: a public URL and a published article.

Week 13: package and apply. Rewrite your résumé with the translated bullets, link the project, and start conversations. Deliverable: an updated résumé and ten tailored applications or internal conversations.

If you fall behind, cut scope, never the evaluation or the write-up.

The internal route

Something unusual is happening in Indian services right now: the large firms are building FDE teams from within. Moneycontrol reported on 21 July 2026 that TCS plans to move 1 to 1.5 per cent of its workforce into FDE roles, HCLTech is training selected freshers as FDEs, LTM's AI1000 programme aims to build 1,000 FDEs and Coforge is targeting more than 100.

So you may not need to leave. But internal selection rarely runs through an application form. People get picked because someone senior already links their name with AI work that went well in front of a client. Create those moments.

Volunteer for the AI pilot on your account. Every large account has one now, usually under-staffed and slightly chaotic. Being the person who made it work is worth more than any certificate.

Own the client demo. Offer to prepare and run it. Demos are where delivery leaders see who can explain a system to a business audience, and that is a core FDE skill.

Write the internal post-mortem. When a pilot struggles, most people go quiet. The person who writes a clear account of what happened and what should change becomes visible to exactly the people who staff new teams.

Then tell your manager and practice head directly that you want FDE work. Quiet competence just gets you renewed on the same account.

The external route

Outside your firm, three kinds of employer hire FDEs: AI startups, product companies selling into enterprises, and global capability centres building AI internally. Startups move fastest and weigh public proof most heavily. Product companies want a credible engineering record plus evidence you can handle a customer. GCCs often value services backgrounds directly, because their internal customers behave much like your clients.

One staffing firm's bands, TeamLease Digital's as quoted in the same Moneycontrol piece, put entry FDE roles at ₹18 to 25 lakh, mid-level at ₹30 to 45 lakh and senior at ₹50 to 85 lakh. Treat those as one firm's view of the market, not a promise. Many roles carrying the title are closer to solutions engineering.

What the interviews tend to probe

I won't claim to know any company's process, but FDE-style interviews tend to test three things beyond coding.

The first is a scoping conversation. You get a vague problem, something like "our support team is drowning, can AI help?", and the interviewer watches whether you ask about users, data, constraints and how success will be measured before proposing a solution. Services engineers are often good at this, then undersell it by jumping to architecture.

The second is debugging, frequently in an unfamiliar codebase or a system described verbally. They want to see how you narrow a problem down, not whether you know the answer.

The third is explaining a trade-off to a non-technical person. Why the cheaper option is riskier, why you need two more weeks, why the model can't be 100 per cent accurate. You have done this on status calls for years. Practise doing it in under two minutes.

You will almost certainly hear some version of "tell me about a time a client's environment broke your plan." Here is how I would shape an answer from typical services material, using the STAR structure.

Situation: "I was the onsite engineer for a data migration at a manufacturing client. We'd planned a weekend cutover moving three years of orders to a new cloud warehouse."

Task: "I owned the load scripts and the validation, and I had to sign off that the numbers matched before the business went live on Monday."

Action: "On Saturday afternoon we discovered the client's network policy throttled outbound transfers far below what we'd tested in the lower environment. The plan assumed eight hours; at that rate it would take three days. I split the load by month, prioritised the last ninety days because that was all the business needed on Monday, and moved the history to a staggered load across the week. Then I called the client's operations head, explained in plain terms what they would and wouldn't see on Monday, and got written agreement."

Result: "Go-live happened on schedule with current data. The history finished by Thursday. I added a network throughput check to our pre-cutover checklist, and the account used it on the next two migrations."

That answer shows a constraint you didn't control, a decision under pressure, a plain-language stakeholder conversation and a lasting fix. You almost certainly have stories like it. Write them down.

The honest risks

Travel can be heavy. Many FDE roles expect real time at customer sites, sometimes abroad. If you left onsite work deliberately, think hard before going back.

Ambiguity is the job. If you enjoy well-defined work with clear boundaries, you may find FDE work exhausting. Het Trivedi called it "like being a firefighter crossed with a plumber and a translator." Some people love that. Some people burn out.

Success is often tied to adoption. Your system can be technically excellent and still count as a failure if the client's team doesn't use it. Some performance reviews will reflect that.

So who should stay put? If you are on a strong product or platform team inside your firm and you enjoy deep technical work, there is nothing wrong with becoming excellent at that. If you dislike client conversations, FDE roles will put you in more of them, not fewer. And if you are switching only because of the salary headlines, the first difficult customer will test that motive quickly.

What to do this week

Take your last two years of work and run it through the translation table. Write down three stories where a client's environment forced you to change a plan, with real numbers you can defend.

Rewrite your top five résumé bullets using the before-and-after pattern above.

Find out whether your account or practice has an AI pilot, and ask the person running it how you can help. Do this in person or on a call, not by email.

Block your calendar for weeks 1 and 2 of the plan, and write the first script this weekend.

If you want a running list of open FDE roles and our notes on preparing for them, both are free at neurapath.in/forward-deployed-engineer.

Over to you: if you have made the move from a services account into an FDE or solutions role, what was the one thing that got you the interview? I'll add the useful answers to the next edition of this guide.

Pankit Kumar is a Senior Data Scientist at Parexel with ten years in data science and AI, much of it building production systems in regulated pharma and clinical settings. He leads the forward deployed engineering programmes at NeuraPath Academy in Noida.

The FDE title is booming in India. Here's who it's actually for

NeuraPath Academy — Mon, 12 Oct 2026 18:16:09 +0000

Palantir invented the job, AI labs made it famous, and Indian IT is now trying to build thousands of them. What the work really is, what it pays, and how to show you can do it.

I first published this on Medium. Cross-posting here because a lot of the people asking me about this role are on DEV.

By Pankit Kumar, Senior Data Scientist and Lead Instructor at NeuraPath Academy

In September I watched a room of beginners write a Python program that worked perfectly and would have failed on every machine except the one it was written on.

It was a live class. We were logging events from a small simulation. The notebook wrote its own log file by hand. In five lines it managed three bugs, and it saved the file to a path that began with C:\Users\ followed by one person's username. It ran. On that laptop, on that day, it was correct.

We spent the next two classes undoing it: turning a notebook into a package, replacing the hand-rolled log file with Python's logging module, adding tests that could run on anyone's machine. Nobody enjoyed it as much as building the simulation. But that gap, between code that works for you and code that works for someone else, is the whole job of a forward deployed engineer. They spend their working life on the other side of that gap, inside a client's systems, where your laptop's assumptions are all wrong.

The title is everywhere in India right now. I want to explain what it actually means, who is really being hired, and what you can do about it if you want in. I'll use numbers where I have them and say so where I don't.

Where the job came from

The forward deployed engineer started at Palantir. Internally they were called "Deltas", and for years Palantir employed more of them than product engineers. A 2019 Palantir post put the difference in one line that is still the best definition I know: product engineers build "one capability, many customers"; Deltas deliver "one customer, many capabilities" (Palantir, Dev versus Delta).

That one-customer focus is the point. An FDE sits with a single client, learns how their data, systems and politics actually work, and then writes software that runs in that environment. Not a slide deck. Running code, on the client's infrastructure, used by the client's people.

The same Palantir post is careful to separate this from consulting. Consultants, one of their engineers said, "generally create a one-time analysis, recommendation, or solution to a specific problem." An FDE ships software that stays.

Why AI made it the job everyone is talking about

For a decade the role was a Palantir oddity. Then large language models arrived, and every software company discovered the same problem at once: a demo that impresses in a meeting falls apart on a real customer's data.

The model is fine. What breaks is everything around it. The customer's documents are scanned PDFs with handwriting. Their single sign-on rejects your service. Their compliance team wants to know where every prompt goes. Salesforce's FDE leadership described the alternative bluntly: without people who can do this work on site, "we risk having thousands of customers stuck in pilot purgatory" (Salesforce).

Investors noticed. Andreessen Horowitz's widely shared 2025 essay argued that AI startups should accept lower margins and embed engineers with customers, because enterprises buying AI "are like your grandma getting an iPhone": they want to use it, but they need someone to set it up (a16z, Trading Margin for Moat). OpenAI, Anthropic, Salesforce and a long list of startups now hire for the role, sometimes under different names: Applied AI Engineer, Deployment Strategist, Solutions Engineer.

If you want one image of the job, the best I have read comes from an engineer who did it at an AI startup. He described it as "like being a firefighter crossed with a plumber and a translator" (Het Trivedi). Firefighter, because something is always on fire. Plumber, because most of the work is connecting pipes nobody documented. Translator, because the client speaks in business problems and your tools speak in APIs.

India has two FDE job markets, not one

Most articles about this role are written from San Francisco, and they quietly assume one kind of employer. In India there are two, and they want very different people.

The two markets compared. Experience figures from our jobs snapshot and public postings; services-firm plans from Moneycontrol, July 2026.

The first market is AI labs and product companies. These are the roles that make headlines. OpenAI's FDE postings ask for five or more years of experience and up to 50% travel. Anthropic's India openings for this kind of work, Applied AI Architect roles in Bangalore and Mumbai, ask for ten years or more in technical customer-facing roles. These companies hire people who have already shipped production systems for demanding customers, and they pay accordingly.

The second market is IT services and global capability centres. Indian services firms have started building FDE teams, mostly from their own staff. Moneycontrol reported in July 2026 that TCS plans to move 1 to 1.5% of its workforce into the role, that HCLTech is training selected freshers as FDEs, that LTM's AI1000 programme aims to build a thousand of them, and that Coforge is targeting more than a hundred (Moneycontrol). The hiring here runs through internal programmes, project allocation and certifications, not through cold applications to a San Francisco lab.

Both are real. But if you are a fresher reading about a ₹50 lakh FDE package at an AI lab, you are reading about the first market, and the door into it is not where most people think.

What Indian postings actually ask for

Our academy runs a live board of FDE and related openings in India, pulled directly from employers' careers pages. On 12 October 2026 it held 138 open roles at 84 companies. That is a fraction of the market, because new roles go up every day, but it is enough to see a pattern.

Share of 138 open FDE and related roles in India mentioning each skill. Source: NeuraPath FDE jobs board, 12 Oct 2026.

The top requirement is not a technology. Client-facing work appears in almost half the postings, more than AI agents, more than any cloud platform, more than Python. Then come the tools you would expect: agents, AWS, Python, APIs, Azure, LLMs, retrieval.

The other number matters even more to anyone starting out.

Minimum experience stated in the 43 postings that state one. Most postings state none.

Of the postings that state a minimum, only two ask for a year or less. The median is five years. I am not showing this to discourage anyone. I am showing it because the honest answer to "can I become an FDE straight out of college?" depends on which market you mean, and pretending otherwise wastes people's time.

The salary question, without the hype

You will see two kinds of numbers in Indian coverage of this role.

The first kind is sensible. TeamLease Digital's figures, reported by Moneycontrol in July 2026, put entry-level FDE pay at roughly ₹18 to 25 lakh, mid-level at ₹30 to 45 lakh and senior at ₹50 to 85 lakh. These are bands from one staffing firm's data, and they describe people who already hold the title, but they are a reasonable starting point.

The second kind is the headline. "Seven times a fresher's salary" compares FDE entry pay with a typical ₹3 to 4 lakh starting package at a large services firm. That is not a like-for-like comparison. The people being hired as FDEs at ₹18 lakh are mostly not freshers; they are engineers with a few years of production work behind them. The multiple is real arithmetic, but it compares two different groups of people.

What I tell people who ask me about pay: look at who is being hired at that number before you look at the number. Live postings that print a range are the most honest data you will find. On our board that week, published ranges ran from around ₹14 to 30 lakh at an early-stage startup to ₹70 to 90 lakh at an AI company hiring for India. Wide, because the job is wide.

You may already be doing part of this job

Here is the part I wish more engineers in Indian IT knew. A lot of the FDE skill set is built in exactly the work that people in services companies are often a little embarrassed about.

If you have spent time on a client site, you have done the most important part. If you have kept a production system alive during a bad week, you have done the second most important part. Look at this list honestly:

Have you sat with a client and worked out what they actually needed, as opposed to what the ticket said?
Have you connected a system to data you did not design and nobody fully documented?
Have you owned something in production, been the person who got the call, and fixed it?
Have you explained a technical trade-off to someone who controls a budget?
Have you changed a delivered system because the client's process turned out to be different from the spec?

If you answered yes to three of those, you are closer than your job title suggests. One FDE who moved from a large tech company into the role wrote that he googled "what is an FDE" after the recruiter's call and realised he had been doing the job unofficially for years. What is usually missing is not experience. It is the modern AI layer (agents, retrieval, evaluation) and the ability to show the work to someone outside your company.

Freshers: what is real and what isn't

I teach freshers, so I owe them a straight answer.

What isn't real: walking out of college and into an FDE role at an AI lab. Those roles ask for years of production experience, and no course or certificate replaces that.

What is real:

Entry-level FDE roles at startups and some services firms. They exist. On our board, a handful of postings asked for one or two years, and HCLTech's fresher track shows services firms are willing to train for the role.
Adjacent first jobs that lead there. Implementation engineer, solutions engineer, technical support engineer for an AI product, applied AI engineer. Each puts you in front of customers with a technical product, which is exactly the experience the FDE postings ask for.
Proof that you can do the work. This is the part you control.

The fresher who gets shortlisted is not the one with the longest list of courses. It is the one who can show a system they built for a real user, working on someone else's machine, with a clear account of what went wrong and how they fixed it.

How to build proof that an FDE hiring manager will believe

Certificates are cheap and everyone has one. Here are three things that are harder to fake and that I would rather see on a CV.

An integration on messy data. Pick a public dataset that is genuinely awkward: inconsistent formats, missing values, a real API with rate limits. Build a small service that pulls it, cleans it and serves it through your own API, deployed somewhere with a link. Then write a short README that a stranger can follow without messaging you. Our own fresher curriculum ends its second phase with exactly this kind of project, because it is the closest thing to a first week on a client site.

An evaluation report for something you built with an LLM. Not a demo video. A table: these are the 50 questions I tested, this is how often the answer was right, these are the five failures and what I changed. Very few candidates do this. Every FDE has to, because a client will eventually ask "how do you know it works?"

A written-up incident. Something broke in a project of yours. Write it up properly: what happened, how you found it, what you fixed, what you would do differently. This shows judgement, which is what clients pay for and what interviews probe.

Then write about the work in public. The startup engineer I quoted earlier got his FDE role after a co-founder read a blog post he had written about deploying a model. That is not a fluke. Showing your work is how most people in this field get noticed.

What the work feels like, so you can decide

Before you chase the title, be honest with yourself about the job.

You will context-switch constantly. You will often be the person who says "this will take longer than you hoped" to someone senior who does not want to hear it. Your success is measured partly by whether a customer adopts the system, which is not entirely in your control. Some weeks involve travel. Some weeks you write very little code and spend your time in meetings working out what the problem actually is.

If that sounds draining, a product engineering role may suit you better, and there is nothing second-best about that. If it sounds like the kind of problem you enjoy, this is one of the most interesting jobs in software right now, and the Indian market for it is only beginning.

Where to start this week

Read three real FDE postings from Indian employers and note which skills from the chart above each one names.
Pick the one proof project from the list above that matches the job you want, and scope it to something you can finish in a month.
If you work in services, write down your answers to the five questions above. That page is the start of your FDE story.

We keep a free, updated list of FDE openings in India, along with the numbers behind the charts in this piece, at neurapath.in/forward-deployed-engineer. If you want to talk through your own route into the role, that page is also the easiest way to reach us.

A question for the comments: if you hold an FDE, solutions or implementation title in India, which of the skills in that chart did you actually use in your first month? I suspect the answer is "client-facing" for almost everyone, and I would like to know if I'm wrong.