What should an FDE candidate be ready to demonstrate?

Clarify a customer problem, write correct code, work with data and APIs, design a safe implementation and explain delivery trade-offs. For AI-focused roles, add retrieval, tool permissions and evaluation. The exact assessment depends on the employer and level.

120 numbered practice questions follow, with open answers and practical follow-ups. These are not leaked questions, a fixed employer interview process or a promise of selection.

Choose your level · Run the coding exercise · Practise a mock interview

What you will take away

Choose a preparation path for your level, practise 120 distinct questions, run Python and SQL examples, work through a system-design case and use a mock-interview rubric to identify your next improvement.

How to use these questions

Try an answer aloud before reading ours. Start with the direct answer, then explain the constraint, your decision, the evidence and a limitation. Use a real example you are allowed to discuss or label it as a learning exercise. The purpose is to make your reasoning useful when the interviewer changes the scenario, not to memorize a script.

Diagnose: choose six questions across coding, design and communication. Record where you cannot explain the next step.
Practise: work through the weak topic, including one small implementation or decision table.
Challenge: change a constraint, such as missing data, revoked access or an unavailable service.
Review: compare your response with the rubric and repeat the weakest area.

Use the table of contents to move directly to a topic. The first 30 questions establish the core delivery journey; questions 31-120 deepen role preparation and technical or stakeholder scenarios.

Choose your preparation path

Your starting point	Start here	Evidence to practise
Fresher or graduate	Questions 1-12, 25-40, 41-60 and 91-93.	One truthful learning project, clear Python and SQL, basic access control and an explanation of what remains untested.
Backend or full-stack developer	Questions 1-6, 19-30, 61-80 and 111-120.	Turn an integration or release into a customer-delivery story with scope, trade-offs and operating evidence.
AI application developer	Questions 13-18, 71-100 and the evaluation walkthrough.	Separate retrieval, answer quality, tool safety and end-to-end task success.
Experienced delivery engineer	Questions 71-80 and 101-120, then technical gaps.	Architecture decisions, rollout risk, incidents, reusable components and stakeholder judgement.
Interview tomorrow	Review your own project, recruiter instructions and the 45-minute mock.	Explain one complete project well; do not attempt to memorize all 120 answers overnight.

This is a study guide, not an eligibility rule. Match your practice to the advertised level. For a broader skills sequence, use the FDE learning roadmap; for role-fit questions, compare FDE and software-engineering ownership.

What employer sources establish about FDE interviews

Primary employer pages were reviewed on 9 October 2026. They support the need for role-specific preparation; they do not establish that the questions below appear in an employer’s interviews.

Source	Useful preparation signal	Do not assume
Palantir: Getting Hired	Discusses role-dependent preparation, technical problem solving and explaining your work.	A fixed round count, a current leaked question bank or identical assessment for every candidate.
Palantir: Students and Early Talent	Distinguishes roles and notes that the recruiter can provide preparation guidance.	Graduate and experienced candidates must demonstrate the same prior ownership.
OpenAI: FDE, Seattle	Describes discovery, scoping, system design, building and production rollout.	Its specific experienced-role requirements apply to every company or to all entry-level roles.

Ask the recruiter whether there will be coding, an open-ended decomposition exercise, system design, a project deep dive or a take-home. Treat that response as more relevant than a generic online account of another person’s interview.

A practical structure for strong answers

Problem, constraint, decision, evidence, limitation. This five-part structure keeps a response concrete without turning it into a speech.

Part	Illustrative policy-assistant answer
Problem	Support staff need the current permitted policy for an account question.
Constraint	Different users have different access; some documents are outdated.
Decision	Start with read-only retrieval and citations; defer account changes.
Evidence	Test answerable, unsupported, outdated and cross-account cases against a versioned set.
Limitation	Synthetic tests establish behaviour on those cases, not production accuracy or customer adoption.

Weak answer: “I would use an advanced agent with a vector database.” Stronger answer: “First I would confirm the decision the user needs to make. I would compare a simple search baseline with a grounded answer workflow, keep account changes disabled and test permission failures before proposing a pilot.” The stronger answer explains a decision and its verification.

Questions 1-6: customer discovery and scope

1. A customer says, “We need an AI agent.” What do you ask first?

Ask which task is failing today, who performs it, what information they use and how success will be observed. Request a walkthrough of a recent example and a difficult exception. Separate the business need from the proposed architecture. Then decide whether a rule, search interface, assisted workflow or agent is justified.

Example or follow-up: A useful opening is: “Show me the last case where this process failed.” Follow with who made the decision, which information was missing and what a correct result would have looked like. Avoid starting with a vendor recommendation.

2. How would you turn an ambiguous request into a first release?

Identify one user, one workflow and one measurable outcome. Record the input, output, constraints and non-goals. Agree on acceptance criteria and a small demonstration that tests the riskiest assumption. Explain what is excluded, who can approve scope changes and what evidence would cause you to revise the plan.

Example or follow-up: For a policy assistant, a first release might answer questions from approved documents without changing accounts. A measurable acceptance case would include a permitted question, a supported answer and a source reference. Account changes remain out of scope.

3. What is the difference between a requirement and an assumption?

A requirement is an agreed condition the solution must satisfy. An assumption is something currently believed but not established. For example, every ticket has a valid account ID may be an assumption. Test it against permitted data before designing an integration that cannot handle missing identifiers.

Example or follow-up: Maintain a short assumption log with the assumption, evidence needed, owner and decision affected. An untested data-access assumption can invalidate the whole schedule even when the code is straightforward.

4. How do you choose a success metric?

Connect it to the user’s task and establish a baseline measurement process. For routing, measure correct reviewed assignments and time to a decision, not simply model response speed. Include a counter-metric such as incorrect high-priority routing so an apparent efficiency improvement does not hide an unacceptable failure.

Example or follow-up: If 18 of 20 reviewed synthetic tickets are routed correctly, report that exact sample result. Do not call it 90% production accuracy. Inspect which two cases failed and whether those failures carry disproportionate cost.

5. A customer asks for another feature just before release. What do you do?

Clarify the need and impact, then assess implementation, testing and operating consequences. Present options: defer it, replace a lower-priority item or change the release scope and date through the agreed owner. Do not silently add work or reject the request without explaining the trade-off.

Example or follow-up: A strong response is: “We can keep Friday’s release with the agreed scope, or add this feature after testing and revise the date. Which business outcome is more important?” Show the decision rather than hiding the schedule impact.

6. How do you work when the needed data is not available?

Identify who owns access and which decision depends on the data. Use synthetic data to test mechanics while clearly marking validation gaps. Avoid claiming production readiness from that exercise. Propose a permitted sample or a staged access review and record what cannot be verified until access is resolved.

Example or follow-up: A synthetic fixture can verify schema handling and UI behaviour. It cannot establish whether real documents contain readable text, whether the retrieval index covers the task, or whether customer permissions were granted.

Questions 7-12: APIs, data and implementation

7. How would you handle duplicate API requests?

First define what makes two requests the same operation. Use an appropriate idempotency key and a durable record of the request fingerprint and outcome where required. A repeated key with a different payload must not silently reuse the old result. Consider concurrency and the boundary around any external side effect.

Example or follow-up: For an account-change request, store the operation key with a fingerprint of the approved payload. The same key and payload may return the prior result; the same key with a different account should be a conflict. A memory-only set will not survive a restart.

8. Which failures should be retried?

Distinguish temporary failures from invalid input, authorization errors and permanent business rejection. Use bounded retries with suitable delay only when the operation is safe to repeat. Set an overall deadline and expose the final failure. Retrying everything can multiply load or duplicate actions without solving the problem.

Example or follow-up: A timeout after sending a write has an ambiguous outcome: the server may already have completed it. Check the operation status or use the provider’s idempotency contract before replay. A retry must fit inside the overall request deadline.

9. An integration returns HTTP success but wrong data. How do you investigate?

Compare the returned schema and semantics with the contract. Check identifiers, units, time zones, pagination and stale records. Trace a known case through each transformation. A transport-level success means the request completed, not that the business result is correct. Add a regression case once the mismatch is understood.

Example or follow-up: For example, a report can be wrong because one endpoint returns paise while another expects rupees. Trace a single known record, document the unit conversion and add a test. Increasing the timeout would not address that defect.

10. How do you protect secrets in a portfolio application?

Keep secrets out of source, sample data, screenshots and logs. Use environment-specific secret configuration and least-privilege credentials. Publish a sample configuration containing names, not real values. If a credential was exposed, removal from the latest file alone is not enough; rotate it and assess the exposure.

Example or follow-up: Use a deliberately fake sample token and an example environment file containing variable names. Inspect generated logs and screenshots too. A secret can leak through observability even when it never appears in the repository.

11. What belongs in an API error response?

