TL;DR: For Lambda-style functions, reconsider when you have steady high throughput (cost per request stops being competitive), when you need predictable low latency (cold starts), when the work runs long or needs persistent connections, and when you are already paying for a container platform. Cold start is provisioning plus runtime initialisation plus your own initialisation, and the last part is usually the one you control.
How to approach it
Take the position the question asks for and support it with the execution model. An answer that lists benefits has not engaged with the question.
A strong answer
This answer concerns Lambda-style functions; serverless also includes managed container and data services with different execution models. Functions reduce infrastructure management and charge for execution, which is excellent for spiky, low-volume, event-driven work. The cases where it is the wrong tool follow from the same properties.
Steady high throughput. The pricing model is a premium per unit of compute in exchange for scaling to zero. If your traffic never goes to zero, you are paying the premium permanently. There is a crossover point where a reserved container fleet is cheaper, and for a service at constant load it arrives sooner than people expect. Work it rather than asserting it, with illustrative prices.
Take a 512 MB function running 200ms per invocation. Each invocation bills 0.5 × 0.2 = 0.1 GB-seconds, and at $0.0000167 per GB-second plus $0.20 per million requests that is about 0.1 × 0.0000167 + 0.0000002 ≈ $0.00000187 per call. Sustained 100 requests a second is 100 × 86,400 × 30 ≈ 259 million invocations a month, so roughly 259,000,000 × 0.00000187 ≈ $484.
Now the always-on equivalent. By Little's law, 100 requests a second at 200ms each is 100 × 0.2 = 20 concurrent requests, so a fleet of four small two-vCPU instances covers it with headroom. At an illustrative $0.08 an hour that is 4 × 0.08 × 730 ≈ $233 a month, against $484.
So the crossover sits below this load, at roughly 233 / 0.00000187 ≈ 125 million invocations a month, which is about 48 requests a second sustained. Under 50 requests a second the functions are cheaper and you keep the operational saving; over it you are paying a premium for scaling you no longer use.
Two caveats on that number, because it moves a lot. It scales directly with configured memory and duration, so a 2 GB function at one second shifts the crossover down by a factor of twenty, and the container side ignores the operational cost of running a fleet, which is the thing you were buying in the first place. Recompute it with your own figures; the point is that the crossover exists and is lower than intuition suggests.
Predictable low latency. A cold start has three parts. The provider provisions an execution environment, the language runtime initialises, and your code runs its own initialisation before handling the first request. The provider's part is largely out of your hands and is small for lightweight runtimes and much larger for a JVM. Your part is not: a function that opens database connections, loads configuration and builds a dependency graph at startup can turn a 200ms cold start into two seconds. If your p99 requirement is tight and your traffic is intermittent enough that instances get recycled, you will miss it. Provisioned concurrency reduces it for the configured capacity, while spillover and environment resets still need testing, which is also the point at which you are paying for idle capacity and have given up the main advantage.
Long-running or stateful work. There is an execution time limit, so anything longer must be decomposed or moved. Persistent connections are the subtler problem: each concurrent execution is a separate environment, so a thousand concurrent functions want a thousand database connections, and a traditional relational database will refuse long before that. This is a real and common failure, and the mitigations (a connection proxy, or a data store designed for it) are extra architecture you did not have when you started.
Where you already run a container platform. If a Kubernetes cluster exists and is paid for, adding a second deployment model has an organisational cost: two sets of tooling, two observability stories, two security models. That is a legitimate reason to say no to an otherwise reasonable fit.
The framing worth offering: serverless is excellent at the edges of a system (event handlers, glue, scheduled jobs, traffic that is bursty) and questionable at the core of a high-traffic service. Most mature architectures use both rather than choosing.
Lambda startup options documents the provider or model boundaries used here.
What interviewers probe next
"How would you reduce a cold start?" Smaller deployment package, a lighter runtime, lazy initialisation so only what the first request needs is built, and moving connection setup out of the handler path. Evaluate provisioned concurrency or SnapStart where the runtime and configuration support it, including restore behavior and pricing.
"What is the vendor lock-in argument?" Real but often overstated for the compute itself. The lock-in is in the surrounding managed services and the event wiring, not in the function body.
"How do you test it locally?" Emulators approximate it and diverge on IAM and event shapes. Deploy to a real environment early, because the differences that matter are the ones the emulator does not model.
Common mistakes
Selling serverless when asked to argue against it.
Describing cold start as one number rather than three components, only one of which you control.
Missing the connection exhaustion problem, which is the failure most teams actually hit.