DEV Community: NeuraPath Academy

Is data science still worth it in India in 2026? An honest answer, and what I'd learn now

NeuraPath Academy — Sat, 17 Oct 2026 10:31:49 +0000

AI writes the code now, fresher hiring is flat and the pay numbers online disagree by a factor of two. Here is what the data says this month, and the order I would learn things in if I were starting today.

I first published this on Medium. Cross-posting here because a lot of the people asking me whether data science is still worth it are on DEV.

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

Yes, data science is still worth it in India in 2026. But it is worth it for a narrower group of people than the advertisements suggest, and the entry door has moved.

Here is the short version. Demand for AI and machine learning work in India is growing faster than most categories on the job portals. Hiring of freshers in general is flat. Employers are paying for people who can take a model from a notebook to something a business uses, and they are paying much less for people who can only train one. Many freshers will not start with the title "Data Scientist". They start as analysts or as junior data scientists at five to seven lakh a year, and the steep part of the pay curve comes after two or three years of real work.

If that sounds acceptable to you, read on. I will show you the numbers I read this week, my view on AI and the job, and the order I would learn things in.

What does the hiring data say right now?

The most current Indian number I trust is Naukri's monthly JobSpeak index, because it counts actual postings on Naukri, one of India's largest job portals. The September 2026 edition, published on 6 October, reported that "AI/ML roles continued to record growth, rising 20% YOY in September" (Naukri JobSpeak). That is year on year, against September 2025, and it is a count of postings, not of people hired.

The same report has the number freshers should read twice. Fresher hiring across all sectors was "+1% YOY", while demand for people with 8 to 12 years of experience grew 5% and for 13 to 16 years grew 7%. Hitesh Oberoi, the CEO of Info Edge, summed it up: "September's numbers reflect a hiring market that remains steady, but more selective." He added that demand "continued to move towards specialised skills, particularly AI, and more experienced professionals."

Put those two facts side by side. AI work is growing. Entry-level hiring is not. The field is healthy, and the first rung of the ladder is crowded.

Two global sources point the same way, with caveats you should know. The World Economic Forum's Future of Jobs Report 2025 is built on a survey of employers, and they placed "Big Data Specialist" and "AI and Machine Learning Specialists" at the top of their fastest growing roles to 2030 (WEF, Future of Jobs 2025). That is what employers expect, not a count of jobs. The US Bureau of Labor Statistics projects that "Employment of data scientists is projected to grow 35 percent from 2025 to 2035" (BLS Occupational Outlook, page updated 27 August 2026). That is a US projection. I quote it because it is careful and official, not because it describes Indian hiring.

Will AI replace data scientists?

No. It will replace a large part of what junior data scientists used to be paid to do, and that difference matters for how you prepare.

Look at how programmers already work. In the 2025 Stack Overflow Developer Survey, "84% of respondents are using or planning to use AI tools in their development process." In the same survey, "More developers actively distrust the accuracy of AI tools (46%) than trust it (33%)," and the biggest single frustration, cited by 66%, was "AI solutions that are almost right, but not quite" (Stack Overflow 2025). That survey is of developers, not data scientists, but anyone who writes pandas code for a living will recognise the pattern.

"Almost right" is the whole story for our field. An assistant will write a cleaning script, a train-test split and a gradient boosting model in a minute. It will also leak tomorrow's data into today's features, pick accuracy as the metric on a dataset where 2% of rows are fraud, and present the result with total confidence. The code runs. The answer is wrong.

So the work that is shrinking is the typing. The work that is growing is the judgement: is this the right question, is this the right metric, did the data leak, would I sign my name under this number? I have spent ten years in data science, much of it on production systems in regulated pharma and clinical settings. In that world a model output nobody can explain does not ship, however good the accuracy looks. That habit used to be a specialist's habit. With AI writing the first draft of everything, it is now the core skill.

