Delivery Hero || SDE 2 java || Germany
xonomous
513
Interview

Recently interviewed with Delivery Hero for a backend engineering role. Sharing my overall experience and the interview process.

Interview 1 — HR Introductory Round

This was mostly a discussion around:

  • My previous work experience
  • Current projects
  • Why I wanted to relocate
  • Compensation expectations

Pretty straightforward and conversational round.

Interview 2 — Coding + Backend Fundamentals

This round focused on coding and general backend/system knowledge.

Coding Question

  • Binary Search based problem

SQL / PostgreSQL

Questions around:

  • HAVING clause
  • Range queries
  • Locks
  • Basic PostgreSQL concepts

Kubernetes

I was transparent here. I mentioned that:

  • I understand the ecosystem and high-level workflow
  • But I haven’t worked on production-grade Kubernetes systems directly

Kafka

Questions around:

  • Where I used Kafka
  • Why Kafka
  • Basic architecture and concepts

Java

Covered:

  • Functional interfaces
  • Abstract classes
  • OOP concepts
  • SOLID principles

Interview 3 — Staff Engineer + Hiring Manager

This round was heavily focused on:

  • Behavioral questions
  • Past experiences
  • Decision-making in projects
  • Architectural choices

Technical discussions included:

  • Kafka partitioning strategy
  • Key design in Kafka
  • PostgreSQL vs MySQL
  • Detailed walkthrough of an AI/agent-based system I had built

This was probably the most balanced and interesting round.

Interview 4 — Bar Raiser Round

This round had 2 parts.

1. Coding

A simple stream-processing style problem:

  • Data was continuously coming in
  • Needed to process/handle the stream efficiently

Nothing too difficult here.

2. System Design / General Implementation Discussion

This discussion was honestly one of the funniest interview conversations I’ve had.

The discussion started with:

Why did you use Kafka in your system?

I explained:

  • High throughput requirements
  • Analytical workloads
  • Okay with slight delays
  • Wanted cost-efficient scaling instead of aggressively increasing consumers/pods

Then came:

Why not just use HTTP calls?

I explained:

  • Under heavy load, HTTP-based synchronous communication would require scaling pods aggressively
  • Otherwise requests pile up and systems become unstable
  • Kafka gives buffering and asynchronous processing advantages

The response:

You are overcomplicating the system. We also use HTTP calls internally.

At this point I had serious doubts, but continued.

Then we discussed alternatives:

  • SSE
  • Other communication approaches

Eventually I said I couldn’t think of a better alternative for that use case and asked if he had something specific in mind.

The answer:

Store the data in the database first and process it later with Kafka.

I asked the extra things we have to do:

  • Introduced data polling
  • Cleanup jobs
  • Additional DB load
  • More operational complexity

But the argument was:

It’s simpler to implement.

Then feedback started coming toward my design choices:

  • You overcomplicate systems.
  • Why use Protobuf with Kafka?
  • Why optimize so much?

I explained:

  • We were handling ~1M daily messages
  • Protobuf reduced payload size
  • Better network efficiency
  • Faster serialization/deserialization
  • Lower infra cost

Then I casually asked :

Why not replace internal HTTPS communication with gRPC in your system ? It would reduce networking cost and will be faster.

The response:

I don’t care about cost. I don’t care about speed.🤯

(Those were his exact words not exaggerating)

That was the exact moment I knew I was probably rejected 😂

The final argument became:

  • Technologies like gRPC/Protobuf/Kafka increase learning overhead for developers and from my 15 years of work experince we should keep system simple .

And honestly my immediate thought was:

Isn’t staying updated part of being an engineer?

I replied politely:

I come from an environment where we focus heavily on building systems that are cost-efficient and fast. I think your experience may come from places where simplicity is prioritized, even if it costs more in terms of infrastructure or performance. Maybe with the kind of experience you have, I’ll also learn when simplicity is the better trade-off.

Final Thoughts

Overall:

  • All interviewers were polite and respectful
  • HR behavior was genuinely good
  • The process itself was smooth
  • Questioning the way their engineers make architectural choices. At the scale they operate, even tiny optimizations could save millions — maybe worth reviewing the architecture before exploring new verticals 😂. If someone from there reads this, feel free to take the idea, grab the credit, and become the hero at Delivery Hero.

I later confirmed with HR that the system-design discussion became the rejection reason, which honestly made me laugh because I already knew after that conversation.

My takeaway for future candidates:

Sometimes the “best engineering solution” is not what interviewers are looking for.

Giving simpler, practical, low-resistance solutions may actually improve your selection chances more than deeply optimized architectures.

That said, the experience was definitely memorable 😄

Comments (2)