Backend Engineer
Job description, salary, sourcing, 15 interview questions and a 30/60/90 plan to hire a Backend Engineer in a German SMB.
Compiled by the Join team from public data and our hiring experience.
Updated
At a glance
- Median salary€62,000€52,000 – €78,000
- Time to fill50–80 days
- Experience3–7 years
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), move on to the template below.
JD template
Backend Engineer (m/w/d): product and platform development at an SMB
[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].
Salary band
Base salary, gross annual
- 25th percentile
- €52,000
- Median
- €62,000
- 75th percentile
- €78,000
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
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.
Structured interview questions
BehavioralAPI and system design Describe an API you designed and brought to production. What decisions did you make on versioning, authentication and error format?
What a strong answer surfacesDeliberate 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.
BehavioralDebugging and observability 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?
What a strong answer surfacesA 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.
BehavioralDatabase fundamentals Describe a database migration you ran in production. How did you handle downtime, rollback and data consistency?
What a strong answer surfacesAn 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.
SituationalDebugging and observability 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?
What a strong answer surfacesA 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.
SituationalPragmatism and prioritization A product manager requests a new endpoint that, in your view, would scan a 200-million-row table unchanged. How do you react?
What a strong answer surfacesClarifying 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.
SituationalPragmatism and prioritization 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?
What a strong answer surfacesDiagnosis 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.
CaseAPI and system design 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?
What a strong answer surfacesClarification 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.
CaseAPI and system design 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?
What a strong answer surfacesRecognizing 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.
CaseDebugging and observability 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?
What a strong answer surfacesA 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.
TechnicalDatabase fundamentals Explain the difference between the isolation levels Read Committed, Repeatable Read and Serializable in a relational database. When do you use which level?
What a strong answer surfacesA 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.
TechnicalDebugging and observability What do you log, measure and alert on for a new backend service before it goes to production? Which tools do you use?
What a strong answer surfacesA 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.
TechnicalSecurity 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?
What a strong answer surfacesA 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.
ValuesCoachability 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)?
What a strong answer surfacesOpenness: 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.
ValuesMentoring and knowledge sharing What role do you play in passing technical knowledge to junior profiles or new team members, especially in backend where production mistakes are expensive?
What a strong answer surfacesAn 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.
ValuesCross-functional teamwork How do you work with frontend profiles, SRE or DBA? Describe a situation where you pushed back on a proposal.
What a strong answer surfacesA 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.
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. |
30 / 60 / 90 day success plan
By day 30
- Full local development environment set up, access to all backend services, and a small PR validated to production
- Reading and understanding the code of the 3 most business-critical services and the central data models
- First documented 1:1 with the tech lead on conventions, identified debt, on-call procedures and priorities
- First substantial PR (bug fix or small endpoint) reviewed and merged
By day 60
- Delivery of a complete backend feature end to end (data model, API, tests, deployment, monitoring) owned independently
- First PR review of a colleague with structured feedback, not just an approve click
- First on-call or standby period, handling at least one incident and contributing to the post-mortem
- Documentation of a recently handled service or a runbook written or updated
By day 90
- Regular delivery (1 to 2 PRs per week) with quality confirmed in review and a visible contribution to at least one architecture decision
- First technical decision owned independently on an ambiguous backend topic (data model, migration, library choice, queue strategy)
- Informal mentoring of a junior or new profile (pair programming, pedagogical reviews, onboarding support)
- Formal review with the tech lead: ramp validated, development plan on 1 to 2 priority areas
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.
Frequently asked questions
What does a Backend Engineer earn at an SMB in Germany?
The reference range for a mid-level Backend Engineer (3 to 7 years of experience) at a German SMB is 52 to 78 k€ gross fixed salary per year (median around 62 k€). Berlin, Munich and Hamburg in the SaaS and scale-up scene pull upward (75 to 95 k€); classic Mittelstand and regional locations trend downward. Distributed systems, high load or hard latency requirements pull noticeably upward. Engineering roles in Germany usually have no variable compensation component; scale-ups add VSOP or ESOP (virtual equity) on top.
What is the difference between backend, full-stack and DevOps profiles?
Backend Engineers focus on the API, the database, scalability, security and production operations of the server side. Full-stack profiles cover frontend and backend at an intermediate to advanced level and are often the standard profile at a small SMB. DevOps or SRE profiles take on infrastructure, deployment, observability and reliability across several services. From around 8 to 12 Backend Engineers a dedicated SRE role becomes worthwhile; before that the backend team carries the operational responsibility too.
How long does it take to hire a Backend Engineer in Germany?
Expect 50 to 80 days between posting the job and the signed contract for a mid-level backend profile. The German tech market remains tight in 2025-2026, especially for profiles with a modern stack (Go, Python, Java with Kubernetes, Postgres) and experience with distributed systems. Timelines lengthen in late summer and around the turn of the year. Cutting below 50 days usually sacrifices the system-design stage or the reference check and noticeably lowers hiring quality.
Do Backend Engineers need a specific university degree?
No. The German tech market largely accepts self-taught profiles and bootcamp graduates (Le Wagon Berlin, neue fische, Spiced Academy) once there are 3 to 5 years of solid production practice, ideally with on-call experience. A degree (computer science from a university of applied sciences or a university, technical mathematics) is reassuring for junior profiles but loses importance after 5 years of experience. Assess on the basis of code, the system-design exercise and incident experience, not academic pedigree.
What legal requirements apply to backend job postings in Germany?
Three central requirements: (1) a gender-neutral job title with (m/w/d) or colon spelling (§ 11 AGG), (2) the obligation of pay transparency in the ad or before the first interview (EU Pay Transparency Directive 2023/970, implementation by 7 June 2026), (3) transparency about the use of AI tools for pre-selection and guaranteed human oversight (EU AI Act, from 2 August 2026). In addition: when contracting through freelance or temporary staffing, a clean demarcation from permanent employment to avoid bogus self-employment.
Does every backend hire warrant a technical test?
Yes, combined with a system-design exercise. For backend profiles the system-design exercise (60 min, a real case) is by far the most predictive step: poor decisions on data model, consistency or queueing only show up after months and are expensive to repair. The technical test should be short (at most 2 to 3 hours), realistic (endpoint, bug, refactor) and aligned with the stack. Avoid purely academic algorithm tasks with no relation to daily work. Cap the expected time explicitly and accept incomplete but well-reasoned solutions.