My position, then, is simple. If your plan was to become the person who writes routine models on request, AI has made that plan weaker. If your plan is to become the person who can tell whether a model is right and get it used, AI has made you more productive and more valuable.

What do freshers actually earn?

Ignore any single number you see in a headline. Pay for data roles in India varies hugely by title, experience, company type and city, and the figures online mix all of them together.

I read the public salary pages on AmbitionBox and PayScale on 17 October 2026 and put the experience-wise averages on one chart.

Reported annual pay by title and experience. Source: AmbitionBox experience-wise averages, updated 14 to 16 October 2026, and PayScale India, updated 9 July 2026, both read 17 October 2026.

A few things jump out.

The title changes everything. On AmbitionBox, a Junior Data Scientist with 0 to 1 year of experience reports ₹4.6 to 6.3 lakh a year. That band rests on only 52 salaries, so treat it as a rough signal. The 1 to 3 year band for the same junior title is ₹5.9 to 6.8 lakh. But someone holding the plain Data Scientist title with 1 to 3 years reports ₹11.3 to 12.5 lakh, from about 24,000 salaries. That gap is mostly about who gets the title, not about the same person being paid double.

PayScale lands close to the junior figures. Its India page says an entry-level data scientist with under a year of experience earns an average total compensation of ₹5,95,255, based on 307 salaries (PayScale India).

Data analysts start lower and rise more slowly. AmbitionBox shows ₹5.2 to 5.7 lakh at 1 to 3 years and ₹7.2 to 7.9 lakh at 3 to 6 years. Data scientists with 3 to 6 years report ₹15 to 16.6 lakh, and 6 to 9 years ₹20.5 to 22.6 lakh.

Now the part almost every fresher gets wrong: fixed pay versus CTC. In India, cost to company usually bundles your fixed salary with variable pay, the employer's provident fund share, gratuity and sometimes a one-time joining bonus. What reaches your bank account each month is noticeably less than CTC divided by twelve. PayScale separates base salary from total pay on its page. AmbitionBox does not label its averages as fixed or CTC, and shows monthly in-hand pay separately. So when two people compare "packages", ask which number they mean before you feel bad.

One more caution. These are self-reported averages from people who already hold the job. They tell you what the market pays, not what you will be offered.

Should you start with data science or data analytics?

For most freshers and career switchers, I would start with analytics. I don't say that because analytics is easier or a consolation prize. I say it because data science is built on top of it.

Look at what a data scientist does in a normal week. Pulling and joining data in SQL. Checking whether the numbers make sense. Explaining a result to someone who controls a budget. Building a model is often a smaller part of the week than people expect. An analyst role trains all of that, gets you paid while you learn it, and gives you real business data to practise on.

We built our own Data Science programme on this logic. The syllabus on our course page opens with a condensed Data Analytics Core of 40 live hours, covering Excel, SQL, Power BI, Python, EDA and statistics, before any machine learning. The page states the reason plainly: "Data science sits on top of the analyst stack; skipping the foundation is the single most common reason people stall." The same page tells anyone with no data experience at all that we would "honestly recommend beginning with analytics first."

If you already work with data, as an analyst, in finance, in operations, in a lab, then go straight at data science. You have the foundation and the domain, and the domain is worth more than most people realise.

What would I learn now, and in what order?

Here is the order I would follow if I were starting again today. It is my opinion, built from what I see employers ask for and from what I watch learners struggle with.

My recommended learning order, with what to postpone. An opinion, not survey data.

1. SQL, spreadsheets and one BI tool. Joins, group-bys and window functions, until you can answer a business question from raw tables without help. Then build one dashboard that a real person uses for a month. This is the skill you will use every single day.

2. Statistics and Python for analysis. Distributions, sampling, hypothesis tests, confidence intervals, and pandas until it is boring. Do honest exploratory analysis: what is missing, what is odd, what would change the answer. AI tools will write the pandas for you. They will not tell you that the "spike" in March is a duplicated file.