Return a stable error category, a safe explanation and a request identifier where useful. Do not reveal credentials, internal stack traces or another user’s data. Make it possible for the client to distinguish validation, permission and temporary service failures without parsing an unpredictable natural-language message.

Example or follow-up: For example, return a stable code such as ACCOUNT_ACCESS_DENIED and a safe request ID. The UI can show an actionable message without exposing whether another tenant’s account exists or revealing an internal stack trace.

12. How do you decide whether to add a queue?

Investigate task duration, load, ordering, retry needs and user expectations. A queue can decouple work but adds operational and consistency complexity. Explain the simpler synchronous baseline, the problem it cannot meet and how queued work will be tracked, deduplicated and recovered after failure.

Example or follow-up: A multi-minute document import may fit a job queue, while a fast account lookup may not. Discuss the status endpoint, cancellation, duplicate work, maximum attempts and how a user learns that the job failed.

Questions 13-18: RAG, agents and evaluation

13. How do you distinguish a retrieval problem from a generation problem?

Inspect the retrieved evidence before the final answer. If the correct permitted source is absent, investigate ingestion, filtering and retrieval. If the source is present but the answer contradicts it, investigate generation and output checks. Keep separate test evidence so prompt changes do not hide a retrieval defect.

Example or follow-up: Use a case where the correct paragraph is known. Check whether it was ingested, permitted, retrieved and included in context before investigating the answer. Otherwise a prompt adjustment may appear to help while the root retrieval defect remains.

14. When should a grounded assistant refuse to answer?

When permitted evidence is absent, conflicting or insufficient for the requested conclusion, return a bounded explanation or route to a human. Do not invent a citation to make the answer appear complete. Define the expected behaviour for unsupported questions in the evaluation set before release.

Example or follow-up: A useful response is: “The permitted policy documents do not establish that exception. I can show the relevant section or route the case for review.” Include conflicting versions and inaccessible sources in the test set.

15. How do you enforce authorization for a tool-using agent?

Authenticate the caller and check permission in application code at the tool boundary. Validate the proposed arguments and bind them to the authorized context. Do not trust a user ID selected by the model. Require appropriate confirmation for consequential actions and log the decision without leaking sensitive data.

Example or follow-up: If the model proposes changing account B while the user is allowed only account A, reject the action in the tool implementation. Do not ask the model to reconsider as the only protection; the application must enforce the boundary.

16. Does structured JSON mean the answer is correct?

No. A response can satisfy the schema and still contain an incorrect account, unsupported amount or wrong conclusion. Validate structure separately from domain rules, source grounding and authorization. Use the schema to constrain shape; use application checks and evaluation to assess meaning and permitted behaviour.

Example or follow-up: The object {“account_id”:”B”,”approved”:true} may be valid JSON and still be unauthorized or unsupported. Type validation, business validation and permission checks answer different questions.

17. How would you build an evaluation set?

Start from the intended tasks and realistic failures. Specify inputs, permitted context, expected outcomes and judging rules. Include normal, edge, adversarial and unavailable-service cases. Version the dataset, separate development from held-out checks and report denominators. Investigate failures rather than relying only on an aggregate score.

Example or follow-up: Include a case manifest with category, expected behaviour and scoring rule. Keep prompt-development cases separate from a held-out check. A report without the number or type of tested cases is hard to interpret.

18. How do you control an agent’s cost and latency?

Measure the number and duration of model and tool calls. Set appropriate time, retry and action limits. Remove unnecessary steps and compare with a simpler workflow. Report quality alongside cost: a cheaper system that silently fails the task is not necessarily an improvement. Define a safe timeout or escalation path.

Example or follow-up: Measure calls per completed task, not only cost per model response. A workflow with repeated retries or failed tasks can look cheap per call but expensive per useful outcome. Set a safe stop condition when budgets are exhausted.

Questions 19-24: deployment and operational judgement

19. What must be ready before a pilot release?

Confirm the version, permitted users and data, acceptance evidence, known limitations, owner, monitoring and stop criteria. Verify how access is revoked and how the previous version is restored. A pilot should have a controlled scope and an explicit decision process, not simply a public link to unfinished code.

Example or follow-up: Use a release checklist with an owner for each item. A disabled write tool, restricted pilot cohort and tested rollback may be more useful than a long presentation about production readiness.

20. What is a rollback plan?

It is a tested way to return to a known acceptable state, including configuration and data compatibility where relevant. Identify the trigger, decision-maker, steps and verification. Reverting application code may be insufficient after an incompatible migration or an irreversible external action, so plan those cases separately.

Example or follow-up: If a release writes a new database format, ask whether the previous application can still read it. For irreversible external actions, define reconciliation or compensation rather than implying a code rollback erases the effect.

21. What would you monitor in an AI customer workflow?

Monitor task completion, failures, latency, usage and meaningful quality indicators. Track permission denials, tool errors and human escalation where relevant. Use safe request identifiers to connect events. Avoid logging sensitive prompts indiscriminately; observability should make debugging possible without creating an unnecessary data exposure.

Example or follow-up: Track a request across retrieval, model call and tool result using a safe correlation ID. Keep user-visible completion separate from technical HTTP success. A successful response with the wrong business outcome is still a defect.

22. A customer reports that yesterday’s release is giving worse answers. What do you do?

Establish impact and stop or limit the affected workflow if needed. Compare versions, configuration, data and model settings using reproducible cases. Communicate what is known and the next update time. Restore a known acceptable state when appropriate, then add regression coverage and document the cause.

Example or follow-up: Start with one reproducible affected case and compare the previous and current versions on the same permitted inputs. Do not assume the prompt changed; source documents, access rules or provider behaviour may have changed too.

23. How do you hand over a solution?

Identify the receiving owner and walk through setup, configuration, operating checks, known limits and recovery steps. Ask them to perform a realistic task using the runbook. Resolve missing knowledge before declaring handover complete. A document sent by email is not proof that another person can operate the system.

Example or follow-up: Ask the receiving owner to follow the runbook to inspect a failed job and restore a known configuration. Their questions expose missing operational knowledge more reliably than asking whether the document looks complete.

24. How do you know a pilot should expand?

Compare evidence against agreed acceptance and stop criteria. Check representative use, unresolved risks, support capacity and data permissions. Do not generalise from a few friendly demonstrations. Record the decision and what additional evidence is needed for a broader rollout, including who is accountable for the next stage.

Example or follow-up: Expansion might require acceptable results across several user groups, resolved high-risk failures and enough support capacity. Record exclusions: success on one document type does not prove performance on every customer source.

Questions 25-30: communication and personal evidence

25. Explain your project to a non-technical stakeholder.

Start with the user problem, show what the application changes and explain the decision it supports. Describe the limits and where a person remains responsible. Use architecture details only to answer a relevant question. A clear explanation should help the stakeholder make a decision, not display terminology.

Example or follow-up: An illustrative opening is: “The tool helps support staff find the applicable policy and shows the source. Staff still approve account changes.” That states value and responsibility without requiring the listener to know what RAG means.

26. Tell me about a failure.

Choose a real event you may discuss. Explain your part, the initial assumption, how you detected the problem and what you changed. Include the effect on users or the project where known. Avoid disguising a success story as a weakness or assigning all responsibility to someone else.

Example or follow-up: Use situation, responsibility, decision, result and learning. If the result was negative, state it. A good learning example might explain how a missing permission check was detected in testing and how the design was corrected before release.

27. How do you disagree with a customer’s preferred architecture?

Understand the reason behind the preference, including constraints you may have missed. Present the risks and compare alternatives using a small experiment or decision table. Agree on who makes the final decision. Record the choice and remaining risks without turning the discussion into a contest over technical taste.

Example or follow-up: Compare alternatives against the same requirements: delivery time, data control, quality, operating cost and maintainability. If the customer constraint makes your preferred option infeasible, acknowledge it and revise the recommendation.

28. What did you personally build in your project?

Separate your code and decisions from framework features, sample code and collaborators’ contributions. Point to a component you can explain and modify. State the license or attribution for reused material when relevant. Clear boundaries make the work more credible, not less impressive.

Example or follow-up: Name the part you owned: for example, the validation layer, tenant-scoped SQL query and regression tests. Explain which framework handled model calls. Being precise is stronger than saying you built an entire platform alone.

29. Why do you want an FDE role?

Connect your motivation to actual work: customer discovery, implementation, delivery and learning from use. Give an example that supports the preference. Also acknowledge the parts you are preparing for, such as travel or ambiguous requirements. A salary trend alone does not explain why you will enjoy the role.

Example or follow-up: A credible answer connects your preference to evidence: “I enjoyed clarifying an unclear request, building the integration and watching users test it.” Then acknowledge a real development area rather than claiming perfect fit.

30. What would you ask the interviewer?

Ask about ownership, first engagements, engineering review, production support and how customer feedback affects the product. Ask what successful performance looks like at the advertised level. These questions help you assess the role while demonstrating that you understand delivery extends beyond a demo.

