Backend Engineer: salary, job description & interviews
Backend Engineer roles in Germany pay a median base salary of €62,000 a year, with the middle half of salaries between €52,000 and €78,000.
At a glance
- Median salary€62,000
- Time to fill50–80 days
- Experience3–7 years
Backend Engineer salary in Germany
Base salary, gross per year
- 25th percentile
- €52,000
- Median
- €62,000
- 75th percentile
- €78,000
| Level | 25th percentile | Median | 75th percentile |
|---|---|---|---|
| Entry-level | €42,000 | €48,000 | €55,000 |
| Mid-level | €52,000 | €62,000 | €78,000 |
| Senior | €72,000 | €85,000 | €105,000 |
For reference: the statutory minimum wage in Germany has stood at €13.90 gross per hour since January 1, 2026 — roughly €2,410 gross a month for a full-time role at 40 hours/week. (BMAS: Mindestlohn steigt zum 1. Januar 2026 auf 13,90 Euro)
Gross fixed salary per year for a mid-level Backend Engineer (3 to 7 years of experience) at a German SMB or Mittelstand company. Berlin, Munich and Hamburg in the SaaS and scale-up scene pull upward (75 to 95 k€); classic Mittelstand and regional locations trend downward (48 to 58 k€). A modern stack (Go, Python, Java with Kubernetes, Postgres) pulls up; a legacy stack (classic PHP, older Java EE monoliths) pulls down. Distributed systems, high load and hard latency requirements pull noticeably upward. Engineering roles in Germany usually have no variable compensation component; scale-ups add VSOP or ESOP on top.
Sources: Stepstone Gehaltsdaten Backend-Entwickler:in Deutschland 2026; Stepstone Gehaltsreport 2026; Honeypot State of Software Engineering Germany 2025; Destatis Verdiensterhebung (April 2025), Berufsgruppe 43 IKT-Berufe
How to hire a Backend Engineer for your SMB
Before you write the job posting, settle three questions. They decide which profile you are actually looking for and help you avoid the most common mistakes in backend hiring at a German SMB.
Question 1: A backend specialist, full-stack with a backend lean, or DevOps? Backend Engineers focus on the API, the database, scalability, security and production operations of the server side. If your product is simple CRUD logic with a manageable UI and your team is under 5 engineers, full-stack with a backend lean is often the right choice. If, on the other hand, you have distributed systems, high load, hard latency requirements or complex data models, backend specialization is the right answer. DevOps or SRE as a dedicated role becomes worthwhile only from around 8 to 12 Backend Engineers; before that the backend team carries the operational responsibility too.
Question 2: Which stack do you have and how mature is it? A good Backend Engineer on Go and Postgres is not immediately productive on Java with Oracle; they need 3 to 6 weeks of onboarding. For a mid-level profile, stack fit often matters more than absolute seniority. Put your stack prominently in the posting (language, web framework, ORM or query builder, relational DB, queue, cache, orchestration); that filters out poorly matched profiles automatically. If your stack counts as legacy (classic PHP, older Java EE monoliths), communicate it openly and look specifically for profiles who enjoy codebase modernization, instead of importing disappointed job-changers.
Question 3: Which system complexity do you serve today, and which in 18 months? A mid-level backend profile in a service with 100 requests per second and one database makes different decisions daily than in a system with 5,000 requests per second, several services, event streams and multi-region consistency. The ideal profile differs: pragmatism and product proximity in the first case, deep experience with distributed systems and observability in the second. Clarify this dimension already in the posting and align the system-design exercise with your real load, not a hypothetical scale.
If all three answers point to a full-time Backend Engineer (and not a full-stack or DevOps profile), see the ready-to-use template in the job description section below.
Backend Engineer job description template
[Company name], a B2B SMB in [industry] based in [city], [X] employees, [X] M€ ARR, is looking for a Backend Engineer to strengthen a tech team of [X] engineers.
Your role
You design, build and operate the server side of our application (APIs, data models, asynchronous processing, integrations with third-party systems), independently on familiar topics and in alignment on structuring decisions. You share responsibility for production operations (observability, on-call or standby depending on the organization). You report to the [Tech Lead / CTO / technical management].
Key responsibilities
- Deliver backend features end to end: understanding the product need, data model, API design, implementation, tests, deployment, support in production.
- Contribute to architecture decisions in your area of responsibility (data model, library choice, queue strategy, consistency guarantees, service boundaries).
- Ensure code quality: review colleagues' PRs, apply the conventions, refactor in passing where it makes sense.
- Contribute to resolving production incidents (on-call or standby depending on the organization), co-write post-mortems, update runbooks.
- Document important technical decisions and non-trivial zones of complexity (ADR or equivalent).
- Collaborate with frontend, SRE and DBA profiles, PM, design and management on product briefs; constructively challenge infeasible or counterproductive requirements.
Profile
- Essential: [3 to 7] years of professional experience in backend development; solid command of at least one modern backend language (Go, Python, Java, Kotlin, Ruby, Node or comparable); experience with relational databases (Postgres, MySQL or comparable), API design and production operations (deployment, monitoring, incident handling).
- Desired: familiarity with our stack [to be completed]; experience with asynchronous processing (queues, event streams), distributed systems or multi-tenant architectures; experience at an SMB or startup (high autonomy); open-source contributions or visible side projects.
- Disqualifying: no experience with independent production operations; refusal of on-call or standby despite an operational requirement; blanket rejection of modern tooling (observability, CI/CD, containers).
What we offer
- Gross annual compensation: [52 to 78] k€ depending on experience. No structural variable; possibly VSOP or ESOP depending on the company's stage.
- Model: [full-time, hybrid 2 to 3 days / week on-site, based in [city] / remote-friendly].
- Benefits: [company pension, bike leasing, employee equity, vacation days, home-office policy, hardware budget, professional development budget].
- Stack: [to be completed: language and framework, DB, queue, cache, infra, CI/CD, monitoring].
Hiring for this role? Job Studio turns the template into a finished job ad, with a suggested salary range and the application form built in.
Backend Engineer interview questions
15 structured questions, grouped by type. Each names the trait it scores; open it to see what a strong answer shows.
Behavioral 3
Describe an API you designed and brought to production. What decisions did you make on versioning, authentication and error format?
API and system designWhat a strong answer surfaces
Deliberate decisions instead of defaults: an explicit versioning strategy (URL, header, no versioning with reasons), an auth model suited to the context (session, JWT, OAuth, mTLS), a consistent error format across all endpoints. Bonus: the candidate names decisions they would make differently today. Someone who names REST with JSON Web Token without reflection has rarely weighed it seriously.
Tell me about a production incident you led the resolution of. What was the symptom, how did you diagnose it, and how long did it take?
Debugging and observabilityWhat a strong answer surfaces
A structured debug method: reproduction, logs, metrics, hypotheses validated by experiment. Honesty about duration (a real production incident is rarely closed in under 30 min). Bonus: the candidate names the root cause and the systemic fix (post-mortem, runbook, new alert), not just the hotfix. Answers like I restarted the service without diagnosis point to weak investigation skills.
Describe a database migration you ran in production. How did you handle downtime, rollback and data consistency?
Database fundamentalsWhat a strong answer surfaces
An incremental approach: online migration with dual writes or backfill, an explicit rollback plan, consistency validation before the cut-over. Bonus: the candidate names a case where the migration took longer than planned and what they learned. Someone who describes a big-bang migration with no rollback shows risk blindness.
Situational 3
Since the last deploy your API returns a 500 on 1 % of requests. The logs show no obvious error. How do you proceed over the next 30 minutes?
Debugging and observabilityWhat a strong answer surfaces
A structured method: (1) keep the rollback option open, (2) temporarily raise the log level on the affected endpoints, (3) correlate with metrics (latency, payload size, source), (4) identify the pattern (time of day, request type, a specific user or tenant). Someone who jumps straight to it's probably the DB without investigating has a bias. Bonus: explicitly mentions starting a post-mortem document in parallel.
A product manager requests a new endpoint that, in your view, would scan a 200-million-row table unchanged. How do you react?
Pragmatism and prioritizationWhat a strong answer surfaces
Clarifying the underlying business need before discussing the solution (the use case can often be solved with aggregated data or an index). Offering options: a suitable index, a materialized view, an async job with cache, a data-model change. Answers like I'll just build it, we'll optimize later when the DB gets slow point to a lack of foresight.
You join a team with significant backend debt: no tests on the business logic, manual deployments, barely any monitoring, a monolithic database. What is your 30-day plan?
Pragmatism and prioritizationWhat a strong answer surfaces
Diagnosis first: not trying to fix everything at once. Prioritization by risk and impact (typically: monitoring and alerts first for visibility, then tests for the two or three most critical business rules, then deployment automation, database refactor last). Alignment with the team and tech lead before each move. Someone who dives straight into a microservices migration shows a lack of pragmatism.
Case 3
Design: we want to add a webhook system for third parties to our application (example: a customer event is delivered to an external customer URL). How do you design it?
API and system designWhat a strong answer surfaces
Clarification before proposing (expected volume, latency requirement, retry behavior, security model). A coherent architecture: an async queue, idempotent delivery with an event ID, retry with exponential backoff, a dead-letter queue, a signed payload (HMAC or similar), endpoint verification. Bonus: explicit handling of slow or failed receivers (circuit breaker, per-receiver throttling). Someone who jumps straight into code without clarifying shows a design weakness.
Design: we are building a counter system that handles several thousand increments per second (example: a view counter on popular articles). How do you design it?
API and system designWhat a strong answer surfaces
Recognizing that a naive UPDATE per request does not scale: lock contention, connection limits, WAL pressure. Solution space: an in-memory counter with periodic flush, a sharded counter, a Redis increment with a persistence strategy, an event stream with downstream aggregation. Bonus: a discussion of consistency guarantees (eventually consistent vs. strict) and failover behavior. Someone who just uses a Postgres table has not thought through load and consistency.
Debug: in your production environment the P99 latency of a critical endpoint has been rising slowly for 48 hours, with no deploy. How do you proceed?
Debugging and observabilityWhat a strong answer surfaces
A structured method: (1) correlate with external factors (traffic increase, data growth, third-party latency), (2) check slow-query logs and DB statistics (table size, index usage, vacuum status on Postgres), (3) trace a slow request from edge to DB, (4) rank hypotheses (index bloat, a risen cache-miss rate, an exhausted connection pool). Bonus: recognizing that a slow rise usually points to data growth or index degradation, not a sudden bug.
Technical 3
Explain the difference between the isolation levels Read Committed, Repeatable Read and Serializable in a relational database. When do you use which level?
Database fundamentalsWhat a strong answer surfaces
A solid understanding of the anomalies (dirty read, non-repeatable read, phantom read, write skew). Read Committed as the pragmatic default in Postgres, Repeatable Read for consistent reports, Serializable for rarely used but critical paths (accounting, inventory). Bonus: mentioning the performance cost of Serializable and SELECT FOR UPDATE as a middle ground. Someone who cannot separate the levels builds race conditions into production.
What do you log, measure and alert on for a new backend service before it goes to production? Which tools do you use?
Debugging and observabilityWhat a strong answer surfaces
A clear separation of logs (structured, with a trace ID), metrics (RED or USE method: rate, errors, duration; or utilization, saturation, errors) and distributed tracing. A concrete tool choice with reasoning (Prometheus plus Grafana, OpenTelemetry, Datadog, Sentry). Alerts only on actionable signals, not on every anomaly. Bonus: explicit SLOs with an error budget. Someone who just says log everything shows a lack of experience with high-load services.
Which security checks do you run on a backend service before it handles a third-party token or user data? Which classes of attack do you keep in mind specifically?
SecurityWhat a strong answer surfaces
A clear list: injection (SQL, OS, template), auth and session weaknesses, authorization bypass at the tenant level, insecure secret handling (plaintext in the repo, in logs, in tracing), insecure deserialization, SSRF from backend calls, open redirect. Concrete measures: parameterized queries, a secret manager, output encoding, authorization checks on every request, logging without sensitive data. Bonus: an OWASP Top 10 reference with concrete application in their own stack.
Values 3
How do you take a critical code review of code you were convinced was good (example: your API design or your data model is challenged)?
CoachabilityWhat a strong answer surfaces
Openness: the ability to separate code from personal ego. Bonus: the candidate names a case where a review actually changed their mind (a different data model, a different API shape). Someone who describes having explained their logic to the reviewer instead of listening shows a coachability weakness; at an SMB with a small backend team this is a hard no-go signal.
What role do you play in passing technical knowledge to junior profiles or new team members, especially in backend where production mistakes are expensive?
Mentoring and knowledge sharingWhat a strong answer surfaces
An active mentoring posture: pair programming on critical paths, pedagogical reviews with reasoning (not just an ok merge), documented architecture decisions (ADR), passing on good practices (idempotency, backoff, safe deploys). Someone who says I help when asked, without more concrete detail, shows a passive posture. At an SMB with a small backend team, the ability to pass on knowledge is decisive for the team's sustainability.
How do you work with frontend profiles, SRE or DBA? Describe a situation where you pushed back on a proposal.
Cross-functional teamworkWhat a strong answer surfaces
A partnership posture: constructive challenging based on feasibility, complexity or operational consequences, with alternative proposals. Bonus: the candidate names a case where they accepted the original proposal after exchange (no systematic opposition). Someone who describes frontend, SRE or DBA as people who don't understand backend shows a weakness in cross-functional teamwork.
Salary and hiring by level
The same role at each level: what it pays, how much experience to expect, and how long the search usually takes.
Junior Backend Engineer
- Base salary, gross per year
- €48,000€42,000 – €55,000
- Experience
- 0–2 years
- Time to fill
- 35–60 days
Backend Engineer (Mid-level)
- Base salary, gross per year
- €62,000€52,000 – €78,000
- Experience
- 3–7 years
- Time to fill
- 50–80 days
Senior Backend Engineer
- Base salary, gross per year
- €85,000€72,000 – €105,000
- Experience
- 7–12 years
- Time to fill
- 60–95 days
Backend Engineer salary by country
The same role at the same level in each market we cover, with every figure taken from that market's own sources.
| Country | Low end | Typical | High end |
|---|---|---|---|
| GermanyThis page | €52,000 | €62,000 | €78,000 |
| FranceFrançais | €45,000 | €55,000 | €70,000 |
| SpainEspañol | €40,000 | €50,000 | €62,000 |
| NetherlandsNederlands | €53,160 | €63,060 | €72,960 |
| ItalyItalianoItalia · sondaggio Crebs · Back-end Developer Mid-weight, anni non indicati | €35,000 | — | €45,000 |
Sources
- France (accessed May 2026): APEC, Baromètre 2025 de la rémunération des cadres tech · INSEE, DADS 2024 (PCS 388a, Ingénieurs informatiques) · Talent.io, Étude rémunération tech France 2025
- Spain (accessed May 2026): INE, Encuesta de Estructura Salarial 2024 (CNO 271, Analistas y diseñadores de software) · InfoJobs, Estado del Mercado Laboral en España 2025 · Honeypot State of Software Engineering Spain 2025
- Netherlands (accessed August 2026): Intermediair — salaris backend developer
- Italy (accessed October 2026): Crebs, Guida Stipendi 2026: Media stipendi Back-end Developer in Italia (livelli Junior, Mid-weight e Senior; metodo del sondaggio) · Hays Italia Salary Guide 2026, Technology, Digital & New Media — Software Development, p. 70 (PDF Hays ospitato da QualEnergia; solo confronto) · Hays Italia Salary Guide 2026 (pagina ufficiale dell’edizione)
Where to source this role
LinkedIn
Recruiter Lite from €170 / month, plus €200-400 / month for Job SlotsThe most important active sourcing channel for backend profiles in Germany. Active sourcing via Recruiter Lite plus personalized InMails clearly beats plain job posts: strong Backend Engineers rarely search actively but are open to targeted outreach with a clear stack and product angle. Filter precisely on your stack (Go, Java, Python, Postgres, Kubernetes) and on experience with scaling or distributed systems before reaching out. Generic sequences sit below 5 % response; precise, technical messages reach 15 to 25 %.
XING
ProJobs from €195 / monthStill relevant for backend profiles in the classic Mittelstand outside the Berlin startup scene, especially in NRW, Bavaria and Baden-Württemberg. Particularly for Java and .NET backend profiles aged 30 to 50 with long experience in insurance, Industry 4.0 or mechanical engineering who do not actively maintain LinkedIn. In classic industrial sectors often on par with LinkedIn or better. For pure cloud-native and Go profiles a weaker signal than LinkedIn.
Honeypot, GitHub Sponsors, niche tech boards
Honeypot success fee 15 % of annual fixed salary; niche boards €200-500 per adHoneypot is the DE-specific tech reverse-recruiting platform: backend profiles create profiles with their stack and salary expectation, and companies apply to them. It works especially well for senior profiles who are not actively searching but open to structured outreach. GitHub Sponsors and visible open-source contributions add signal for senior backend profiles (language maintainers, OSS libraries). As a complement: German Tech Jobs and We Are Developers for stack-specific ads. Overall lower volume than LinkedIn and XING, but markedly higher signal quality per contact.
Evaluation playbook
The Backend Engineer role reveals itself across five evaluation stages. The system-design exercise (stage 4) is the most predictive for this role: backend profiles make daily decisions on data models, consistency guarantees and scaling strategies that are hard to reverse later.
Stage 1: CV review
Look for stack consistency (a profile on Go and Postgres does not switch back to Java and Oracle without 3 to 6 months of onboarding), stability (at least 18 to 24 months on previous roles) and production signals (services run independently, on-call experience, a visible GitHub with OSS contributions or own libraries). The degree matters less than the last 3 to 5 years of practice: a self-taught engineer with 5 years of production operations often scales better than a top-university graduate with no on-call experience.
Stage 2: Phone screen (30 min)
Three questions only: (1) Describe the latest service you brought to production independently; what was your contribution?, (2) Which technical decision did you make recently that you still doubt? (humility and reflection), (3) Why are you looking for a change now? Outcome: go/no-go in a 5-minute debrief. Avoid technical gotcha questions at this stage.
Stage 3: Technical interview (60 to 90 min)
Pair programming or code review on a bounded backend task (45 to 60 min), followed by 15 to 30 min of Q&A on data models and API design. Assess the ability to think out loud, to identify edge cases (empty input, concurrent writes, malformed input) independently, and to iterate. Avoid purely academic algorithms with no relation to daily work; favor tasks that resemble the day-to-day (add a REST or gRPC endpoint, debug a bug in a queue, refactor an N+1 query).
Stage 4: System-design exercise (60 min)
Architecture discussion on a concrete case: how would you design a system for [product-specific feature with load, consistency or latency requirements]? Assess the ability to clarify constraints before proposing (expected volume, acceptable latency, consistency guarantees, failover), to trade off simplicity against scalability, and to flag zones of uncertainty. For backend the most predictive stage: poor decisions on data model, consistency or queueing only show up after months and are expensive to repair.
Stage 5: References (structured check)
Call two references: a former tech lead or direct manager and a former backend peer. Ask both the same 4 questions: What is she/he strongest at? Where would you hire someone complementary? Would you hire them again tomorrow, why? An example of a difficult technical decision they owned (data model, migration, incident)? The fourth question delivers the real autonomy signal.
How to recognize a great hire
| Trait | Below bar | On bar | Above bar |
|---|---|---|---|
| Backend fundamentals | Stumbles over fundamentals (HTTP semantics, indexing, transactions, asynchrony, consistency). Finds solutions by trial and error with no clear mental model. Hard to place on a new stack. | Masters the current stack independently (language, web framework, ORM or query builder, relational DB, queue or cache). Can learn a new backend framework in 2 to 4 weeks. Understands the fundamentals well enough to debug deeply when needed. | A reference for the backend stack on the team and able to move to a new stack within a few weeks. Anticipates classic traps (race conditions, N+1 queries, memory leaks, connection-pool exhaustion). Builds useful, not premature, abstractions. |
| API and system design | Jumps into code without clarifying constraints. Over-architects (microservices for an MVP) or under-architects (a large monolith with no boundaries). Struggles to trade off simplicity, consistency and scalability. | Clarifies need, load and consistency requirements before coding. Pragmatic in trade-offs: no premature architecture for an uncertain future, but identifies zones where structure pays off (queueing, idempotency, indexes). Can pivot when the initial hypothesis does not hold. | Designs systems that age well: clear API contracts, well-chosen consistency guarantees, idempotent and secure operations, minimal dependencies. Recognizes their own zones of uncertainty and proposes targeted POCs. Trains the team in systemic thinking. |
| Debugging and observability | Powerless without logs or metrics. Reacts to incidents with a restart or luck. No structured diagnosis. Logs either too little or everything as noise. | Has a clear approach to incidents (reproduction, hypotheses, validation). Uses structured logs, sensible metrics and tracing. Writes a post-mortem after an incident that derives actions. | A reference on the team for observability: defines SLOs, builds alert hygiene (no pager spam), develops runbooks. Finds root causes quickly in complex distributed systems. Coaches the team in debug hygiene. |
| Database and security hygiene | Writes SQL with no awareness of indexes, locking or isolation. Stores secrets in the repo or in logs. No consistency guarantees on writes across multiple tables or services. | Understands indexing, transactions and the common isolation levels. Uses parameterized queries and a secret manager. Secures multi-part writes with transactions, idempotency keys or sagas. | Plans data models for 3 to 5 years of growth. Masters online migrations with rollback. Applies OWASP Top 10 protection consistently, checks authorization at the tenant level, instruments auth paths. A reference for safe deploys on the team. |
| Autonomy and resourcefulness | Blocks for hours on an unfamiliar topic without asking for help, or asks at every obstacle. No structured debug strategy under pressure. | Can diagnose familiar topics independently; asks for help after prior investigation (a summary of the problem, hypotheses, what has already been tried). Stays functional under incident pressure. | High resourcefulness on unfamiliar topics: reads the source code of dependencies, instruments the runtime, isolates root causes, builds new tools when needed. Documents the findings for the team. |
| Communication and teamwork | Explains their own backend decisions poorly to non-technical people. Defensive in reviews. Works in a silo, shares little context. Systematic opposition to frontend, SRE or DBA. | Can explain their decisions to a PM or management in clear language. Takes reviews constructively. Shares context in team reviews and 1:1s, documents architecture decisions. | A bridge between backend and other functions. Facilitates technical debriefs, makes trade-offs understandable, negotiates timelines transparently. A reference on the team for cross-functional communication. |
Common hiring mistakes for this role
Hiring on corporate pedigree instead of production operations
A top graduate from a prestigious school with 2 years at a DAX corporation or a Big Tech subsidiary is not automatically more productive than a self-taught engineer with 5 years of on-call experience at a startup or SMB. Large organizations give their backend profiles clear specs, dedicated SRE teams and solid tooling; at an SMB this scaffolding is usually missing, and the lack of autonomy in production operations becomes a burden. Weight the system-design interview and incident experience more heavily than the pedigree on the CV.
Overvaluing algorithmic fundamentals for a product role
A Backend Engineer at an SMB almost never has to optimize a graph algorithm or reimplement a B-tree; but they have to design data models daily, prevent N+1 queries and ensure consistency under load. LeetCode-style tasks filter for academic profiles at the expense of operational ones. Favor tasks that resemble the day-to-day: design an endpoint, analyze a slow query, debug a bug in a queue. Pure LeetCode-Hard filters are counterproductive at an SMB.
Requiring multi-day take-home assignments
A take-home assignment of 8 or more hours actually takes 24 hours (with emotional investment), demotivates the best profiles (who have other options in parallel) and delivers no better signal than a well-constructed 2 to 3-hour task. You want to measure the quality of reasoning, not completeness. Cap the expected time explicitly and accept incomplete but well-reasoned solutions.
Treating observability as nice-to-have
A backend profile with no experience in logs, metrics, tracing and alert hygiene can deliver working code but is powerless in any non-trivial incident. At an SMB with a small team, every Backend Engineer shares responsibility for production operations. Test observability explicitly (which tools, which SLOs, which alerts, what to log, what to trace) and treat weak answers as a risk, not a detail.
Testing security and data-model decisions too late
Poor security and data-model decisions do not show up in stage 3, but only in stage 4 (system design) and in references. Whoever addresses the auth strategy, the multi-tenant model or the migration strategy only after the offer buys long-term risks that are expensive to repair. Ask at least one security question and one data-model question explicitly in the interview, not as a bonus.