3. Classical machine learning, done properly. Linear and logistic regression, decision trees, random forests and gradient boosting. Spend more time on validation than on algorithms: cross-validation, leakage, class imbalance, choosing a metric the business cares about. Most real tabular problems in Indian companies are still solved here.

4. Ship one model. Wrap a model in a small API with FastAPI or a simple app with Streamlit, put it in Docker, and add basic logging so you can see when its inputs drift. Our own syllabus gives this its own module, Model Deployment, with Flask/FastAPI services, Streamlit apps, a Docker introduction and monitoring basics. One shipped model teaches you more than five notebooks.

5. GenAI for data work. Learn embeddings, build a small retrieval system over documents you understand, and above all learn to check LLM output. Make a test set of fifty questions, score the answers, and write down the failures. This is where "almost right" bites hardest.

6. One domain, properly. Pick banking, retail, pharma, logistics or whatever you know, and learn its metrics, its data and its rules. A data scientist who understands how a loan book or a clinical trial works is worth far more than one who knows a fifth algorithm.

What I would postpone

Deep learning theory from first principles can wait until you have a problem that needs it. Kaggle leaderboard chasing teaches tricks that rarely matter at work. Learning R and Python together splits your attention in the first year; pick Python. And skip the big-data tooling until a job puts terabytes in front of you.

I would also skip collecting certificates. Hiring managers have seen hundreds of them. What they rarely see is a candidate who can show a deployed model, the test set behind it and a short note on where it fails.

What makes a fresher's portfolio believable in 2026?

Because AI can produce a tidy notebook in minutes, a tidy notebook proves very little now. Here is what I would want to see on a CV.

A project on messy, real data that you cleaned yourself, with a short write-up of what was wrong with it. A model that runs somewhere other than your laptop, with a link. An evaluation section that reports where the model fails as well as its best score. And one piece of writing, a blog post or a README, that a non-technical manager could follow.

If you can only do one, do the deployed model with the honest evaluation. It answers the two questions every interviewer is really asking: can you finish things, and can you be trusted with a number?

Who this is not for

Data science is a poor fit if you want a quick, certain salary jump in six months. The numbers above show that the large jumps come after two or three years of real work, and the first job may pay less than you hoped.

It is also a poor fit if you dislike ambiguity. Much of the job is working out what the question should be, finding that the data cannot answer it, and saying so to someone senior.

And if you enjoy building software more than questioning numbers, look hard at software or ML engineering instead. Those are excellent careers, and many people discover too late that they liked the coding part of data science much more than the statistics part.

What to do this week

Write ten SQL queries against a public dataset, including at least two with window functions. If that feels hard, you have found your starting point.
Open three real data job postings in your city, one analyst, one junior data scientist, one data scientist, and list what each asks for that you cannot yet show.
Pick one project you could deploy in a month, and write down how you will measure whether it is wrong.
Check what your current skills are likely to pay before you spend money on anything.

For that last step we built a free data science salary calculator. You choose a role, experience band, city and the skills you already have, and it shows a directional range and how much each skill moves it. It is a rule-of-thumb model, not a survey, so read it next to the chart above. Its Data Scientist setting prices the full title, so if you are a fresher, run it for Data Analyst as well and compare. The most useful thing it shows is which skills move the number, which is a good way to decide what to learn next. If you want a personal roadmap, there is an optional form for a short call with our counsellors.

A question for the comments: if you work in data in India, what did your first role actually ask of you in month one: SQL and reporting, or modelling? I suspect SQL wins for most people, and I would like to know if I'm wrong.

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 data science and forward deployed engineering programmes at NeuraPath Academy in Noida.

How to practise for a forward deployed engineer interview when nobody can mock-interview you

NeuraPath Academy — Sat, 17 Oct 2026 10:31:47 +0000

