Plaid AI Tooling Interview Experience

A three-round Plaid interview for a Senior Software Engineer, AI Tooling role focused less on model internals and more on putting agents into production: permissions, tool safety, failure recovery, idempotency, and whether an internal workflow actually saves people time.

Interview Experience | AI / SWE | 🔥🔥🔥 | Plaid

2026 (July–September) · Senior Software Engineer — AI Tooling · Bachelor's degree · full-time · Plaid · LinkedIn cold application · Virtual Onsite · Positive / Average · Passed · currently employed and interviewing.

This role looked like AI Tooling from the title, but the actual interviews felt closer to backend, internal platform, and agent engineering. There was not much time spent on transformers or model training. The questions kept adding production constraints instead.

Round 1: Technical deep dive — agent and internal tooling

The first round started with a project from my past work. I was asked to choose an AI or agent project that I had worked on deeply. I talked about an internal workflow automation project.

There was not much textbook questioning at the beginning. The interviewer kept asking why I had made particular design choices.

One question was:

How do you make the model call tools reliably instead of inventing parameters?

My answer was that the tool schema should be as strict as possible. Parameters should go through structured output or JSON Schema validation, and the backend should validate them again immediately before execution.

An LLM's output cannot be treated as trusted input.

For a dangerous action, such as changing user data, sending an email, or issuing a refund, I would not let the model execute it directly. I would first generate an action proposal, run a permission check, and require human approval in some cases.

The interviewer followed up:

What if the parameter schema is correct but the model chooses the wrong tool?

I said that tool selection and tool execution success should be evaluated separately. An offline evaluation should not only check whether the final answer is correct. It should also track:

• tool selection accuracy
• argument validity rate
• execution success rate
• unnecessary tool-call rate
• end-to-end task success

The interviewer then asked a very practical question:

What happens when a tool call fails or times out?

Not every failure should be retried. A timeout or a 5xx response may justify exponential backoff. A validation error or a permission denial usually does not.

For a tool with side effects, idempotency has to be considered before retrying. An agent may think the first attempt failed even though the action actually succeeded. Retrying could then execute the same action twice.

We spent a fair amount of time on this. My impression was that the team cared about agents becoming part of a production system, rather than remaining a demo.

Another question was:

If this agent is used by Support, Support can look up some customer information but must not see every sensitive field. How would you design permissions?

I would not give the agent a large service account. I would prefer each request to carry the user's identity and role, with the tool gateway performing authorization again at execution time. The agent can decide what it wants to call, but a deterministic policy decides whether it is allowed to call it.

The central question in this round was not whether I knew LangChain or LangGraph. It was whether I had thought about what could happen after an agent receives production permissions.

Round 2: System design — an internal AI workflow platform

The second round matched the job description more closely.

Plaid has many Ops and Support teams with manual workflows. A support ticket might require someone to check an account's status, inspect previous transactions, determine what may have happened, search several internal systems, and finally draft a reply or execute an action.

The prompt was to design an internal AI platform that would let non-engineering teams build these workflows themselves.

I started by separating the system into:

• workflow definition
• agent runtime
• tool registry
• authentication and authorization
• execution state
• observability

The interviewer asked:

Why not let them build everything in Retool or something like Zapier?

This felt like a product-judgment question as much as a system-design question.

My answer was that not every workflow should become an agent. If the process is deterministic — for example, call three fixed APIs and update one field — a normal workflow engine is simpler and more reliable.

An agent is more useful when the middle of the workflow contains unstructured input, reasoning, or dynamic tool selection. I would allow a workflow to contain both deterministic nodes and agent nodes, rather than sending every step to an LLM.

The interviewer seemed to like that distinction.

The discussion then moved to runtime behavior.

What happens if an agent crashes halfway through a run?

Every tool execution should have persisted state. The entire agent execution cannot live only in memory. I would model something like:

workflow_run
step_run
tool_call

Each step needs its own status. If a worker crashes, a new worker should be able to continue from the last completed step instead of replaying the entire task from the beginning.

The immediate follow-up was the difficult case:

The previous step was “refund the customer $100.” The refund succeeded, but the worker crashed before it could write the success status. What happens now?

That becomes a distributed-systems problem. The tool itself needs to support an idempotency key, or the execution layer needs to assign every side-effecting action a stable request ID. Workflow state by itself cannot resolve an ambiguous outcome safely.

We then discussed authorization. Suppose an Ops team creates a workflow and selects a tool that can access financial data. How do we prevent privilege escalation?

My answer was that a tool registry should store more than a description and a schema. It should also record:

• required permission
• allowed caller
• data classification
• side-effect level
• approval policy

The runtime still needs to pass through a policy layer every time the tool actually executes. A workflow being approved at creation time does not mean it should be allowed to execute forever under the same permissions.

Finally, the interviewer asked how to measure whether the platform was valuable.

I started with task success rate. The interviewer asked what else mattered, so I added:

• workflow completion rate
• human intervention rate
• tool failure rate
• latency
• cost per successful task
• escalation rate
• time saved per ticket

The final answer should connect these to business outcomes: did support handling time fall, and can the same team handle more tickets?

This round felt very Plaid. The architecture did not need to be flashy, but every component invited another question: why does it exist, who can call it, and what happens when it fails?

Round 3: Coding — a workflow executor

The final round was coding. It was not a standard LeetCode problem. It was a simplified workflow engine.

Given a set of tasks, each task had an ID, dependencies, and an action. A task could run only after its dependencies completed.

The first question was to return a valid execution order. I used an indegree count and a queue — a standard topological sort.

Then the interviewer added a follow-up:

Do not just return the order. Execute the tasks, with at most K tasks running at the same time.

I initially tried to modify the original breadth-first search directly. I then realized that tasks finish at different times, so the problem cannot be handled as a simple layer-by-layer traversal.

The updated design kept track of:

• a ready queue
• running tasks
• dependency state

When a task completed, I decremented the indegree of its children. Any child whose indegree reached zero went into the ready queue.

The interviewer then added failure. If a task fails, it can be retried twice. If it still fails, all tasks that depend on it must not run.

I made a small bug while writing this. At first I marked only the direct children as blocked, which left some descendants able to reach the ready queue. I caught it while running an example and added another propagation step.

The last follow-up was:

A task calls an external API. The first call times out, and you do not know whether the other side executed it. How should retry work?

This returned to the same idempotency issue from the first two rounds. The action should carry a stable execution ID. If the external API supports an idempotency key, use it. If it does not, the integration needs an additional reconciliation or deduplication strategy.

The algorithm itself was not especially difficult. I think the workflow-executor choice was deliberate because it can grow from topological sorting into a real production problem:

parallelism → failure → retry → dependency propagation → idempotency

Overall impression

This Plaid AI Tooling role was different from what I initially expected. The agent framework itself was not the focus. The interviewers did not spend much time on LangChain APIs or model-specific details.

They cared about:

• how to put an AI workflow into production
• how to control tool permissions
• how to make side effects safe
• retry, crash recovery, and idempotency
• deciding which parts should use an agent and which should not
• whether the product actually improves internal users' efficiency

AI experience combined with strong backend and platform fundamentals seems valuable for this kind of role. If your experience is mostly RAG demos, the second round may become difficult because many follow-ups turn into distributed systems, security, and production engineering.

The coding was not algorithmically extreme, but a simple version kept acquiring realistic constraints. The hardest part for me was system design: the interviewer kept forcing the vague phrase “agent platform” into concrete permissions, state, APIs, and failure behavior.