What Makes FDE Interviews Different
Forward Deployed Engineer interviews are unlike any other engineering interview. You are being evaluated on three things simultaneously:
- Can you build? — Write working code, design systems, debug under pressure
- Can you operate? — Navigate ambiguity, prioritize ruthlessly, own outcomes
- Can you communicate? — Explain technical decisions to non-technical stakeholders without losing precision
Most engineers fail FDE interviews not because they can't code but because they can't do all three at once. This question bank covers all five round types with what interviewers are scoring you on.
Round 1: Technical Coding (12 Questions)
These are typically medium-difficulty problems with a practical bent — less abstract algorithms, more "write something that actually runs in a client environment."
Q1. Given a JSON log file from a production system, write a script to identify the top 10 error types by frequency and output a summary with timestamps of first and last occurrence.
What they're testing: File I/O, JSON parsing, aggregation. Can you write clean, readable code quickly without an IDE?
Good answer signals:
- Uses
collections.Counteror equivalent without reinventing it - Handles malformed JSON gracefully (try/except)
- Asks clarifying questions: what counts as "error type"? By message string? By error code?
- Output is human-readable, not just raw data
Q2. A client's database has a users table and an events table. Write a SQL query to find users who were active in January but not in February.
What they're testing: SQL fundamentals, set operations. FDEs query client databases constantly.
Good answer:
SELECT DISTINCT u.user_id, u.email
FROM users u
JOIN events e ON u.user_id = e.user_id
WHERE DATE_TRUNC('month', e.created_at) = '2026-01-01'
AND u.user_id NOT IN (
SELECT DISTINCT user_id FROM events
WHERE DATE_TRUNC('month', created_at) = '2026-02-01'
);
Good answer signals:
- Asks whether "active" means any event or a specific event type
- Notes that NOT IN is risky with NULLs, mentions NOT EXISTS or LEFT JOIN alternative
- Considers index performance on large tables
Q3. Write a Python function that retries an HTTP request up to 3 times with exponential backoff, and logs each failure with the status code and attempt number.
What they're testing: Real-world robustness patterns FDEs use constantly when integrating with client APIs.
Good answer signals:
- Uses
time.sleep(2**attempt)or similar for backoff - Distinguishes between retryable (5xx, 429) and non-retryable (4xx) errors
- Structured logging, not just print statements
- Returns a result object or raises a typed exception with context
Q4. A client gives you a CSV with 200 columns, many with inconsistent naming (snake_case, camelCase, spaces). Write a normalizer that standardizes all column names.
Good answer signals:
- Regex-based or uses
re.subto handle all variants in one pass - Handles duplicates after normalization (two columns might become the same name)
- Returns a mapping of old → new names for audit trail
Q5. You have a pandas DataFrame with 10M rows. A client says a filter query that should take <1s is taking 45s. Walk me through how you'd diagnose and fix it.
What they're testing: Performance intuition, systematic debugging.
Good answer:
- Check if column is categorical vs. object dtype — string comparison on 10M rows is slow
- Check if there's an index on the filter column; add one if not
- Check if the filter can be vectorized — avoid
df.apply()with lambdas - Profile with
%timeitto isolate the slow step - If recurring, consider chunking or pushing the filter to the database layer
Q6. Write a function that takes two lists of dictionaries representing database records and returns the diff — records added, removed, and changed.
Good answer signals:
- Uses set operations on primary keys for adds/removes
- Only compares field values for records present in both (avoid O(n²))
- Returns structured diff, not just a boolean
Q7. A client's REST API returns paginated results (next_cursor in response). Write a generator that yields all records across all pages.
What they're testing: Generator pattern, API integration, graceful termination.
Q8. Write a simple CLI tool that takes a SQL SELECT query as input, runs it against a SQLite file, and outputs results as formatted JSON or CSV based on a --format flag.
Good answer signals:
- Uses
argparseproperly - Parameterized queries where applicable (even for a CLI, habit matters)
- Handles empty results gracefully
- Formats output with
json.dumps(indent=2)orcsv.DictWriter
Q9. Given a nested JSON config file, write a function that flattens it to dot-notation keys: {"a": {"b": 1}} → {"a.b": 1}.
Q10. A client webhook sends events with inconsistent timestamp formats (ISO 8601, Unix epoch, "YYYY-MM-DD HH:MM"). Write a normalizer that returns all as UTC datetime objects.
Good answer signals:
- Uses
dateutil.parserfor flexible parsing - Handles timezone-naive timestamps (assumes UTC unless specified)
- Doesn't throw on unknown formats — logs and returns None
Q11. You need to detect duplicate records in a client's data warehouse. Records are "duplicates" if they match on 3 of 5 specified fields. Write a function that identifies and groups them.
What they're testing: Fuzzy matching intuition. This is a common actual client problem.
Q12. Write a script that monitors a directory for new CSV files and automatically loads them into a SQLite database, skipping files already processed.
Good answer signals:
- Uses
watchdogor polls withos.scandir()if watchdog not available - Tracks processed files in a small state file or table
- Handles partial writes (file still being written when detected)
Round 2: System Design with Client Context (8 Questions)
FDE system design differs from standard SWE design: the client's constraints (no cloud, legacy systems, compliance requirements) are as important as the technical architecture.
Q13. A healthcare client wants to run AI-assisted diagnosis suggestions. They cannot send patient data to the cloud. Design the system.
What they're testing: On-premise deployment, data residency, model serving on constrained hardware.
Good answer covers:
- Local model serving: vLLM or Ollama on hospital-owned GPU servers
- Data never leaves the VPC — inference is local
- FHIR-compliant data pipeline to feed the model
- Audit logging for every AI suggestion (regulatory requirement)
- Fallback to rule-based system if model is unavailable
- Monitoring without cloud telemetry: Prometheus + Grafana on-prem
Q14. A client currently uses Excel to manage their supply chain (5,000 SKUs, 200 suppliers). They want to move to a system that gives real-time visibility. Design it.
Good answer signals:
- Start with ingestion: replace Excel workflows with forms or API connectors to supplier systems
- Database choice: PostgreSQL for relational supplier/SKU data
- Real-time = event-driven, not polling — suppliers push updates via webhooks
- Simple dashboard first (Metabase/Grafana), not custom UI
- Migration plan: Excel import → parallel run → cutover
- What NOT to build: don't pitch a custom ML forecasting system before basic data hygiene exists
Q15. Design a system that lets a legal team search 10 years of internal documents and contracts using natural language queries.
What they're testing: RAG pipeline design, enterprise search, access control.
Good answer covers:
- Document ingestion: PDF parsing (handle scans with OCR), chunking strategy
- Embedding model selection: local vs. API, cost trade-offs
- Vector database: Pinecone, Qdrant, or pgvector for smaller scale
- Retrieval: hybrid search (BM25 + vector) typically outperforms pure vector
- Access control: user's document permissions must filter search results — critical for legal
- Citation: every answer must cite the source document with page number
Q16. A fintech client processes 50,000 transactions/day in a legacy Oracle database. They want to add AI fraud detection without touching the Oracle system. Design the integration.
Good answer:
- CDC (Change Data Capture) from Oracle via Debezium → Kafka stream
- Fraud model scores each transaction in <200ms on the Kafka consumer
- Results written to a separate Postgres decisions table
- Alert system for high-risk scores (email, Slack, or internal ticket)
- Oracle untouched — zero risk to production transaction processing
Q17. A client wants to automate customer support emails using AI. Currently 500 emails/day, handled by 10 agents. Design the system with a human-in-the-loop escalation path.
Q18. Design a data pipeline that takes raw GPS telemetry from 500 delivery vehicles and produces a real-time dashboard showing late deliveries.
Q19. A client's data team runs 50 notebooks manually every morning to generate reports. They want this automated but their IT team won't allow new cloud services. Design it.
Good answer: Prefect/Airflow on-prem, notebook conversion to scripts or Papermill, cron scheduling, failure alerting via internal SMTP
Q20. A government client wants AI summarization of public meeting transcripts. They require: no third-party APIs, full audit trail, outputs reviewed by a human before publication. Design it.
Round 3: Client Simulation / Role-Play (10 Questions)
This is the round most SWEs underestimate. You play the FDE; the interviewer plays a non-technical client stakeholder. These are real scenarios FDEs face.
Q21. The client says: "Your system has been down for 3 hours. My CEO is asking for a status update and I don't understand what you're telling me." How do you respond?
What they're testing: Communication under pressure. Can you be honest, clear, and calm simultaneously?
Good answer:
- Acknowledge impact first, not technical cause: "I understand this is impacting your team right now."
- Give a plain-English status: "We've identified the issue and our team is actively fixing it. We expect to restore service within 2 hours."
- Don't say "it's complicated" — translate: "A scheduled update affected a database connection. We're restoring the previous version now."
- Offer a specific next check-in time: "I'll send you an update in 30 minutes, and again when we're back online."
Q22. A client's VP of Engineering says: "I've been told I need to use your platform but my team prefers to build in-house. Why should I trust your product over my own engineers?"
What they're testing: Navigating internal client politics without being defensive.
Good answer signals:
- Don't dismiss the VP's engineers — validate the concern
- Ask what "build in-house" means to them: a full rebuild or integrating their own logic?
- Focus on what FDE support provides: ongoing maintenance, rapid deployment, their team can focus on domain-specific logic rather than infrastructure
- Offer a proof of concept that runs alongside their existing system
Q23. Mid-deployment, a client asks you to add a feature that's not in scope. The deadline is in 2 weeks. How do you handle it?
Good answer signals:
- Clarify: what's the business impact if it's not in this release?
- If critical: negotiate timeline extension or scope reduction elsewhere
- If nice-to-have: document it for next sprint, commit to a date in writing
- Never promise what you can't deliver — FDE reputation is built on reliability
Q24. A client's internal champion leaves the company suddenly. The new contact is skeptical of the project and hasn't been part of any previous meetings. How do you rebuild the relationship?
Q25. A client says the AI's outputs are "wrong" and wants to terminate the contract. When you investigate, you find the AI is technically correct — but the client's expectation was different from what was promised. How do you handle it?
What they're testing: Navigating blame, resetting expectations, saving the relationship.
Good answer:
- Acknowledge the client's frustration as legitimate even if the technical output is correct
- Don't lead with "actually you're wrong" — that ends the relationship
- Reframe: "Let's look at what outcome you needed and see if we can get there."
- Identify the expectation gap: was it a miscommunication in the sales process? Document it.
- Propose a concrete path forward, not an apology loop
Q26. A client's data is far messier than the spec promised — missing fields, inconsistent formats, duplicates. You're 2 weeks from go-live. What do you do?
Q27. The client's CISO says they'll block deployment unless you provide a full security audit. You have 5 days. How do you approach this?
Q28. A non-technical executive keeps changing requirements in weekly calls, which is blocking your technical team. How do you manage this without damaging the relationship?
Good answer signals:
- Establish a formal change request process with documented impact assessments
- Create a "parking lot" for ideas that don't block current sprint
- Build an ally in the exec's team who can filter requests before they reach the FDE
Q29. A client's team is using the platform in ways that weren't intended and are generating incorrect results. They're presenting these results to their board. What do you do?
Q30. Midway through a project, you realize the original technical approach was wrong and will fail at production scale. The client doesn't know yet. When and how do you tell them?
What they're testing: Ownership, transparency, ability to recover from failure.
Good answer signals:
- Tell them immediately — not after you've "figured it out"
- Come with a plan, not just the problem: here's what's wrong, here's what we're doing about it, here's the revised timeline
- Own it without excessive apologizing: "We identified an issue with our original architecture. Here's what we're doing."
- Document the change and get sign-off on the new plan
Round 4: Business Case Study (10 Questions)
You're given a scenario and asked to recommend a technical approach that also addresses business constraints.
Q31. A mid-sized hospital (800 beds) wants to reduce nurse overtime by 15% using AI scheduling. What would you build, what data do you need, and what are the risks?
Framework for case study answers:
- Clarify the problem: What drives overtime? Understaffing? Unexpected absences? Inefficient scheduling?
- Data requirements: Historical schedules, shift preference data, census (patient volume) forecasts, absence records
- Build: ML demand forecasting + constraint optimization for scheduling
- Risks: Union agreements on scheduling, nurse trust in AI-generated schedules, regulatory compliance on nurse-to-patient ratios
- Measure: Track overtime hours per quarter, nurse satisfaction scores
Q32. A retail bank wants to use AI to reduce loan default rates. They have 5 years of transaction data and existing credit scores. What do you build?
Q33. A manufacturing company loses $2M/year to unplanned equipment downtime. They have sensor data from 200 machines going back 3 years. What do you propose?
Good answer:
- Predictive maintenance model on sensor time-series data
- Anomaly detection before failure (not just failure classification)
- Alert system integrated with maintenance ticketing
- ROI calculation: if you catch 30% of failures 24hrs early, what's the maintenance cost savings vs. unplanned downtime cost?
- Risk: false positives cause unnecessary maintenance — balance precision/recall based on failure cost vs. maintenance cost
Q34. A law firm wants to use AI to draft standard contracts faster. Their main concern is liability if the AI makes a legal error. How do you structure the solution?
Q35. A government agency wants to automate processing of benefit applications (currently 90-day wait). 40% of applications are rejected on technicalities. What do you build?
Good answer signals:
- Don't automate the rejection decision — automate the completeness check and flag errors before submission
- Human-in-the-loop for all actual approval/rejection decisions (regulatory and ethical requirement)
- Reduce 90-day wait by eliminating back-and-forth on incomplete applications, not by automating decisions
- Measure: time-to-complete-application, not time-to-decision
Q36. A trucking company wants real-time AI routing that accounts for weather, traffic, and driver hours-of-service compliance. They have 1,200 trucks. Design the solution and its rollout.
Q37. A university wants to personalize learning paths for 50,000 students using AI. Budget: $500K/year. What's realistic to build?
Q38. An insurance company wants AI to assist claims adjusters — not replace them. They process 10,000 claims/day. What does a good AI assist tool look like here?
Q39. A retailer's inventory forecasting model is consistently off by 25% during promotional periods. How would you diagnose this and what would you fix?
Good answer:
- The model likely wasn't trained with promo flags — promotions create a non-stationary distribution
- Feature engineering: add promo indicator, promo type, historical promo lift by SKU category
- Re-train with promo periods separated: the model should learn "normal" demand and "promo multiplier" separately
- Evaluate separately on promo vs. non-promo periods
Q40. A startup client wants you to build an AI solution in 6 weeks that they can demo to investors. Their data is a mess and the feature they want doesn't technically exist yet. What do you do?
What they're testing: Judgment. Can you scope to what's actually achievable without overpromising?
Good answer signals:
- Negotiate scope: what's the smallest version that demonstrates the core value?
- Be honest about what "demo-ready" vs. "production-ready" means
- Prioritize visual impact for the investor demo over technical completeness
- Build the data cleaning in parallel with the model — don't wait for clean data
- Set clear expectations: "This demo shows the concept; production will take X more months"
Round 5: Values and Working Style (10 Questions)
These are often framed as behavioral questions but FDE interviewers are looking for specific signals around ownership, adaptability, and client empathy.
Q41. Tell me about a time you had to make a technical decision under time pressure without all the information you needed. What did you do?
Signal they want: You made a decision, owned it, and communicated the uncertainty clearly rather than stalling.
Q42. Describe a situation where you realized mid-project that the original plan was wrong. How did you handle it with the client?
Q43. Tell me about a time a client was wrong about something technical. How did you handle it?
Signal they want: You corrected without condescension. You focused on their outcome, not being right.
Q44. Describe a project where you had to learn a new technology quickly and apply it in a client context. How did you approach it?
Q45. Tell me about a time you pushed back on a client request. What was the outcome?
Signal they want: You pushed back with data and a better alternative, not just "no." You maintained the relationship.
Q46. Describe a time you had to work across multiple stakeholders with conflicting priorities. How did you navigate it?
Q47. Tell me about a project that failed. What went wrong, and what would you do differently?
Signal they want: Clear-eyed accountability. No blame-shifting to the client or other teams.
Q48. How do you balance moving fast (client wants results) with doing things right (technical debt, maintainability)?
Good answer:
- Context-dependent: a 6-week demo has different standards than a 2-year production system
- Make technical debt explicit and documented — don't hide it
- "Doing it right" often means building the simplest thing that works, not the most elegant
- Push back when speed creates unsustainable technical risk — be specific about the cost
Q49. Why do you want to be an FDE rather than a standard software engineer or solutions engineer?
Signal they want: Genuine motivation, not "I like variety." Specific about the client-facing + technical combination.
Q50. What makes a great FDE different from a good one?
Strong answer:
A good FDE solves the problem they were given. A great FDE understands the problem behind the problem — why the client actually wants what they're asking for — and delivers that, even if it's different from the spec. The technical skill is table stakes. The differentiation is judgment: knowing when to push back, when to move fast, and when to say "we need to slow down before this breaks something important."
How to Prepare
3 weeks before the interview:
- Practice the coding questions in Python without an IDE (FDE coding rounds are often on a whiteboard or Google Docs)
- Do 2-3 mock client simulations with a friend playing a skeptical stakeholder
- Build one end-to-end project that involves messy real-world data
1 week before:
- Research the company's actual clients and use cases — interviewers expect you to reference their domain
- Prepare 3-4 strong behavioral stories with the STAR format (Situation, Task, Action, Result)
- Practice explaining technical decisions in 2 sentences to a non-technical audience
Day of:
- In system design rounds: clarify requirements before jumping to architecture
- In client simulations: slow down, listen fully, ask one clarifying question before answering
- In coding: narrate your thinking — FDEs need to communicate while working
Further reading: