Forward deployed engineer interview questions, with model answers

If you have an FDE interview coming up, you have probably found lists of questions with no answers attached. A list tells you what might be asked, not what the interviewer is listening for. Our fresher syllabus ends with interview preparation, and this article is the core of what I plan to teach in it: eleven questions, what a strong answer contains, and one decomposition round written out in full so you can see the shape. If you want to know how your resume reads against FDE postings before you walk in, run the free resume check first.

How I researched this: the rounds come from our own client-simulation material and public interview threads on Reddit (labelled as anecdote), and the skills data from the 138 roles in our India FDE jobs database on 12 Oct 2026. No company's internal rubric is reproduced here, because I have not seen one.

What rounds does an FDE interview have?

Expect a technical screen, a scenario or decomposition round, a client simulation and a behavioural round, sometimes with a take-home in place of the live coding. Smaller startups often merge the scenario and client rounds into one conversation.

What do they ask in the technical round?

Mostly practical engineering on messy data and misbehaving systems. The questions you ask first count as much as the code.

1. Walk me through something you deployed. What broke after it went live?

A strong answer names one real project, gives the architecture in two sentences, then spends most of its time on the failure: what the symptom was, how you found the cause, what you changed and what you added so it would not happen again. If nothing you built has ever broken, it has probably never been used.

2. Write a query for customers whose payment failed twice within any seven days.

Before writing, ask: does a retry of the same payment count as a second failure, and which timezone are timestamps in? Then write it, and say what you assumed. A window function is the clean answer:

SELECT DISTINCT customer_id
FROM (
  SELECT customer_id,
         created_at,
         LAG(created_at) OVER (
           PARTITION BY customer_id ORDER BY created_at
         ) AS prev_failed_at
  FROM payments
  WHERE status = 'failed'
) f
WHERE created_at - prev_failed_at <= INTERVAL '7 days';

Then mention the edge you did not handle: if retries share a payment ID, you would de-duplicate on it first. Saying that unprompted is worth more than a perfect query.

3. Design a nightly sync from a client's CRM into our platform.