Example or follow-up: Ask: “How is ownership divided between the deployment team and product engineering after launch?” or “What would a successful first engagement look like at this level?” Choose questions whose answers would change your understanding of the role.

Questions 31-40: role fit and interview preparation

31. How is an FDE interview different from a general software-engineering interview?

Prepare to connect implementation decisions to a customer workflow, not only solve an isolated coding problem. You may need to clarify an unclear goal, explain data constraints and propose a usable release. Coding fundamentals still matter. The balance varies by employer, so use the actual job description and recruiter guidance rather than assuming that every FDE interview contains the same rounds.

Practise next: Explain one project twice: first to an engineer, then to the person who would use it.

32. Are FDE, FDSE and solutions engineer interviews interchangeable?

No. Titles can overlap, but hands-on ownership differs. Check whether the advertised role builds production software, develops prototypes, supports sales, implements a platform or combines these responsibilities. Prepare evidence for the stated scope. A solutions demonstration does not by itself establish experience operating a service, and a backend project does not automatically demonstrate customer discovery.

Practise next: Ask who owns code review, production incidents and customer acceptance.

33. How should a fresher answer questions about customer experience?

Use a truthful university, volunteer or personal-project example with a real or explicitly simulated user. Explain how you gathered requirements, changed the implementation after feedback and tested the result. State that it was a learning project. Do not convert classmates into enterprise customers or synthetic tests into production impact. Show sound reasoning while acknowledging the responsibilities you have not yet held.

Practise next: What feedback changed your original design?

34. How should an experienced backend engineer demonstrate FDE readiness?

Translate existing experience into a delivery story: the user problem, the integration you owned, the constraint, the release decision and the operating result. Identify which customer conversations you personally handled. Where your experience is indirect, say so and describe how you worked with product or support. Demonstrate willingness to investigate a workflow without pretending that backend depth alone proves stakeholder leadership.

Practise next: Explain a trade-off that changed because of user feedback.

35. How do you prepare for a company whose platform you have never used?

Read the public product documentation, the role description and an accessible example workflow. Build a small permitted exercise if tooling is available, recording what you actually tried. Separate concepts you understand from product features you have only read about. Ask whether the assessment expects platform-specific knowledge or evaluates learning and problem solving. Do not claim production experience after watching a demo.

Practise next: What would you need to learn in your first week?

36. What should you clarify with the recruiter before a technical assessment?

Ask about the assessed skills, duration, environment, allowed language, permitted references or AI assistance, collaboration expectations and accessibility needs. Confirm whether a take-home requires paid services and how to submit it safely. These questions remove avoidable uncertainty; they are not requests for confidential questions. Follow the stated rules even if a tool would make the exercise faster.

Practise next: Can you explain your solution without the tools used to create it?

37. How do you handle an unfamiliar library during a live exercise?

State what you know, inspect the available interface or documentation if permitted, and isolate a small experiment. Explain the expected input and output before connecting the library to the larger solution. If it remains uncertain, describe a simpler implementation or a clearly marked assumption. Avoid inventing API names and presenting them as tested code.

Practise next: What would you verify before relying on this dependency in production?

38. What evidence should you bring to a project deep dive?

Bring a permitted problem brief, architecture sketch, code you can explain, representative tests, a reproducible run command and a short list of limitations. Include a decision that changed and why. Use synthetic examples when employer work is confidential. A screenshot of a successful response is supporting material, not enough evidence to establish correctness, security or operating reliability.

Practise next: Open the component you personally changed and explain one failure case.

39. How do you answer when you genuinely do not know?

Say which part is unfamiliar, then reason from known constraints. Clarify the required guarantee, suggest a test or authoritative reference, and explain what you would avoid until the uncertainty is resolved. For example, do not promise a provider supports idempotency without checking its contract. Intellectual honesty is useful only when paired with a practical next step.

Practise next: Which assumption would be most dangerous to leave untested?

40. What should a strong first-90-days answer contain?

Describe an adaptable sequence, not a promise to redesign everything immediately. First learn users, product boundaries, security requirements and delivery conventions. Then own a small reviewed implementation and observe its use. Finally propose a reusable improvement backed by evidence. Ask how the employer defines success at the advertised level and which responsibilities require supervision or approval.

Practise next: How would your plan change for an existing troubled deployment?

Questions 41-50: Python coding and testing

41. How would you keep the latest status for each ticket from unordered events?

Define latest before coding: here it means the highest non-negative revision, not the last list position. Validate ticket ID, revision and status; track conflicting values for the same ticket and revision; retain the highest revision per ticket. Exact duplicates can be ignored. Return deterministic output for testing. The worked Python exercise below implements this contract and explains its memory trade-off.

Practise next: What if an older conflicting event arrives after a newer revision?

42. When would you use a dictionary rather than repeatedly scan a list?

Use a dictionary when the operation needs repeated lookup by a stable key, such as ticket ID. Repeated linear scans can turn an otherwise simple batch operation into quadratic work. Explain expected hash-table lookup behaviour, memory cost and key semantics rather than simply saying dictionaries are always faster. For a tiny ordered collection or range query, a different structure may fit better.

Practise next: What changes when the dataset no longer fits in memory?

43. Why must input validation check types as well as values?

A value can pass a loose check while violating the contract. In Python, bool is a subclass of int, so isinstance(True, int) is true. If a revision must be an ordinary integer, explicitly reject booleans. Also decide how to treat blank strings, missing keys, null values and unknown enum values. Validation should reflect the interface agreement, not silently repair every unexpected input.

Practise next: Would you coerce the string "2" to integer 2, and where would that rule be documented?

44. How would you process a large file without loading everything at once?

Read records incrementally and process bounded batches, while tracking only necessary state. A generator reduces input buffering but does not make an unbounded deduplication dictionary disappear. Explain parsing failures, checkpointing, output commits and restart behaviour. If correctness requires remembering every historical identifier, use durable storage or a defined retention window rather than claiming constant memory.

Practise next: Can the consumer resume safely after the process stops halfway through?

45. When is async Python useful, and when is it not enough?

Async can improve concurrency for operations that spend time waiting on compatible network or file interfaces. It does not automatically speed up CPU-heavy Python computation or make blocking libraries non-blocking. Bound concurrent requests, propagate cancellation and set deadlines. Compare sequential execution, threads, processes and async against the actual workload instead of treating async syntax as a performance guarantee.

Practise next: How would you prevent 10,000 queued tasks from overwhelming an upstream API?

46. How would you handle exceptions without hiding defects?

Catch errors at a boundary where you can make a useful decision: return a validation response, retry a permitted transient failure, or record a failed job. Preserve diagnostic context safely. Do not catch every exception and return success or an empty result. Distinguish expected domain failures from programming defects, and ensure callers can tell whether the requested work actually completed.

Practise next: What happens if error reporting itself fails?

47. How do you make time-dependent code testable?

Pass a clock or time value into the logic instead of reading the current time in every function. Use timezone-aware values and define expiry boundaries explicitly. Tests can then cover just-before, exactly-at and just-after expiry without sleeping. Separate elapsed-duration measurement from business timestamps, and do not assume clocks on different machines are perfectly synchronized.

Practise next: Is a token valid at the exact expiry instant?

48. What is the difference between unit, integration and end-to-end tests?

A unit test checks a small piece of logic with controlled dependencies. An integration test checks a real boundary such as a database or API contract. An end-to-end test exercises a user workflow across components. Use each for the risk it exposes; many mocked unit tests cannot prove a real integration works, while only end-to-end tests may make failures slow and difficult to diagnose.

Practise next: Which test would catch a database migration that changes a column type?

49. How would you test a function beyond the happy path?

Start from its contract and partition inputs: normal, empty, boundary, malformed, duplicated and conflicting. Check deterministic ordering and whether input objects are mutated when they should not be. Add a regression test for each discovered defect. For suitable functions, use properties such as order independence or idempotence, but confirm the property is actually required before asserting it.

Practise next: Should shuffling the event list change the latest-status result?

50. How do you debug a coding solution that passes samples but fails hidden cases?

Re-read the contract and identify assumptions not covered by the samples: empty input, repeated keys, ties, integer boundaries and ordering. Construct the smallest counterexample and trace state changes. Review time and memory complexity against the limits. Explain your investigation aloud. Do not randomly patch conditions until examples pass without understanding which invariant was broken.

Practise next: What single additional test would most challenge your current implementation?

Questions 51-60: SQL, data modelling and ingestion

51. How do you select the latest record per entity in SQL?

Use a window function such as ROW_NUMBER partitioned by the full entity key and ordered by the defined version or time. Filter to row number one in an outer query. Resolve ties explicitly or enforce uniqueness in the schema. MAX(revision) alone does not reliably return the corresponding status. In a multi-tenant system, both filtering and entity identity must respect the tenant boundary.