What Palantir and OpenAI say they look for, what each round of an FDE loop is really checking, and a drill for every round that you can run on your own.

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

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

A forward deployed engineer interview usually mixes five or six kinds of round: a phone screen with a coding question, an open-ended "decomposition" problem, a take-home you later defend, some work inside code you did not write, a customer scenario, and questions about why you want the job. Every one of them can be practised alone. You need a voice recorder, a timer, a few real job posts and the discipline to score yourself honestly.

That last part is where most preparation falls apart. People read question lists and walk in having never said an answer out loud.

What does an FDE interview actually look like?

There is no single FDE loop. So I went to the companies' own words first, then to one candidate account, and read all of it on 17 October 2026.

Palantir, where the role started, is the most open about its process. Its careers site has a set of "Getting Hired" pages. The one on the phone interview says the process "begins with one or two phone interviews, typically lasting 20 to 45 minutes each", and that for engineering roles "you'll also be asked a technical question that focuses on your coding abilities." It adds a line I wish every candidate read twice: "it's good to come up with a simple solution first and then go from there."

Palantir also publishes a page on navigating open-ended questions, which is the round prep sites call "decomposition", and another on working inside existing systems. Both are excellent free advice for this role.

OpenAI does not publish an FDE interview guide that I could read today, but its FDE job post tells you what the interview will be hunting for. The role will "own discovery, technical scoping, system design, build, and production rollout", and the post asks for people who "make trade-offs between scope, speed, and quality" and who "model calm and judgment when the stakes are high." Read those as interview rounds and they map almost one to one.

For the take-home, the clearest account I found is an anonymous candidate write-up on the prep site Aced (formerly Exponent). The candidate describes "a one-week take home, a live team discussion of that case study, and a separate AI-enabled coding screen that was basically an easy LeetCode problem." One account is one account, but it matches the job post, and the candidate's summary of what mattered is useful: the evaluation "seemed to come down to whether I could explain my decisions clearly and tie them back to customer needs."

Six common kinds of round, what each one checks, and a drill you can do without a partner. Loops differ; ask your recruiter which are in yours.

I could not find an official page from any of these companies describing a role-play round with an angry client. Prep sites describe one and the job posts clearly test for it, so I include it, but no published rubric sits behind it.

What is the coding screen really checking?

Mostly two things: that you can get to working code, and that someone listening can follow how you got there.

Palantir's phone interview page says it plainly: "Since we can't see you, the only way we can understand your thought process is to hear you talk." The OpenAI candidate called their coding round easy, then added that "they still wanted me to speak to time complexity and memory."

So the drill is about speaking. Pick two easy array, string or hashmap problems a day. Start a voice recording, say what the problem is, say the plain solution, write it, then say its time and memory cost. Play one recording back each day. You will hear ninety-second silences, and that silence is what an interviewer on a call experiences.

Keep the problems easy. Failing the coding round ends things early, but nothing I read suggests FDE loops reward exotic algorithms.

How do you practise the decomposition round with nobody across the table?

This is the round that makes FDE interviews different, so it gets the most space here.

Palantir describes it as handling problems "with multiple possible solutions that will incur different trade-offs", and gives its own advice for the interview: "articulate the alternatives and trade-offs, but don't forget to be pragmatic enough to be able to arrive at some concrete approach. Deliver a functioning idea first, then expand it afterwards."

Two failure modes sit inside that sentence: listing alternatives forever, and committing in the first minute to a design for a problem nobody has explained yet.

You do not need anyone to give you prompts. Palantir's own job posts contain them. Its new-grad FDE posting mentions problems such as "How can we analyze and adapt a global supply chain to deliver critical parts on time?" That is a perfect practice prompt: one line, no data, no scope.

Here is roughly how I would want a strong answer to that prompt to be shaped. Not the content, which depends on the client, but the order.

First, restate it in business terms. "Some parts arrive late, and when a critical one is late, a line stops or a customer waits. You want to see that risk early enough to act."

Then ask the questions that change the design. What makes a part critical, and who decides? Late against which date: the supplier's promised date, or the date the factory actually needs it? How do people find out about a late part today, and how many days before it bites? What data exists: purchase orders, supplier confirmations, shipment tracking, and how fresh is each? And the most important one: when a part is flagged, what can anyone actually do? Expedite it, switch supplier, move stock from another plant? The available actions decide what you build.

Then define success out loud, in terms the client can check. Something like: how many of the late critical parts did we flag, how many days ahead, and how often did a flag lead to an action. You agree the numbers with the client. You do not invent them in the interview.

Then cut a first version small enough to ship. One plant, the parts the planners already call critical, a daily refresh, and a ranked list that shows each part's risk and the reason for it. No machine learning until a simple rule (expected arrival later than needed-by date) has been measured.

Then sketch the whole path before going deep anywhere. Pull orders, confirmations and shipment events; join them on part and order; compute expected arrival against need date; rank; show it to one planner; log what they did.

Then name the trade-offs and the risks. Rules first versus a model first. Daily batch versus near real time. And the risk I would bet on: the same part carrying different numbers in different plants' systems, which quietly breaks every join.

Nothing in that answer requires knowing Palantir's software. It requires asking before building and committing before the clock runs out.

The drill I would use: reverse a finished spec

Here is the first-hand part, and it comes from our own classroom rather than an interview.

At the end of a live Python class on 12 September, our FDE fresher cohort got a brief called "Car Manufacturing & Delivery System". It was a coding exercise in classes, loops and dictionaries, and it was fully specified. Delivery cost had a base charge of ₹2,000, then ₹10 a kilometre for the first 500 km, ₹8 a kilometre from 500 to 1,000, and ₹6 beyond that. A hybrid car priced over ₹15 lakh was HIGH priority. There was a menu with eight options, a report format, and an extra challenge: let a customer place an order, and check whether enough cars are available before allocating them.

Read that brief as a forward deployed engineer and something jumps out. Every one of those rules is an answer to a question somebody had to ask. No dealership manager walks in with a distance slab table. Somebody sat with them and asked how delivery is charged today, whether long routes get cheaper per kilometre, which cars jump the queue and why.

So here is the drill. Take any fully specified exercise you have done, from a course, a college project or a hackathon. Cover everything except the one-line scenario. For our brief, that line was: "The company manufactures different cars and delivers them to dealerships across different cities." Give yourself fifteen minutes to write the questions you would ask the client. Then uncover the spec and tick off every rule your questions would have surfaced.

The rules you missed are your blind spots. I would expect pricing and priority rules to be among them, because those live in someone's head rather than in a system. The extra challenge hides the best question of all: what happens when two dealers order the last car of a model on the same day? That is a business decision, not a coding one, and an FDE has to notice it before writing the if.

How to score yourself

Record every decomposition attempt and play it back against six boxes. Did I restate the problem? Did I ask at least three questions before proposing anything? Did I say what success means? Did I cut a first version? Did I sketch end to end before going deep? Did I name a trade-off and a risk? Write the time of your first question as well. If the first two minutes are all solution, you know what to fix.

What happens in the take-home, and how should you rehearse it?

The OpenAI candidate's line is the one to remember: "the take home was basically the job." They built "a semantic search setup over Amazon products for ChatGPT", then walked the team through it.

The walkthrough is half the round, and it is the half people skip in practice. Pick a weekend project close to the work: search over a public product catalogue, a small assistant over a set of public documents, a pipeline that cleans an awkward public dataset. Build it in a fixed time, write a README a stranger could follow, and then present it to your phone camera in ten minutes. End with three things you would change if a customer asked for more precision, more speed or lower cost.

