Java backend developer to FDE: services skill, client-facing gap

What you walk in with

Before the questions, list your evidence plainly. A typical Spring Boot developer has:

• OpenAPI specs for services they own, and the arguments about breaking changes.
• JUnit and integration tests, often with Testcontainers.
• Kafka or RabbitMQ consumers with retry topics and dead-letter queues.
• Postmortems from production incidents, including at least one caused by a retry storm.
• Observability dashboards: latency percentiles, error rates, traces.

Keep these in front of you while you prepare. Almost every model answer below draws on one of them.

Question bank: engineering questions with an AI twist

"An agent calls your payments API as a tool. What changes in how you design that endpoint?"

"I treat the model as an untrusted client that may retry, repeat or send malformed arguments. So the tool gets a strict schema with enums and bounds, an idempotency key on anything that moves money, and a server-side authorisation check that does not rely on the agent's context. I would also cap the amount an agent can move without human approval. It is the same thinking as designing for a flaky mobile client, just stricter."

"How would you test a feature whose output changes between runs?"

"I separate what must be deterministic from what may vary. Tool arguments, routing decisions and refusals get exact assertions. Free-text answers get a labelled evaluation set and a pass rate, and I track that rate per release the way I would track p99 latency. A change that drops the pass rate blocks the release like a failing test would."

"The client says the assistant is wrong 'a lot'. Where do you start?"

"With examples, not the model. I would ask for twenty failing conversations, label why each failed (retrieval missed the document, wrong tool, bad argument, answer ignored the context) and fix the largest bucket first. In my experience with production incidents, the first fix is usually in the plumbing rather than in the part everyone is focused on."

The project that backs up the first answer

Build a small tool gateway that validates model-proposed tool calls before your service runs them. It is written in Python here, because the evaluation and model tooling you will use is Python-first, but the design is the one you already know from API work.

import json

# Hypothetical tool contract for a refund service
SCHEMA = {
    "order_id": {"type": str, "pattern_prefix": "ORD-"},
    "amount_inr": {"type": int, "min": 1, "max": 5000},
    "reason": {"type": str, "enum": {"damaged", "late", "wrong_item"}},
}
REQUIRED = set(SCHEMA)
seen_keys = {}

def validate(args):
    errors = []
    missing = REQUIRED - args.keys()
    extra = args.keys() - REQUIRED
    if missing:
        errors.append(f"missing {sorted(missing)}")
    if extra:
        errors.append(f"unexpected {sorted(extra)}")
    for name, rule in SCHEMA.items():
        if name not in args:
            continue
        v = args[name]
        if not isinstance(v, rule["type"]) or isinstance(v, bool):
            errors.append(f"{name} has wrong type")
            continue
        if "min" in rule and not rule["min"] <= v <= rule["max"]:
            errors.append(f"{name} out of range")
        if "enum" in rule and v not in rule["enum"]:
            errors.append(f"{name} not allowed: {v}")
        if "pattern_prefix" in rule and not v.startswith(rule["pattern_prefix"]):
            errors.append(f"{name} malformed")
    return errors

def call_refund_tool(raw_json, idempotency_key):
    if idempotency_key in seen_keys:
        return {"status": "duplicate_ignored", "original": seen_keys[idempotency_key]}
    args = json.loads(raw_json)
    errors = validate(args)
    if errors:
        return {"status": "rejected", "errors": errors}
    result = {"status": "refund_queued", "order_id": args["order_id"], "amount_inr": args["amount_inr"]}
    seen_keys[idempotency_key] = result
    return result

# Synthetic model outputs, including typical failure modes
proposals = [
    ('{"order_id": "ORD-1182", "amount_inr": 1499, "reason": "damaged"}', "k1"),
    ('{"order_id": "ORD-1182", "amount_inr": 1499, "reason": "damaged"}', "k1"),   # retry
    ('{"order_id": "1183", "amount_inr": 25000, "reason": "angry"}', "k2"),          # hallucinated values
    ('{"order_id": "ORD-1184", "amount_inr": "900", "reason": "late"}', "k3"),       # string amount
]
outcomes = [call_refund_tool(p, k) for p, k in proposals]
for o in outcomes:
    print(o)

assert [o["status"] for o in outcomes] == ["refund_queued", "duplicate_ignored", "rejected", "rejected"]

The four synthetic proposals exercise the cases you would expect in production: a valid call, a retry that must not refund twice, a call with invented values, and a type error where the model sent the amount as a string. In the README, add a table of fifty labelled proposals and the rejection rate by failure type. That table is what turns a coding exercise into evidence of judgement about agents.

Question bank: the client-facing half

"Tell me about a time you disagreed with a stakeholder about scope."

Most Java developers have a story about a product manager, not a client. Use it, but say what you would do differently in front of a client: write the disagreement down, offer two options with their costs, and let the person who owns the budget choose.

"How do you explain latency or cost trade-offs to a business owner?"

"In their units. Instead of 'p95 went from 800 milliseconds to 3 seconds', I would say 'one in twenty customers now waits three seconds for an answer, and the version that is faster costs roughly this much more per thousand conversations'. Then I would recommend one and say what I would monitor."

"Why forward deployed, and not a backend role on an AI team?"

"Because the problems I found most interesting in eight years of backend work were the ones in someone else's environment: a partner's API timing out, a bank's firewall rules, a client's data that did not match the contract. Forward deployed work is mostly those problems, plus model behaviour, which I have been learning deliberately. I want to be close to the people using the system."

Where to put your learning time

Your services background covers much of the engineering. The newer areas are retrieval over real enterprise data, evaluation and judge calibration, MCP and agent tool design, cloud-native deployment in a client's environment, and TypeScript, which much agent tooling now uses. The FDE for Professionals track at /courses/fde-professionals is built for experienced engineers on those topics; its schedule is proposed, and eligible learners who meet attendance and capstone criteria receive assured job interviews through our hiring network.

The first title to target

A good first move is a role where your services depth is the entry ticket: backend or platform engineer on a team shipping agent features, solutions engineer on an AI infrastructure product, or a forward deployed role at a company selling into enterprises. The FDE hub describes the role, and the skill check will show which of your current resume lines already point at it.