💼 “Tell Me About the Outage.” — A Backend Engineering Job Interview in
German

I am sitting in a technical interview for a backend engineering role.
The conversation starts comfortably: what have I built, which languages
have I used, and how do I work with other engineers? Then the interviewer
changes direction. Instead of asking me to recite definitions, she gives me
a production scenario: mobile listeners are reporting playback failures
while the web client appears healthy.

This is where a strong engineering interview becomes interesting. The
interviewer is not only testing whether I recognize technologies. She wants
to see how I reason when information is incomplete. I need to ask useful
questions, distinguish evidence from assumptions, identify system
boundaries, explain trade-offs, and communicate a safe next step.

Experience is more useful when it becomes a story

If I say that I have worked with backend services, cloud infrastructure,
containers, databases, or Go, the interviewer can easily ask what that
experience looked like in practice. A convincing answer therefore connects
technology to responsibility. What did the service do? Who consumed its
API? What failed? How did I know? What decision did I make? What changed
afterward?

This does not mean every answer needs to be dramatic. A small example
can demonstrate strong engineering judgment if I explain it clearly. I
might describe an API change that needed backward compatibility because
mobile clients updated more slowly than the server. I might explain why a
database query became expensive under traffic, or how an infrastructure
change was reviewed and deployed safely.

Debugging questions test structure, not clairvoyance

Suppose the interviewer says: “Playback is failing on Android, but the
web client still works. What do you do?” I should resist the temptation to
announce a root cause immediately. I do not have enough information. A
better response establishes scope. Which app versions are affected? Did the
problem begin after a deployment? Is it regional? Are API errors
increasing? Do traces show a difference between successful and failed
requests?

Good debugging is a sequence of narrowing questions. I form hypotheses,
but I also say what evidence would support or weaken them. If an API
returns a successful status code while playback still fails, I investigate
the response contract and downstream behavior rather than declaring the
backend healthy.

Cross-platform APIs create long-lived contracts

An API used by web, Android, and iOS clients cannot assume that every
consumer changes at the same moment. A server may deploy several times
while a mobile release is still waiting for users to update. That makes
compatibility an operational concern, not merely an interface-design
preference.

In an interview, I would explain how I think about additive changes,
versioning, feature flags, migration windows, contract testing, and
observability by client version. I would also acknowledge trade-offs.
Permanent backward compatibility can create complexity, while aggressive
evolution can break real users. The engineering task is to manage that
tension deliberately.

Scale questions are usually questions about bottlenecks

If the interviewer asks how I would scale a service to a very large
audience, “add more servers” is incomplete. I want to understand the
workload. Is it read-heavy or write-heavy? Where is state stored? Which
dependencies dominate latency? Can requests be cached? Are retries
multiplying traffic? Does one database query become disproportionately
expensive as data grows?

I would discuss horizontal scaling when appropriate, but also data
access, service boundaries, queues, caches, timeouts, load shedding, and
failure isolation. The important part is showing that scale is a property
of the whole path, not one container count.

Infrastructure as code belongs in engineering reasoning

Cloud infrastructure affects application behavior. Network rules,
permissions, autoscaling, managed databases, container settings, and
regional configuration can all influence reliability. Describing
infrastructure as code in an interview is therefore more useful when I
connect it to reproducibility, reviewability, controlled change, and
recovery.

I might explain that application and infrastructure changes should both
be visible during incident analysis. If two changes occur near the same
time, I should not assume the application commit is automatically
responsible.

On-call questions reveal judgment under pressure

An interviewer may ask whether I would roll back immediately during an
incident. There is rarely a universal answer. I want to know the impact,
confidence in the suspected change, rollback safety, and whether a smaller
mitigation exists. Disabling a feature may be safer than reversing an
unrelated database migration. A rollback may be the fastest responsible
option if a recent compatible release is known to be healthy.

The key is to communicate priorities: protect users, avoid making the
incident worse, preserve evidence where practical, and continue root-cause
analysis after service is restored.

Collaboration is part of backend engineering

A backend engineer works through interfaces with other people as well as
other systems. If mobile engineers report that an API contract changed
unexpectedly, arguing about which team “owns” the bug is less useful than
establishing what each side expected and what the contract actually
guaranteed.

Code review works similarly. I want reviews to catch correctness,
maintainability, operability, and unclear assumptions without turning into
personal contests. Humility matters because distributed systems regularly
prove confident people wrong.

AI-assisted development needs the same engineering controls

If the interview turns to AI-assisted development tools, I would neither
dismiss them nor treat them as autonomous engineering judgment. They can
accelerate exploration, boilerplate, test generation, documentation, and
code review preparation. They can also produce plausible but incorrect code
or miss constraints that exist only in production context.

I would use such tools inside a verification process: understand the
proposed change, run tests, review security and failure behavior, check
integration assumptions, and keep a human accountable for the result.

What a strong interview answer demonstrates

By the end of a senior backend interview, the interviewer is often
evaluating more than syntax. Can I move from ambiguity to a testable
hypothesis? Can I design an API for several consumers? Can I reason about
databases, cloud infrastructure, containers, and distributed failure? Can I
make a safe on-call decision? Can I disagree constructively in an
architecture discussion? Can I explain why I chose one trade-off instead of
another?

The German quiz below develops exactly that progression. Early levels
focus on introducing experience and answering simple technical questions.
Intermediate levels require explanations of incidents and design choices.
Advanced levels turn the interview into a realistic engineering discussion
in which I must qualify claims, compare alternatives, defend decisions with
evidence, and acknowledge uncertainty without becoming vague.