Practise next: See the tested SQL exercise below for a parameterized tenant-scoped example.

52. Why can a join unexpectedly multiply rows?

Check the cardinality on both sides. If one ticket has several events and several labels, joining both child tables can produce combinations rather than one row per ticket. Identify the intended output grain, aggregate or select the needed child records before joining, and test counts on a small fixture. DISTINCT may hide the symptom while preserving an incorrect business calculation.

Practise next: What is the intended meaning of one output row?

53. How should NULL affect a SQL filter or count?

NULL represents a missing or unknown value, not an empty string or zero. Use IS NULL for the relevant test and distinguish COUNT(*) from COUNT(column), which excludes null values in that column. Define the business meaning of missing data before replacing it. A missing payment amount is not automatically a zero-value payment.

Practise next: How would you report a rate when some records have unknown outcomes?

54. How do you choose an index for a slow query?

Inspect the actual filter, joins, ordering, data distribution and query plan. Consider an index whose leading columns support the access pattern, then measure on a representative dataset. Include storage and write overhead. An index on every column is not a strategy, and a fast query on ten rows says little about a table with millions of records.

Practise next: Would a tenant-and-ticket lookup benefit from the same index as a global time-range report?

55. What should be inside a database transaction?

Group changes that must become visible consistently, such as updating an operation record and recording its outcome. Keep the transaction bounded and understand the isolation level. A database transaction does not automatically include an external email or payment API. For cross-system effects, describe an outbox, compensating action or reconciliation process and explain the remaining failure window.

Practise next: What if the database commits but the network acknowledgement is lost?

56. How would you introduce a breaking schema change safely?

Plan compatibility across old and new application versions. A common approach is to add a compatible field, deploy readers and writers that tolerate both shapes, backfill with verification, switch usage and remove the old field later. Define rollback and ownership at each step. Treat the sequence as a design pattern to adapt, not a universal migration recipe.

Practise next: Which deployment step would make rollback impossible?

57. How do you handle late-arriving data?

Distinguish event time from processing time and define how long results can be revised. Use source versions or another explicit ordering rule rather than arrival order alone. Recompute affected aggregates or issue corrections where required. Document the lateness window, retention policy and user-visible behaviour. If the business requires final results, explain when and why a result becomes final.

Practise next: What happens to a daily report when yesterday’s event arrives today?

58. How would you design incremental synchronization with a third-party system?

Use a supported cursor, change token or version boundary, persist progress only after corresponding data is committed, and handle pagination and retries. Decide how deletions and out-of-order updates are represented. Reconcile periodically against an authoritative view where feasible. A timestamp alone can miss equal-time changes unless the provider documents a stable ordering and resume contract.

Practise next: Can you replay the last successful page without corrupting local data?

59. What data-quality checks belong before an AI workflow?

Check required identifiers, valid types, duplicates, freshness, allowed values and relationships needed by the task. Quarantine or reject invalid records according to an agreed policy, with traceable reasons. Measure coverage and failure categories. Feeding malformed data into a model does not remove the need for contracts; it may merely produce plausible output that hides the underlying problem.

Practise next: Which invalid records may be safely skipped, and which should stop the batch?

60. How do you prove a dashboard metric is trustworthy?

Define its numerator, denominator, time window, exclusions and source of truth. Trace a few records from source through transformation to the displayed value. Reconcile totals and investigate differences rather than rounding them away. Version changes to the definition. A dashboard that refreshes quickly can still mislead if cancelled, duplicate or unknown cases are counted inconsistently.

Practise next: Can another engineer reproduce the same number from the same snapshot?

Questions 61-70: APIs and distributed-system reliability

61. How would you authenticate a webhook and handle replay?

Use the sender’s documented signature protocol over the required request bytes, verify the signature safely and check the permitted timestamp window where supported. Store an event identifier to detect repeated deliveries. A valid signature proves a particular authenticity property, not that processing should happen twice. Protect secrets and define rotation. Do not invent a signature algorithm instead of following the provider contract.

Practise next: How do legitimate delayed deliveries interact with the replay window?

62. How should a client handle API rate limits?

Respect documented limits and server retry guidance, bound concurrency and use controlled backoff with jitter where appropriate. Share the budget across workers when the limit applies to an account. Keep an overall deadline and expose incomplete work. Retrying immediately in every worker can increase pressure and delay recovery. Prioritize essential work if all requests cannot be completed within the limit.

Practise next: What would you do when the rate limit is per tenant rather than global?

63. How do you choose timeouts across a chain of services?

Start from the user-visible deadline and allocate time across operations, retries and response handling. Propagate remaining deadlines when interfaces support them. Cancel work that no longer has a consumer when safe. Avoid independent long timeouts at every layer, which can produce much longer end-to-end delays. Measure latency distribution under realistic load and leave room for recovery behaviour.

Practise next: What should the user see when an optional enrichment call times out?

64. What does at-least-once delivery mean for a worker?

The same message may be delivered more than once, so the handler must tolerate repetition. Acknowledge only after the required durable work, and define an idempotency key that matches the business operation. Handle concurrent duplicates, poison messages and replay. Do not describe the queue as providing exactly-once business effects unless the complete processing boundary genuinely supports that guarantee.

Practise next: What happens if a worker crashes after completing the effect but before acknowledging?

65. How do you prevent stale cache entries from leaking data?

Include the relevant authorization context in the cache design, not just the question text. Define invalidation for document updates, entitlement changes and deletion. Consider whether storing the result is appropriate at all. Short expiry reduces some staleness but is not a substitute for access control. Never serve one tenant’s answer to another because their prompts look similar.

Practise next: How does permission revocation affect already cached answers?

66. When would you use a circuit breaker?

Use one when repeated dependency failures are consuming resources or causing cascading delays. Define failure classification, an opening threshold, a recovery probe and a safe fallback. Keep it distinct from retries and rate limits. A breaker that hides errors indefinitely can make recovery worse, so expose its state and test both the failed and recovered paths.

Practise next: Should validation errors count toward opening the circuit?

67. How do you manage backward-compatible API evolution?

Identify consumers and their expectations, then prefer additive changes when they preserve semantics. Validate whether new required fields, changed enums or altered error behaviour break older clients. Use versioning or a migration plan for incompatible changes, with observable adoption and a communicated retirement policy. Adding a field can still break a strict consumer, so contract testing matters.

Practise next: How would you learn which clients still depend on the old response?

68. How do you prevent lost updates when two users edit the same record?

Use an explicit concurrency strategy such as a version check, conditional update or suitable lock. With optimistic concurrency, compare the submitted version with the current version and return a conflict rather than silently overwriting another edit. Explain how the user resolves it. A last-write-wins policy is a deliberate trade-off, not a default guarantee of correctness.

Practise next: Can your update check and write happen atomically?

69. How would you expose progress for a long-running job?

Return an operation identifier and a status resource with clear states such as queued, running, succeeded, failed or cancelled. Define result retention, polling guidance and authorization for status access. Report meaningful progress only when you can measure it. Explain cancellation semantics: cancelling the client request may not undo work already performed by a downstream system.

Practise next: Which states are terminal, and can clients safely retry job creation?

70. What would you do with a poison message that fails repeatedly?

Limit retries, preserve enough safe diagnostic context and move the message to a controlled failure path for inspection. Alert on impact and volume rather than silently discarding it. Fix the cause before replaying, and make replay idempotent. Do not put unrestricted sensitive payloads in broadly accessible logs or dead-letter tools merely because they help debugging.

Practise next: Who is authorized to correct and replay the failed operation?

Questions 71-80: system design and implementation architecture

71. How would you design a support-ticket triage service?

Clarify ticket sources, allowed routing actions, review requirements and acceptable errors. Begin with validated ingestion, a rules baseline, a classification component, a review queue and an audit trail. Separate recommendation from an irreversible action. Measure routing quality by category and track backlog and latency. Explain unavailable dependencies and duplicate tickets before selecting a model or orchestration framework.

Practise next: Which decisions remain human-owned in the first release?

72. How would you design a permission-aware document assistant?

Authenticate users, resolve their permitted document scope, retrieve only within that scope and generate answers tied to usable evidence. Preserve document version and source references. Define unsupported and conflicting-evidence responses. Secure ingestion and deletion as well as query-time retrieval. Test cross-account access explicitly. The system-design walkthrough below expands this into a read-only first release with staged action support.

Practise next: Where is the authorization boundary if the model proposes a document identifier?

73. When is a relational database enough instead of a vector database?

If the task is exact lookup, filtering, joins or structured reporting, a relational query may solve it with clearer guarantees. Semantic retrieval becomes useful when meaning-based matching adds value beyond those operations. Compare quality, latency, permissions and maintenance on representative queries. Some relational platforms support vector search too; the decision concerns required behaviour, not fashionable product categories.

Practise next: What baseline would prove that semantic retrieval is necessary?