Cover four things without being asked: how you authenticate (and who owns the credential), how you page through a large export and respect rate limits, how you make the job safe to re-run (idempotent upserts keyed on the CRM's record ID, not inserts), and how anyone will know it failed at 3 AM. Then ask what happens to records deleted in the CRM: that is the bug that surfaces three weeks later.

4. Our RAG assistant gives confident wrong answers at one client. How would you investigate?

Separate retrieval from generation. First collect the failing questions and check whether the right passage was retrieved at all. If it was not, look at chunking, metadata and whether the client's documents differ from the ones you tested on. If it was retrieved and the answer is still wrong, look at the prompt and whether the model is allowed to answer beyond the passage. Then build a small evaluation set from their real questions so the fix is measured, not guessed.

5. How would you let an AI agent issue refunds safely?

Give the agent a narrow tool, not general API access: one refund function with a hard amount limit, an idempotency key so a retry cannot refund twice, and human approval above a threshold the client sets. Log every call with the conversation that triggered it. Test it with prompts that try to talk the agent into a larger refund. The interviewer wants to hear that you design for the agent being wrong.

6. It works on your machine but fails in the client's environment. What do you check?

Work outward in order: versions (language, libraries, OS), configuration and environment variables, file paths and permissions, network access through their proxy or firewall, and the data itself. Get the exact error and logs first, reproduce it, and change one variable at a time. Our debugging exercise post gives you a fixture to practise this on.

How do you answer the decomposition round?

Restate the problem, ask the questions that change the design, define what success means, cut a first version small enough to ship, then give the architecture, the evaluation plan, the schedule and the risks. In that order. Most weak answers jump straight to architecture.

You can practise the habit on any business process. At the end of our 12 Sep live class, the trainer set the cohort a "Car Manufacturing & Delivery System" brief: an object-oriented system modelled on a real business process. It is a coding exercise, but it trains the same muscle. Before writing a single class you have to list the actors, the states a car moves through between factory and customer, and what can go wrong at each step. That is decomposition.

7. A mid-sized Indian NBFC wants an assistant so branch staff can ask questions about its loan policies. They want it live in six weeks. Walk me through it.

Here is a full answer, as I would want a candidate to give it.

"Let me restate it: branch staff have policy questions, and the bank wants them answered correctly from its own documents within six weeks. Before designing anything I would ask a few questions. Who asks today, and who answers? If it is a phone call to head office, those calls are my test set. Which documents count, how often do they change, and how do staff know which version is current? Are some documents restricted to credit or compliance teams? Which languages do branch staff work in? Do they have single sign-on? And what does a wrong answer cost: is this a staff convenience or something a customer decision will rest on?"

"Success, for me, is measured on real questions. In week one I would collect a few hundred questions staff have actually asked, with the correct answer and clause agreed by head office. The target is a correct answer citing the clause, or a clear 'contact head office' when the documents do not cover it, with the pass mark agreed with the client."

"Version one is deliberately small: one product line's policies, read-only, answers always citing the document and clause, no customer data and nothing that touches a loan account. Approvals and anything customer-specific are out of scope, and I would say so in the first meeting."

"The architecture: ingest the PDFs with their version and effective date, split them by clause rather than by fixed length, and tag each chunk with document, version and which roles may see it. Retrieval filters by the user's role from single sign-on before ranking, then a reranker, then the model answers only from the retrieved passages and must cite them. Every question, answer and source is logged, and a thumbs-down sends the case to review."

"Evaluation runs separately for retrieval and for answers, on the week-one question set, every time we change anything. The schedule: week one, discovery and the test set; week two, ingestion and a retrieval baseline; week three, answering and the first evaluation; week four, a pilot in two or three branches; week five, fixes driven by pilot transcripts; week six, a go or no-go decision on wider rollout with the numbers in front of the client."

"The biggest risk is not the model. It is superseded circulars: if an old version is still in the index, the assistant will quote it confidently. So version control of the documents, and a named owner at the bank who retires old ones, is part of the deliverable. After the call I would send a one-page summary of scope, out-of-scope, open questions and the week-one asks."

Notice what that answer never does. It never names a vector database before it knows the constraints, and it never promises an accuracy figure. I would mark both as warning signs.

What happens in the client simulation round?

The interviewer plays a client who is unhappy, rushed or asking for something unrealistic. You are scored on whether you stay honest, find the real problem and leave with a written next step, not on whether you make them happy.

8. "Your system gave my team wrong numbers. Switch it off before tomorrow's board meeting."

Do not argue and do not promise. Acknowledge it, ask for the specific examples, and offer containment you can actually deliver tonight: turn off the affected report or flag it as under review, rather than switching off everything. Give a time for your next update. The kind of sentence that lands is "I'd rather pause that one report than have you present a number neither of us trusts." Our customer-scenario transcript shows a full version of this round with scoring notes.

9. "Explain to our CFO, in two minutes, what your system does and what it cannot do."

Start with the business outcome, not the technology: what work it removes and how you measure that. Then the limits, stated plainly: where it is wrong, how often on the test set, and what a human still checks. A CFO trusts an engineer who volunteers the limits.

Which behavioural questions come up, and what makes an answer strong?

Mostly ownership and judgement. A strong answer is one specific story with your own actions in it, ending in what changed, not a description of how you generally work.

10. Tell me about a time you said no to a deadline.

The strong version shows that you said no to the date, not to the person: you explained what could be delivered by then, what it would cost to hit the original date, and let them choose. A college project counts if it is true.

11. Why FDE, and not a regular software engineering role?

Say what you like about the work, specifically: being close to the person with the problem, seeing your code used the week you ship it. Then show you know the cost: client pressure, and possibly travel. "I like both coding and talking to people" is the answer everyone gives, so it earns nothing. I compare the two roles in detail in FDE vs software engineer.

How should you prepare if you are not yet interview-ready?

Build the projects these questions assume, then rehearse the rounds aloud with someone who pushes back.

That is how our FDE for Freshers programme is built. It is taught live online by working practitioners, with optional classroom labs at our Noida centre, and needs no coding experience to start. I lead it: my day job is Senior Data Scientist at Parexel, a Goldman Sachs–backed company, with about ten years in data science and AI. Ishaan Sharma, a Senior Data Scientist at Nuvo AI (Meril Group), is our co-instructor for AI and GenAI. Phase 6 ends with exactly the client round described above: you run a mock discovery session and a demo while a mentor plays a difficult enterprise client, and the session is recorded and reviewed with you.

EMI starts from ₹8,000/month; the full fee is shared on a free counselling call. Eligible learners are covered by our job guarantee with minimum package assurance, or 50% of the fee back, for those meeting the attendance, deliverable and capstone criteria. Terms and conditions apply. The conditions include at least 70% in every assessment, at least 80% live attendance, four or more logged applications a week and attending the interviews we arrange; the minimum package and full conditions are in our published terms. Who this is not for: if your interview is next week, a six-month programme will not help you, so use this page and practise aloud. If you already have several years of shipping production code, the proposed FDE for Professionals track is the better fit.

Do FDE interviews ask LeetCode-style DSA?

Some do, usually at a lighter level than a product-company SDE loop. Prepare the core well and stop there.

Arrays, strings, hashmaps, stacks and queues, recursion, and two-pointer and sliding-window patterns are the core a coding screen draws on. Failing the coding round ends the loop, so do not skip it, but the scenario and client rounds are where offers are decided. The FDE roadmap shows where this fits in a study plan.

What do Indian startups ask freshers?

Honestly, public detail is thin, so the postings are a better guide than forum threads.

In one r/developersIndia thread about a UnifyApps fresher FDE interview, read on 12 Oct 2026, commenters discussed pay, not rounds: one said "mostly 12/14 LPA", another "18-22 LPA for freshers". Those are unverified anecdotes, and they say nothing about what was asked.

In our database on 12 Oct 2026, only 2 of the 43 postings that state a minimum ask for a year or less: Prodigal's Forward Deployed Engineer – AI Agents in Mumbai and AiStudio's Forward Deployed Engineer, both asking for one year. At two years there are roles such as Kyndryl's FDE in Gurugram and HighRadius's FDE (AP) in Hyderabad. Across all 138 listings, client-facing work (67) and AI agents (55) are named more often than any single language. So expect a practical coding screen, then questions on talking to a client and reasoning about an agent: prepare questions 4, 5, 7 and 8 hardest. For which fresher roles actually exist, see FDE jobs for freshers in India.

What to do this week

1. 1Ask your recruiter which rounds are in your loop, and how long each is.
2. 2Write your answer to question 1 on one page, about a project someone else used. If you have none, that is your first task.
3. 3Do question 7 aloud in 20 minutes, with a different client, such as a logistics firm wanting exception emails sorted.
4. 4Ask a friend to play the angry client from question 8 and to interrupt you twice. Write the follow-up email within ten minutes of finishing.
5. 5Solve two array or hashmap problems a day, no more, and spend the saved time on the scenario rounds.