One caution about AI tools. Anthropic publishes guidance for candidates (last updated 10 July 2025). For take-home assessments it says: "Complete these without Claude unless we indicate otherwise." For live interviews, it allows "no AI assistance unless we indicate otherwise." The same page encourages using Claude to "practice your answers" while preparing. Other companies differ, and some allow AI in a coding screen, as the OpenAI candidate described. Ask every time, and practise both ways.

Why do FDE loops care about code you didn't write?

Because that is most of the job. Palantir's page on working inside existing systems says that "there are always third-party components in the mix", and that a developer "will spend far more time debugging, modifying, and extending existing code than writing brand-new things from the ground up."

The same page gives practice advice I have not seen bettered. Swap projects with a friend and see whether you can understand theirs without reading every line. Pick an open-source project, find a small bug in its issue tracker, and notice how long it takes to find the right place to fix it. And after you debug anything, ask yourself whether "there was a better way you could have found the bug."

That last question is the drill. Each time you fix something, log the symptom, your first wrong guess, what finally located the cause, and how long it took. After a month you know how you personally get stuck, and you have stories for two rounds.

How do you rehearse a difficult customer on your own?

Write ten short client prompts on cards. A few examples: "Your dashboard showed wrong numbers in front of my director." "We need this live by Friday, not in three weeks." "Our security team will not allow data to leave our network." "Can you also add a chatbot while you're at it?"

Draw one, start a voice memo, and answer as if the client is on the call. Then stop and write the follow-up email within ten minutes. Play the memo back and check three things. Did you ask what actually happened before explaining? Did you promise anything you could not personally deliver? Did you end with a specific next step and a time?

The OpenAI post asks for people who "spot risks early and adjust without slowing down" and who stay calm when the stakes are high. Calm is easy to claim and hard to fake on a recording. The memo will tell you the truth.

If you want a live opponent, an AI assistant can play the client during practice, and Anthropic's guidance explicitly allows practising answers that way. Just tell it to be difficult and to interrupt, or it will be far too polite.

What about the "why this role" questions?

Write five one-page stories about work someone else actually used; a college project counts. Note what you did, what went wrong and what you changed. Then replace every "we" that was really "I". A team story with no individual in it tells an interviewer nothing about you.

A four-week plan you can run alone

About seven to nine hours a week, spread across six drills. A suggestion to adapt to your own loop.

Decomposition gets steady time every week because it improves slowly and people under-practise it. Coding tapers after week one. The take-home sits in the middle so you have something to present in week four.

Who this is not for

If your interview is in three days, skip the plan. Do two decomposition prompts out loud tonight, one customer memo tomorrow, and rest the day before.

If you have never written a program that someone else used, the interview is not your bottleneck yet. Build one small thing for a real user first, and come back to this when you have a story to tell about it.

And if you are aiming for an AI lab role that asks for five or more years of engineering or deployment experience including customer-facing work, as the OpenAI post does, no amount of interview practice replaces that experience. Practise anyway, but apply to roles that match where you are.

What to do this week

Ask your recruiter, or a friend at the company, which rounds are in the loop and how long each runs. Most will tell you.
Do the reverse-the-spec drill once on a project you have already finished.
Answer the supply chain prompt above out loud in 45 minutes, record it, and score it on the six boxes.
Record two customer memos and write both follow-up emails.
Pick three real FDE postings and underline the phrases that describe a round. "Own discovery" is a decomposition round. "Calm when the stakes are high" is a customer round.

For that last step, we keep a free list of FDE and related openings in India at neurapath.in/forward-deployed-engineer/jobs, pulled from employers' own careers pages and refreshed every few hours. On 17 October 2026 it listed 137 open roles at 83 companies, a fraction of all postings. You can filter by city, experience and skill, and if you leave your email you get today's roles straight away and then one email a week with only the new ones.

A question for the comments: which round in your FDE or solutions loop surprised you most, and what would you practise differently? I am especially curious whether anyone met a live customer role-play, because I could not find a company that documents one.

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.

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.

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.