74. How do you choose between a modular monolith and microservices?

Start with team size, independent scaling needs, deployment boundaries and failure isolation. A modular monolith can simplify delivery while preserving clear interfaces. Microservices add network, observability and consistency costs but may support genuine independent ownership. Explain the specific constraint that justifies separation and how the boundary could evolve. A diagram with more boxes is not automatically a better design.

Practise next: Which component must scale or deploy independently today?

75. How would you design a document-ingestion pipeline?

Track each document from permitted source through parsing, validation, chunking, indexing and readiness status. Preserve source identifiers, versions and access metadata. Make stages restartable and record failures without marking incomplete content as searchable. Handle changed documents, deletions and corrupt files. Evaluate extraction quality, because a successful parse call does not establish that tables or reading order are correct.

Practise next: How will users know that a newly uploaded document is not yet ready?

76. How would you estimate capacity before building?

State assumptions about users, request rate, concurrency, payload size, retention and dependency latency. Derive rough storage and throughput requirements and identify which assumption most affects the design. Use the estimate to choose a test workload, not to claim measured capacity. Revisit it using observed traffic. Separate peak demand from daily averages and account for background work.

Practise next: If demand doubles, what is likely to saturate first and how would you verify it?

77. How would you integrate with a legacy system that has no reliable API?

Investigate supported exports, database views, batch interfaces or approved automation before proposing direct access. Agree on ownership, permissions, update frequency and reconciliation. Isolate the adapter behind a contract so the rest of the application does not depend on undocumented behaviour. Avoid scraping or modifying a production system without authorization and an operating plan.

Practise next: How do you detect when the legacy format changes silently?

78. How do you choose what to build versus buy?

Compare required capabilities, integration effort, operating cost, security fit, portability and support obligations. Test a narrow representative workflow rather than rely only on feature lists. Include exit and migration costs. Build where it creates necessary differentiation or control; buy where a supported service meets the need. Neither choice removes the responsibility to validate the resulting customer workflow.

Practise next: Which requirement would make the preferred vendor unsuitable?

79. How do you design human approval for a consequential action?

Show the reviewer the exact proposed action, affected resource and supporting evidence. Bind approval to a specific payload or version, re-check authorization before execution and invalidate approval if material inputs change. Record who approved what and handle duplicate execution. A vague confirmation in chat is not a sufficient control for an action whose target or amount can change later.

Practise next: What if permission is revoked after approval but before execution?

80. How do you turn a customer-specific implementation into a reusable component?

Look for a repeated stable contract across engagements, then separate configuration from genuinely shared behaviour. Keep customer policy, credentials and data isolated. Validate the abstraction against more than one realistic case and provide tests and versioning. Avoid generalizing after a single example or creating a framework so broad that every customer needs custom exceptions.

Practise next: Which variation belongs in configuration, and which means the abstraction is wrong?

Questions 81-90: advanced RAG, agents and evaluation

81. How would you choose a document chunking strategy?

Inspect document structure and the questions users ask. Compare boundary-aware chunks with a simple baseline, preserving headings, source locations and access metadata. Evaluate whether relevant evidence is retrieved intact and whether irrelevant context overwhelms it. Chunk size is a testable design choice, not a magic number. Tables, procedures and short reference entries may need different treatment.

Practise next: What happens when an answer depends on two sections that are far apart?

82. When would you combine keyword and vector retrieval?

Use a hybrid approach when the query set contains both semantic paraphrases and exact identifiers such as product codes or policy numbers. Evaluate candidate recall and final answer quality against separate baselines. Define filtering and ranking behaviour explicitly. A hybrid stack adds complexity and does not automatically improve every query; inspect failures by query type rather than report only one aggregate score.

Practise next: Which query would keyword search handle better than embedding similarity?

83. What is reranking, and how would you decide whether it helps?

Reranking reorders an initial candidate set using an additional relevance model or rule. It can improve ordering only among candidates that were retrieved, so it cannot recover a missing source by itself. Measure relevance at the chosen cutoff alongside added latency and cost. Confirm that reranking does not bypass permissions and retain a simple baseline for comparison.

Practise next: Is the relevant document missing from candidates or merely ranked too low?

84. How do you evaluate citations instead of merely checking that links exist?

Check that the cited source is accessible to the user, is the correct version and actually supports the associated claim. Distinguish citation presence from correctness and coverage. Include answers with several claims so a single relevant link cannot conceal unsupported statements. Keep examples of incorrect attribution and broken source references in the evaluation set.

Practise next: Does every material claim have support, or only the first sentence?

85. How do you measure abstention behaviour?

Create cases that are answerable and cases that should not be answered from the permitted evidence. Track unsupported answers, correct abstentions and unnecessary refusals separately. State the denominator for each metric. Reducing hallucinations by refusing everything is not a useful system, while answering every question confidently is unsafe. Choose operating thresholds based on the cost of each error type.

Practise next: The worked evaluation table below shows why one overall accuracy number is insufficient.

86. How would you choose between prompt engineering, RAG and fine-tuning?

Identify the failure first. A clearer prompt can improve instructions; retrieval can supply relevant current evidence; fine-tuning may help a repeated task or behaviour when suitable data and evaluation justify it. These techniques can be combined, but none automatically fixes authorization or missing ground truth. Compare small controlled experiments and include data maintenance, cost and regression risk.

Practise next: Does the failure come from missing knowledge, inconsistent behaviour or a broken application contract?

87. When does a multi-agent design make sense?

Consider it when independently scoped tasks or roles create a measurable benefit over a simpler workflow. Define coordination, shared state, tool permissions, termination and failure handling. Evaluate the complete task, including extra calls and handoff errors. Multiple agents that repeat the same reasoning can raise cost without improving reliability. Begin with a single-agent or deterministic baseline and demonstrate the gap.

Practise next: What evidence would make you remove an agent from the design?

88. How should an agent store and use conversational memory?

Separate short-lived interaction state from durable user preferences or business records. Define consent or authorization, retention, update rules and tenant isolation. Treat recalled text as potentially stale and untrusted, not a higher-priority instruction. Do not persist secrets or every conversation by default. Test deletion, incorrect memories and context changes that invalidate an earlier assumption.

Practise next: Can a malicious or mistaken statement become a durable instruction?

89. How do you compare two model or prompt versions fairly?

Use the same versioned test cases, allowed context and scoring rules, and record model and configuration versions. Review regressions by category, not only the average. Repeat stochastic cases when variability matters and include human review for consequential errors. Prevent test-set leakage into tuning. Report quality, latency and cost together, with limitations of the sample.

Practise next: Would you deploy a version with a higher average score but a new permission-related failure?

90. How do you evaluate a tool-using agent end to end?

Check whether the intended task completed safely, not only whether the final answer sounds correct. Inspect tool arguments, authorization decisions, state transitions, external effects and recovery behaviour. Test denied actions, unavailable tools, duplicate calls and misleading tool output. Separate deterministic checks from judgement-based scoring, and review traces without collecting unnecessary private data.

Practise next: An agent says "done" but the tool failed. How will your evaluation detect that?

Questions 91-100: security, identity and privacy

91. What is the difference between authentication and authorization?

Authentication establishes the caller’s identity under the chosen mechanism. Authorization determines which operation that identity may perform on a particular resource. A logged-in user is not automatically allowed to read every account. Enforce authorization at trusted application boundaries for each relevant action, including background jobs and downloads, and test access using users with different permissions.

Practise next: Where would you check access when a model calls an account lookup tool?

92. How would you prevent cross-tenant data access?

Derive tenant context from trusted identity and membership information, validate resource ownership, and scope queries, caches, retrieval and object storage consistently. Use additional database controls where appropriate, but verify the whole path. Test guessed identifiers and shared-resource edge cases. Do not rely on a tenant ID supplied by the user or model as the sole security boundary.

Practise next: Which background or administrative path could accidentally bypass the normal filter?

93. How do you handle prompt injection in retrieved content?

Treat retrieved documents and tool outputs as untrusted data, even when they look like instructions. Keep tool permissions and consequential-action checks in application code. Restrict available capabilities, validate arguments and test documents that attempt to redirect the workflow or expose data. Prompt wording can help clarify intent but is not a complete security boundary.

Practise next: What can the application prevent even if the model follows the malicious text?

94. What should a service account be allowed to do?

Grant the minimum permissions required for its specific workload, scope them to relevant resources and separate environments. Prefer short-lived credentials where supported and define rotation and revocation. Document the owner and audit usage. A read-only assistant should not inherit broad administrative write permissions merely because using one powerful account is convenient during development.

Practise next: Which permission would you remove before the pilot starts?

95. How do you keep observability useful without exposing sensitive data?

Log identifiers, timings, error categories and decision outcomes that support debugging, while minimizing raw prompts, documents and personal information. Apply redaction before storage where possible, restrict access and define retention. Evaluate traces as data stores with their own risks. Redacting the user interface does not protect information already copied into logs or analytics.

