Extended Interview Bank 1: FDE and Solution Scenarios

1. Convert the target to minutes per month.
2. Ask what happens to a user during downtime and when the pilot is used.
3. Multiply the availability of every component that must be up.
4. Offer a smaller promise, a degraded mode or a measurement period.
5. Write down what counts as downtime and how it is measured.

Strong answer sketch.

Ninety-nine point nine percent of a thirty-day month is 43 minutes of allowed downtime. If our service is 99.9% and the model provider is 99.5%, both must be up, so we multiply: about 99.4%, or roughly 4.3 hours down. I cannot promise 99.9% on that chain, and I would not try. I would offer a pilot target in business hours only, with a fallback to the search page when the model is down, and I would measure for four weeks before we write a number into a contract. The worked example below has the arithmetic.

One common mistake. Accepting the number because the cloud platform advertises a high one, without multiplying in the model provider.

One follow-up. The customer says pilot downtime outside business hours is fine. How does your answer change?

Q4. The engagement ends next week. How do you hand the system over?

What it assesses. Whether you leave the customer able to run, change and trust the system without you.

Answer framework.

1. Name the owner for each part: service, data, evaluation set, access.
2. Hand over the things that decay: runbook, configuration list, evaluation set and how to re-run it.
3. Do one change together, led by the customer's engineer.
4. List what you did not finish and the risks that remain.
5. Agree a review date and who calls it.

Strong answer sketch.

A handover is a test: could their engineer ship a change next month without me? So I would not only write documents. I would pair on one real change, such as adding a document to the index and re-running the question set, with their engineer driving. I would hand over the runbook, the list of settings and secrets with who rotates them, and the evaluation questions with the last results. I would also hand over the known problems: the three questions we still miss, and the data feed that breaks when the supplier changes a column. Last, I would book a thirty-minute review in a month.

One common mistake. Handing over code and a slide deck, but not the evaluation set, so nobody can tell if a change made things worse.

One follow-up. Their only engineer who understood it has just left. What do you do?

Q5. The customer asks, "Should we fine-tune a model on our documents?" How do you answer?

What it assesses. Whether you match the fix to the problem: missing knowledge, wrong behaviour, wrong format or too much cost.

Answer framework.

1. Ask what is failing: missing facts, wrong tone or format, or something else.
2. Match the fix to the failure.
3. Try the cheapest fix first and measure it on the customer's questions.
4. Say what would make you change the plan.
5. Point out that documents change, and a trained model does not follow them.

Strong answer sketch.

I would ask what the wrong answers look like. If they are wrong because the specification is missing, that is a knowledge problem, and retrieval with citations solves it while keeping the documents editable. If the model has the facts and still writes in a format we cannot use, I would fix the prompt and the schema first. I would only suggest training after a measured gap on their questions, and I would tell them it adds a maintenance job: retrain when the data changes.

One common mistake. Answering "yes, fine-tuning" or "no" without asking what is failing.

One follow-up. The customer's legal team will not allow documents to leave the building. How does that change the options?

Q6. One customer wants a feature that the product team has not planned. How do you handle it?

What it assesses. Whether you separate a one-off request from a pattern, and whether you carry customer evidence back to the product team without making promises you cannot keep.

Answer framework.

1. Ask what outcome the customer needs; the feature is one way to get it.
2. Check whether a configuration or a small adapter meets the need.
3. Count how many customers or deals raise the same need.
4. Bring the product team evidence: the need, the count, the workaround and its cost.
5. Tell the customer what you know, not what you hope.

Strong answer sketch.

I would ask what they are trying to do, because "an export button" is often "my finance team needs last month's usage by cost centre". If a small adapter on our side gets them there, I would build it as a workaround and label it as one. Then I would count: is this the third customer this quarter or the first? I would give the product team one page with the need, the count and what the workaround costs us to maintain. To the customer I would say what is planned, what is not, and what we are doing meanwhile, without a date I do not control.

One common mistake. Promising a delivery date on behalf of the product team.

One follow-up. The workaround is now used by five customers. Who owns it?

Worked example

Assumptions: a 30-day month has 43,200 minutes; the availability of each component is illustrative; both components must be up for a request to succeed.

Predict first. If the model provider alone is 99.5%, what is the best availability your service can reach for the whole chain, however good your own code is?

For the chain in Q3: 0.999 x 0.995 = 0.994005, or about 99.4%. Expected downtime is 43,200 x (1 - 0.994005) = 258.98 minutes, about 259 minutes or 4.3 hours. Against an allowance of 43.2 minutes, that is about 6 times too much.

Practice task

Run the loop in Figure 1 on all six questions with a friend or a recorder.

1. Answer each question in four minutes; stop at four minutes.
2. Count your clarifying questions in the first minute. Aim for two that would change your design.
3. Compare with the sketch, and write one sentence on what you left out.
4. Redo the weakest answer a day later without notes.

Explain it back. In three sentences, explain to a customer's operations lead why a 99.9% target is not the same as "the AI assistant works 99.9% of the time". A good explanation names the dependencies, gives the allowed minutes and offers a fallback.

Exercise

Write your own card: a scenario you could be asked about your own field, such as a customer who wants real-time answers from a system that is updated weekly. Write the assessment, the framework and a sketch with at least one calculation.

Acceptance criteria: the first framework step is a question to the customer; the sketch has one number with its arithmetic shown; the common mistake is something you have seen or could see. Done when a friend can score your sketch using only your framework.

Common mistakes

• Memorising a sketch. The interviewer changes one fact, and the memorised answer no longer fits.
• Opening with a solution instead of a question.
• Giving one option and calling it a recommendation.
• Quoting a percentage without turning it into minutes or counts.
• Promising dates, features or availability that depend on someone else.
• Skipping the "what would change my mind" sentence, which is the sign of real judgement.

Knowledge check

You can now

• Structure a four-minute scenario answer that starts with a question.
• Convert an availability target into minutes and combine two components.
• Compare integration options for a system with no API.
• Match a model-customisation choice to a measured failure.
• Carry a customer request to the product team as evidence.

Further reading

• RFC 9110: HTTP Semantics: section 15.6.4 defines the 503 status for a server that is currently unable to handle a request, and says the server may send a Retry-After header; use it when you design the fallback in Q3.
• The Twelve-Factor App: Config, for keeping configuration and credentials out of code, which Q4's handover list depends on.
• On this site: Estimation and total cost of ownership and Reliability and scaling.

Last verified: 2026-11-02

Next

Positioning enterprise integration experience