Practise next: Can you reproduce the defect with a synthetic case instead of a production payload?

96. How would you implement deletion across an AI application?

Map all copies: source storage, extracted text, indexes, caches, conversation history, logs and backups under the applicable retention policy. Define how deletion propagates, is verified and is communicated. Remove stale retrieval and cache entries promptly according to the contract. Do not promise instant erasure from every system when backup retention or external providers impose different processes.

Practise next: How will you detect a deleted document reappearing after a synchronization job?

97. How do you defend an integration against unsafe URL fetching?

Restrict destinations to the necessary supported services and validate redirects and resolved destinations according to a security-reviewed design. Keep internal or metadata services out of reach from arbitrary user-supplied URLs. Apply network controls, timeouts and size limits. A superficial string check is not enough. In an interview, describe the trust boundary and involve security expertise for implementation details.

Practise next: Does the downloader follow a redirect to a destination it would otherwise reject?

98. What should you do when a secret is accidentally committed?

Revoke or rotate the credential promptly, assess its scope and possible use, and follow the organization’s incident process. Remove exposed material from active code and coordinate repository-history cleanup where appropriate. Check logs, artifacts and shared copies. Deleting the latest line or making the repository private does not reliably invalidate a credential already exposed.

Practise next: How do you verify that dependent services now use the replacement credential?

99. How would you assess a new open-source dependency?

Check whether it solves a real need, its license, maintenance status, provenance, update process and known security issues using appropriate tooling. Pin or constrain versions and test upgrades. Review how the dependency handles data and network access. Popularity alone is not sufficient, but neither is rewriting a mature component without understanding the cost and risk.

Practise next: What is your response if the dependency becomes unmaintained?

100. Can you send customer data to an external model provider?

Only within the organization’s approved data-handling arrangement and the provider configuration authorized for that use. Identify data classification, contractual constraints, region, retention and access requirements before integration. Minimize data and use synthetic examples during unapproved prototyping. Do not infer permission from a customer saying "try AI" or from the availability of a personal API key.

Practise next: Who must approve the data flow before a pilot using real records?

Questions 101-110: release, observability and incidents

101. How do you distinguish an SLI, SLO and SLA?

An SLI is a defined measure such as the proportion of eligible requests completed successfully. An SLO is a target for that measure over a window. An SLA is a service commitment with agreed terms, potentially including consequences. Define eligibility, exclusions and measurement location. Do not promise an SLA from a local benchmark or confuse uptime with successful task completion.

Practise next: Which user-visible failure should count against your objective?

102. How would you design a canary release?

Expose a controlled portion of representative traffic or users to the new version, compare agreed indicators with the baseline and define stop or rollback criteria. Ensure the experiment is permitted and that data changes remain compatible. A canary is not just a small percentage: it needs observable risk signals and an owner who can stop expansion.

Practise next: What if the small cohort never exercises the high-risk workflow?

103. How would you use a feature flag safely?

Use a flag to control a specific behaviour independently of deployment, with clear default, ownership and retirement plan. Evaluate configuration consistently and test both states. Keep access control separate; a hidden button is not permission enforcement. Consider partially completed work when disabling a feature. Too many permanent flags can create an unmanageable set of operating states.

Practise next: Can switching the flag off leave queued actions in an unsafe state?

104. Why is p95 latency often more useful than the average?

The average can hide a slow minority of requests. A percentile describes the distribution: p95 is the value at or below which approximately 95% of observations fall under the chosen measurement method. Examine sample size, time window and workload mix. Do not average percentiles from different services and assume the result is the end-to-end percentile.

Practise next: Are slow requests concentrated in one tenant, document size or dependency?

105. How do you diagnose a memory leak or growing backlog?

First distinguish a temporary load spike from sustained growth. Compare memory, queue age, throughput, error rate and worker restarts over time. Reproduce with a controlled workload and inspect retained state or slow dependencies. Adding workers may relieve symptoms but can amplify pressure elsewhere. Set safeguards while identifying the bottleneck and verify recovery after the workload ends.

Practise next: Does the system drain the backlog when new traffic stops?

106. What belongs in an incident update to a customer?

State the affected capability, known impact, current mitigation and next update time. Separate confirmed facts from hypotheses and avoid exposing another customer’s data. Use plain language and an accountable contact. Update the message when understanding changes rather than waiting for a complete root cause. Do not promise restoration times without evidence or hide a material limitation.

Practise next: How would your update differ for degraded service versus potential data exposure?

107. What makes an alert actionable?

An alert should identify a condition requiring timely human action, explain likely impact and point to an owner and runbook. Tune it using observed incidents and false positives. Distinguish paging from informational dashboards. Alerting on every exception can conceal the important signal; silently ignoring a failed critical workflow is equally poor. Test notification routing and recovery handling.

Practise next: What exact action should the on-call engineer take after receiving it?

108. How do RPO and RTO affect a recovery plan?

Recovery point objective describes the tolerated data-loss window, while recovery time objective describes the desired time to restore the relevant service. Choose them with business owners and design backups, replication and restoration procedures accordingly. A backup job succeeding does not prove restoration works. Test recovery with a representative dataset and record actual results and gaps.

Practise next: What does the application do if restored data is older than an external system?

109. How do you plan a load test without misleading results?

Model realistic request mix, concurrency, payloads, think time and dependency behaviour within authorized infrastructure. Measure errors, latency, resource use and cost as load increases, including recovery afterwards. State which providers were mocked and which limits were not tested. Do not send uncontrolled traffic to customer or third-party systems or extrapolate a tiny local test into a production guarantee.

Practise next: Which workload characteristic most differs from your current test?

110. What should a blameless post-incident review produce?

A timeline, user impact, contributing technical and process conditions, detection gaps and prioritized actions with owners. Focus on why the system allowed the failure rather than finding a person to blame. Preserve accountability for following through. Verify fixes and update tests or runbooks. A document declaring "human error" without changing conditions is not a useful outcome.

Practise next: Which action would reduce recurrence, and which would improve detection if it recurs?

Questions 111-120: stakeholder judgement and leadership

111. Two stakeholders disagree about the main problem. How do you proceed?

Ask each to describe a concrete workflow, affected users and the cost of the current failure. Make the disagreement visible as competing objectives or constraints rather than choosing the louder sponsor. Compare evidence, identify the decision owner and propose a small test if uncertainty remains. Record the agreed priority and what is deferred so implementation does not oscillate between incompatible goals.

Practise next: What evidence could change the priority decision?

112. How do you respond to an unrealistic delivery deadline?

Break the request into essential outcomes, dependencies and verification work. Explain what can credibly be delivered by the date, what risks remain and which scope reduction or extra support would change the plan. Escalate decisions through the agreed owner. Avoid silently removing testing or promising a full production rollout when only a limited demonstration is feasible.

Practise next: Which safety or correctness check would you refuse to omit, and why?

113. What if users do not adopt a technically working tool?

Observe their actual workflow and investigate friction: missing access, slow interactions, unclear outputs, duplicate entry, poor fit or lack of trust. Compare intended use with real use before adding features. Work with users on a small improvement and measure whether the task becomes easier. Adoption is not guaranteed by successful API calls or a positive demonstration to management.

Practise next: What would you watch during a user walkthrough?

114. How do you say no to a request that creates unacceptable risk?

Explain the user goal you understand, the specific risk and the boundary you cannot cross. Offer a safer alternative, such as a read-only recommendation or reviewed action, and identify who can decide policy questions. Keep the tone collaborative. Do not frame security as personal preference or agree to bypass a control merely to protect a deadline.

Practise next: Can the business goal be met without the requested privileged access?

115. How do you decide between a one-off customer fix and a product change?

Assess urgency, number of affected customers, strategic fit and the risk of maintaining divergent behaviour. Contain an urgent issue with a narrow reviewed fix where appropriate, while documenting whether it belongs in the shared product. Include product and engineering owners in the decision. Avoid turning every customer preference into a platform feature or every repeated need into permanent custom code.

Practise next: What evidence would justify generalizing the solution?

116. How do you estimate business value without inventing ROI?

Establish a measurable baseline and identify which part of the workflow the change affects. Use ranges and explicit assumptions for unmeasured inputs. Separate time saved in a controlled exercise from realized savings in normal use, including review and operating costs. Explain uncertainty and propose a pilot measurement plan. A model-generated answer rate is not itself a business-value metric.

Practise next: Which cost or failure could cancel the apparent saving?

117. How do you manage handoff across teams and time zones?

Define interfaces, owners, response expectations and a shared record of decisions. Use concise written updates with current state, blockers and the next action, supported by reproducible examples. Reserve synchronous meetings for decisions that benefit from discussion. Confirm the receiving team can operate the workflow rather than assuming a document link completes ownership transfer.

Practise next: Who acts if the primary owner is unavailable during an incident?

118. How do you mentor a junior engineer without taking over the task?

Agree on the outcome and boundaries, ask them to explain their reasoning, and review a small checkpoint early. Give specific feedback tied to correctness, maintainability or user impact. Let them implement the change where safe, then ask them to demonstrate tests and limitations. Increase autonomy with evidence while retaining appropriate review for risky changes.

Practise next: How would you respond if the proposed design works but is unnecessarily complex?

119. How do you recover trust after your recommendation was wrong?

Acknowledge the error promptly, explain the confirmed impact and own your contribution without inventing certainty about the cause. Present a corrective plan, update affected decisions and communicate progress. Show what changed in the evidence or review process. Trust is rebuilt through reliable follow-through, not a defensive explanation or a promise that errors will never happen again.

Practise next: What would you tell the stakeholder before the complete root cause is known?

120. How should you close an FDE interview?

Summarize the problem-solving strengths supported by the discussion, acknowledge one relevant learning area and ask focused questions about the role’s ownership and next steps. Clarify any answer you materially misstated without reopening every topic. Do not claim an outcome or pressure the interviewer for a guarantee. Leave them with a coherent, truthful account of how you approach customer-facing engineering.

Practise next: Which example best demonstrates the role’s actual requirements, not just your favourite technology?

Worked Python coding exercise

Task: implement a function that returns the highest valid revision for each ticket from an unordered event batch. Exact duplicates are allowed; conflicting statuses for the same ticket and revision are errors. This is an original practice exercise supporting questions 41-50.

Clarify the contract before coding

The input is an iterable of event dictionaries from one trusted tenant context. Tenant authorization is outside this pure function.
A ticket ID is a non-blank string. IDs are case-sensitive and are not normalized.
A revision is a non-negative integer, excluding booleans. Allowed statuses are open, pending and closed.
Only ticket ID, revision and status define an event for this exercise; additional fields are ignored.
Any invalid or conflicting event aborts the batch with ValueError. The input is not modified.
Return one row per ticket, sorted by ticket ID, including an empty list for an empty batch.

def latest_status(events):
    """Return the highest valid revision per ticket in deterministic order."""
    seen = {}
    latest = {}
    for event in events:
        if not isinstance(event, dict):
            raise ValueError("Each event must be an object")
        ticket = event.get("ticket_id")
        revision = event.get("revision")
        status = event.get("status")
        if not isinstance(ticket, str) or not ticket.strip():
            raise ValueError("ticket_id must be a non-empty string")
        if type(revision) is not int or revision < 0:
            raise ValueError("revision must be a non-negative integer")
        if status not in ("open", "pending", "closed"):
            raise ValueError("Unsupported status")
        key = (ticket, revision)
        if key in seen and seen[key] != status:
            raise ValueError("Conflicting status for the same revision")
        seen[key] = status
        if ticket not in latest or revision > latest[ticket][0]:
            latest[ticket] = (revision, status)
    return [
        {"ticket_id": ticket, "revision": revision, "status": status}
        for ticket, (revision, status) in sorted(latest.items())
    ]


if __name__ == "__main__":
    events = [
        {"ticket_id": "T2", "revision": 1, "status": "open"},
        {"ticket_id": "T1", "revision": 2, "status": "closed"},
        {"ticket_id": "T1", "revision": 1, "status": "open"},
        {"ticket_id": "T1", "revision": 2, "status": "closed"},
    ]
    print(latest_status(events))

Expected result

[{'ticket_id': 'T1', 'revision': 2, 'status': 'closed'},
 {'ticket_id': 'T2', 'revision': 1, 'status': 'open'}]

The function keeps two maps for different reasons. latest selects each ticket’s highest revision. seen detects conflicts even when an old revision arrives after a newer one. Keeping only the latest status would miss that older conflict.

Complexity: for n events and k distinct tickets, expected processing and sorting time is O(n + k log k); stored state is O(n + k) in the worst case. This is an in-memory batch exercise, not a distributed deduplication service or an exactly-once guarantee.

Test case	Expected behaviour
Empty batch	Return an empty list.
Out-of-order events and exact duplicate	Keep the highest revision once; deterministic output; do not mutate input.
Same ticket and revision, different status	Raise ValueError, even if this is an older revision.
Blank ID, unknown status or invalid revision	Raise ValueError rather than silently coerce.
Revision 0; T1 and t1	Accept zero and treat the two IDs as distinct.

Interview extension: explain how the contract changes for a streaming feed, bounded retention or partial-batch acceptance. Then discuss which state must be durable and which system is responsible for authorization. Do not simply put the function behind an endpoint and call the whole service production-ready.

Worked SQL exercise: latest event per ticket

Task: return the latest ticket status for an authorized tenant. Use SQLite for this runnable example. The same ticket ID may exist in another tenant, and that other tenant can have a much higher revision.

Schema and synthetic fixture

CREATE TABLE ticket_events (
    tenant_id TEXT NOT NULL,
    ticket_id TEXT NOT NULL,
    revision INTEGER NOT NULL CHECK (revision >= 0),
    status TEXT NOT NULL CHECK (status IN ('open', 'pending', 'closed')),
    UNIQUE (tenant_id, ticket_id, revision)
);
INSERT INTO ticket_events VALUES
('team-a', 'T1', 2, 'closed'),
('team-a', 'T1', 1, 'open'),
('team-b', 'T1', 99, 'pending'),
('team-a', 'T2', 1, 'open'),
('team-a', 'T2', 3, 'pending');

Parameterized query

WITH ranked AS (
    SELECT tenant_id, ticket_id, revision, status,
           ROW_NUMBER() OVER (
               PARTITION BY tenant_id, ticket_id
               ORDER BY revision DESC
           ) AS rn
    FROM ticket_events
    WHERE tenant_id = ?
)
SELECT ticket_id, revision, status
FROM ranked
WHERE rn = 1
ORDER BY ticket_id;

Bind the question-mark parameter through the database driver’s parameter interface. In Python’s sqlite3 interface, call connection.execute(query, (authorized_tenant_id,)).fetchall(), where query is the SQL above. The tenant value must come from trusted, authorized application context. Parameter binding prevents value text from becoming SQL; it does not decide which tenant the caller may access.

Authorized tenant	ticket_id	revision	status
team-a	T1	2	closed
team-a	T2	3	pending

The UNIQUE (tenant_id, ticket_id, revision) constraint removes revision ties in this exercise. Without a tie rule or uniqueness guarantee, ordering by revision alone is not deterministic. Do not select MAX(revision) beside an unrelated status and assume both came from the same row.

SQLite’s official window-function documentation describes ROW_NUMBER and partitioning. Other databases may use different parameter syntax and additional access controls.

Tested, with a defined boundary: the included Python and SQLite examples passed 11 local unittest methods on 9 October 2026. Coverage includes invalid values, older conflicts, non-mutation, tenant filtering, parameter binding and the uniqueness constraint. This validates these examples on their test fixtures, not a deployed application’s authorization or production reliability.

Worked system-design case: policy assistant with controlled actions

Original scenario: a support manager wants an assistant to answer policy questions and create account-change requests. Policies can become stale, staff have different account permissions and the account API can time out. The useful first move is to separate answering from acting.

Step 1: discover the decision and constrain the first release

Ask who uses the assistant, what a typical case looks like, which policy is authoritative, who owns permissions and which mistakes cause harm. Agree on a read-only first release that cites permitted current evidence. A change request can remain a manually reviewed workflow until the action boundary is designed and tested.

Step 2: describe the data flow and trust boundaries

Authenticated user
  -> application authorization
  -> permitted, versioned document retrieval
  -> answer generation with sources
  -> evidence and output checks
  -> answer or explicit escalation

Later action phase:
  proposed change -> reviewed payload -> authorization re-check
  -> idempotent operation record -> account API -> verified outcome

Keep credentials and authorization decisions outside model control. Treat retrieved text as evidence, not instructions. Store enough safe trace information to investigate a failed case without logging every private document.

Step 3: state failure behaviour before discussing scale

Scenario	Expected behaviour	Evidence to show
Correct evidence is absent	Explain that the answer is not established; offer a permitted escalation.	Unsupported-question evaluation case.
Two policy versions conflict	Use the agreed authority/version rule or escalate, not silently merge them.	Versioned source fixture and decision rule.
User requests another account	Deny access at the application boundary.	Cross-account negative test.
Retrieved document contains instructions to ignore rules	Keep tool and access restrictions enforced outside the model.	Adversarial document case plus tool-boundary test.
Account API times out after a proposed write	Record an uncertain outcome and reconcile; do not blindly repeat.	Simulated ambiguous-response integration test.
User approves one payload and it later changes	Require approval for the changed material action.	Approval binding and stale-approval test.

Step 4: define a pilot decision

Identify permitted users, representative cases, quality and latency goals, operating owner and rollback or disable conditions. Establish who reviews unsupported answers and how a defect becomes a regression case. Expand only when the agreed evidence supports it. A system-design interview should make these trade-offs visible, even if there is no time to build the whole application.

For deeper practice, use the customer discovery and problem-decomposition guide and deployment and handover checklist.

Worked evaluation example: show the denominator

Illustrative arithmetic, not measured model performance: suppose a labelled set contains 100 permitted policy questions. Eighty are answerable from the provided evidence; twenty should be refused or escalated. In this invented example, the assistant gives 70 correct supported answers and 10 unnecessary refusals on the answerable cases. It correctly refuses 18 unsupported cases but invents answers for two.

Measure	Calculation	What it tells you
Supported success on answerable cases	70 / 80 = 87.5%	Performance among cases that should have an answer.
Unnecessary refusal rate	10 / 80 = 12.5%	Lost usefulness on answerable cases.
Unsupported-answer rate	2 / 20 = 10%	Unsafe answering among cases without sufficient evidence.
Correct unsupported-case handling	18 / 20 = 90%	Refusal/escalation performance on unsupported cases.
Correct behaviour across this full set	(70 + 18) / 100 = 88%	A summary that must not hide the two unsupported answers.

The aggregate score does not decide release safety. The impact of unsupported answers, the representativeness of cases and the quality of labels matter. Keep a separate access-control test suite; semantic answer scores do not prove authorization. For agent workflows, also inspect tool actions and final state rather than scoring only prose.

Anthropic’s agent-evaluation guidance and Microsoft’s RAG-evaluator documentation provide additional context for separating evaluation dimensions. The figures above are original teaching arithmetic, not results attributed to either source.

A 45-minute mock interview exercise

Original practice scenario: a support manager wants an assistant to read policy documents and create account-change requests. The documents may contain outdated instructions and users have different account permissions.

Minutes 0-8: clarify users, decisions, data permissions and the current process.
Minutes 8-18: scope a read-only first release and draw the data and trust boundaries.
Minutes 18-28: explain retrieval, evidence handling and an unsupported-question path.
Minutes 28-38: design tests for stale documents, cross-account access and tool failures.
Minutes 38-45: propose a pilot, monitoring and a next-stage decision.

The timing is a suggested practice format, not an employer’s interview schedule. A peer should challenge one assumption halfway through. Explain how you revise the design without abandoning the user problem.

Change the constraint halfway through: the customer now says users must act across multiple accounts, while the account API has no documented idempotency support. A strong candidate asks who is authorized for which account, scopes the action boundary and investigates outcome reconciliation. They do not respond by adding another agent and assuming the risk disappeared.

Ask your practice partner to record one unclear assumption, one unsupported claim and one well-defended decision. Revisit the weakest response after the session instead of trying to perfect every sentence.

Score the quality of your reasoning

Use 0 for absent, 1 for named without explanation, 2 for a concrete explanation and 3 for evidence plus limitations. Score dimensions separately. This is an original self-review rubric, not an employer’s selection score or a prediction of hiring.

Dimension	What a strong response demonstrates	Warning sign
Problem clarity	Names user, decision, constraint and acceptance criteria.	Picks a framework before understanding the task.
Implementation	Explains contracts, edge cases and tests; can modify the code.	Relies on tool names or untested snippets.
Data and security	Identifies trusted identity, permissions, validation and data handling.	Lets a model-selected ID determine access.
Evaluation	Separates retrieval, outputs, actions and business outcomes.	Uses one unexplained accuracy percentage.
Operations	Includes deployment, monitoring, recovery and ownership.	Stops at a successful local demonstration.
Communication	States decisions, uncertainty and personal contribution clearly.	Invents impact or avoids trade-offs.

Choose the lowest-scoring dimension for the next practice session. If implementation is weak, complete a small tested exercise. If communication is weak, explain the same project to a non-technical peer. If operations are weak, rehearse failure and recovery rather than making another demo.

A seven-day preparation plan

Day	Main work	Concrete output
1	Read the actual vacancy and confirm assessment format.	Responsibility-to-evidence map and known gaps.
2	Practise Python and SQL with boundary cases.	Working code, expected results and explanations.
3	Review APIs, data contracts and reliability.	A duplicate-request and timeout walkthrough.
4	Design one customer workflow with permissions.	Architecture sketch and failure-case table.
5	Review AI evaluation if relevant to the role.	A labelled case set with clear denominators and limits.
6	Run the mock interview and review the recording or notes.	Two specific improvements, not a vague confidence score.
7	Rehearse your project and confirm logistics.	Accessible permitted artifacts and focused interviewer questions.

This is a preparation schedule for consolidating existing skills, not a promise to become an FDE in seven days. Allow more time where the exercise reveals a foundational gap.

Final checklist before the interview

Confirm time zone, meeting link, coding environment and permitted tools.
Run your project from its documented setup and inspect links.
Remove secrets and private customer material from what you will share.
Prepare one success, one failure and one trade-off you personally owned.
Explain tests and limitations without claiming simulated results are production outcomes.
Keep a few role-specific questions ready and leave room to clarify the problem.

Turn interview preparation into demonstrable skills

A question bank tells you what to practise; a working project shows whether you can do it. Choose one of the FDE project build plans, document a customer problem and test a small complete workflow. Use the resume and portfolio guide to present the evidence honestly.

The Forward Deployed Engineer Course at Brolly Academy provides a structured learning option. The confirmed duration is two months, with INR 20,000 online or INR 25,000 classroom tuition and trainer Manish. Use the free demo to compare your current skills with the syllabus and confirm batch hours, project feedback, taxes and cloud costs before enrolling. A course does not guarantee an interview, job or employer selection.

Frequently Asked Questions

How many questions are in this FDE interview guide?

There are exactly 120 numbered original practice questions, with answers and practical follow-ups or examples. The Python, SQL, system-design and mock-interview exercises are additional learning material.

Are these actual Palantir or OpenAI interview questions?

No. These are original practice questions. Linked employer pages provide role and preparation context, not proof that a company asks these questions or follows a fixed interview sequence.

What topics should I prepare for an FDE interview?

Prepare coding, data and APIs, customer discovery, system design, permissions, delivery and communication. Add retrieval, agents and evaluation when the role involves AI applications. Confirm the actual assessment with the recruiter.

Can freshers use these questions?

Yes. Begin with fundamentals and use clearly labelled learning projects. Explain your contribution, tests and limitations without claiming paid customer or production experience you do not have.

Do FDE interviews include coding or data structures?

They can. The exact scope depends on the employer and role. Practise writing correct code, explaining complexity and testing boundary cases; ask the recruiter about the language, format and permitted tools.

Is Python mandatory for every forward deployed engineer role?

No single language is universal. Python is useful for many data and AI workflows, while other roles may require JavaScript, TypeScript, Java or another stack. Follow the job description and assessment instructions.

Should I prepare SQL?

SQL is valuable when the role includes data investigation, integration or customer reporting. Practise joins, grouping, null handling, window functions and the meaning of the output, not only syntax.

What is a problem-decomposition interview?

It is an open-ended exercise in turning an unclear problem into a structured approach. Clarify users and constraints, define a first scope, compare alternatives and explain verification. Employers differ in how they assess this skill.

How long should an interview answer be?

Give the direct answer first, then enough reasoning and evidence to address the question. Pause for follow-ups instead of reciting a long script. Coding and design exercises naturally need more interaction than a factual question.

Can I use AI tools during the interview?

Only when the assessment rules permit them. Confirm the allowed tools and disclosure requirements beforehand. You should still be able to explain, test and modify anything you submit.

Should I memorize all 120 answers?

No. Use them to identify gaps and practise decisions. An interviewer may change a constraint, so understanding why an approach works is more useful than repeating the wording.

Are the coding examples tested?

The included Python and SQLite examples passed 11 local unittest methods on 9 October 2026, including invalid input, duplicate and conflicting revisions, tenant filtering and parameter binding. They are bounded teaching examples, not a complete production service.

Does completing this question bank guarantee an FDE job?

No. Selection depends on the employer, role level, demonstrated skills and assessment. Use the guide to improve preparation and build evidence, not as a hiring prediction.

How can Brolly Academy help with FDE preparation?

Review the Forward Deployed Engineer Course syllabus and free demo to discuss your skill gaps and practical learning needs. Confirm the specific batch schedule, feedback and support arrangements before enrolling.

Sources and Further Reading

Official documentation and employer pages were checked on 9 October 2026. Job availability, compensation and product details can change. Teaching scenarios are illustrative unless explicitly identified otherwise.

AI & Data Science

BI & Analytics Tools

Cloud & DevOps

Cybersecurity & Networking

Enterprise Apps & Automation

Software Development

Web Development

Software Testing & QA

Mobile, Embedded & IoT

Digital Marketing & Business

Design & Animation

Project Management & Careers

Languages & Personal Skills