Full-Stack Engineer
Job description, salary, sourcing, 15 interview questions and a 30/60/90 plan to hire a Full-Stack Engineer in a German SMB.
Compiled by the Join team from public data and our hiring experience.
Updated
At a glance
- Median salary€60,000€50,000 – €75,000
- Time to fill50–80 days
- Experience3–6 years
How to hire a Full-Stack Engineer for your SMB
Before you write the job posting, settle three framing questions. They decide which profile you are actually looking for and help you avoid the most common mistakes in tech hiring at a German SMB.
Question 1: Full-stack or specialist? Full-Stack Engineers cover frontend and backend at an intermediate to advanced level; pure specialists (frontend-only, backend-only) are deeper in their area. At tech SMBs with fewer than 10 engineers, full-stack is almost always the right choice: specialization is only worth it from a certain team size and product complexity. When in doubt, take full-stack with a slight tilt (more frontend-oriented or more backend-oriented) depending on the current need.
Question 2: Which stack do you have and how mature is it? A good engineer on React, Node and Postgres will not be productive on Vue, Python and MongoDB overnight; they need 2 to 4 weeks of ramp-up. For a mid-level profile, stack fit counts more than absolute seniority. Put your stack prominently in the posting; that filters out poorly matched profiles automatically. If your stack counts as legacy (classic PHP, jQuery, older Java monoliths), say so openly and target profiles who enjoy codebase modernization, instead of importing disappointed switchers.
Question 3: What share of the time goes into independent technical decisions? At an early-stage SMB (fewer than 5 engineers), a mid-level full-stack engineer regularly makes architecture decisions (library choice, designing a new service, refactoring critical zones). At an established SMB (more than 15 engineers), they execute more within a framework already set by a tech lead. The ideal profile differs: autonomy and resourcefulness in the first case, execution quality and collaboration in the second. Clarify this dimension already in the posting.
If all three answers point to a full-time Full-Stack Engineer (and not a specialist or tech lead), continue to the template below.
JD template
Full-Stack Engineer (m/w/d): product development at an SMB
[Company name], a B2B SMB in [industry] based in [city], [X] employees, [X] M€ ARR, is hiring a Full-Stack Engineer to strengthen a tech team of [X] engineers.
Your mission
You design, build and maintain product features across the entire stack ([frontend and backend and database]), independently on familiar topics and in alignment on structuring decisions. You report to the [Tech Lead / CTO / technical management].
Key responsibilities
- Deliver features end to end: understanding the product need, technical design, frontend and backend implementation, tests, deployment, support in production.
- Contribute to architecture decisions in your area of responsibility (library choice, refactor, designing a new service).
- Ensure code quality: review colleagues’ PRs, apply the conventions, refactor in passing where it makes sense.
- Contribute to fixing production incidents (on-call or standby depending on the organization).
- Document important technical decisions and non-trivial zones of complexity.
- Work with PM, design and management on product briefs; constructively challenge requirements that are unfeasible or counterproductive.
Profile
- Essential: [3 to 6] years of professional web-development experience; solid command of at least one modern frontend framework (React, Vue, Svelte) and backend framework (Node, Python, Ruby, Go or equivalent); experience with production operations (deployment, monitoring, incident handling).
- Desirable: familiarity with our stack [React and Node / Python / other]; experience at an SMB or startup (high autonomy); open-source contributions or visible side projects.
- Disqualifying: no experience with independent production operations; refusal to touch either frontend or backend; blanket rejection of modern frameworks.
What we offer
- Gross annual compensation: [50-75] k€ depending on experience. No structural variable; possibly VSOP / ESOP depending on the company’s stage.
- Model: [full-time, hybrid 2-3 days / week on-site, based in [city] / remote-friendly].
- Benefits: [company pension, bike leasing, employee equity, vacation days, home-office policy, hardware budget, training budget].
- Stack: [to be completed: frontend, backend, DB, infra, CI/CD, monitoring].
Salary band
Base salary, gross annual
- 25th percentile
- €50,000
- Median
- €60,000
- 75th percentile
- €75,000
Gross fixed salary per year for a mid-level Full-Stack Engineer (3 to 6 years of experience) at a German SMB or Mittelstand company. Berlin, Munich and Hamburg in the SaaS/scale-up environment pull upward (70-90 k€); the classic Mittelstand and provincial locations trend lower (45-55 k€). A modern stack (React + Node or Python, Postgres, Kubernetes) pulls upward; a legacy stack (classic PHP, jQuery, older Java monoliths) pulls downward. Engineering roles in Germany usually have no variable compensation component; scale-ups add VSOP/ESOP on top.
Sources: Stepstone Gehaltsdaten Fullstack-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 tech profiles in Germany. Active sourcing via Recruiter Lite plus personalized InMails is far more effective than job posts alone: strong full-stack profiles rarely scan the jobs feed anymore. Filter precisely on your stack (React + Node or Python + Postgres) and seniority before reaching out. Generic outreach sequences see response rates under 5 %; personalized messages with a clear stack and product reference land at 15-25 %.
XING
ProJobs from €195 / monthStill relevant for tech profiles in the classic Mittelstand outside the Berlin startup scene, especially in NRW, Bavaria and Baden-Württemberg. A good complement for full-stack profiles between 30 and 45 who do not actively maintain a LinkedIn presence. In classic industry sectors (mechanical engineering, Industry 4.0, traditional trade) often on par with LinkedIn or better. Weaker signal for pure startup/scale-up stack profiles.
Honeypot, GitHub Jobs successor, niche tech boards
Honeypot success fee 15 % of the annual fixed salary; niche boards €200-500 per postingHoneypot is the Germany-specific tech reverse-recruiting platform: developers create profiles, companies apply to them. It works especially well for senior profiles who are not actively searching but open to a move. As a complement: stack-specific boards (German Tech Jobs, We Are Developers) and GitHub sponsorships for visible open-source profiles. Overall lower volume than LinkedIn/XING, but higher signal quality per contact; good for topping up a LinkedIn-driven pipeline.
Evaluation playbook
The Full-Stack Engineer role reveals itself across five evaluation stages. The hands-on exercise (stage 4) must be realistic and time-boxed: an 8-hour task actually takes 24 hours, demotivates good profiles and delivers no better signal than a well-constructed 2-3 hour task.
Stage 1: CV review
Look for stack consistency (a profile with React and Python does not switch back to Java without 3-6 months of ramp-up), stability (at least 18-24 months in previous roles) and autonomy signals (own projects, open-source contributions, visible GitHub). The degree counts less than the last 3-5 years of practice: a self-taught engineer with 5 years of solid production experience weighs more than a top-university graduate with 2 years of extended internship.
Stage 2: Phone screen (30 min)
Three questions only: (1) Describe the most recent project you are proudest of; what was your concrete contribution?, (2) Which technical decision did you make recently that you still have doubts about? (humility and reflection), (3) Why are you looking to move now? Outcome: go/no-go in a 5-minute debrief. Avoid technical gotcha questions at this stage.
Stage 3: Technical interview (60-90 min)
Pair programming or code review on a bounded task (45-60 min), followed by 15-30 min of Q&A on architecture and technical decisions. Assess the ability to think out loud, ask clarifying questions and iterate. Avoid purely academic algorithms with no link to daily work; prefer tasks that resemble daily work (refactoring, adding a feature, debugging an uncovered case).
Stage 4: System-design exercise (60 min)
An architecture discussion on a concrete case: how would you design a system for [a product-specific feature]? Assess the ability to clarify conditions before proposing, weigh simplicity against scalability, and recognize zones of uncertainty. This is the most predictive stage for a Full-Stack Engineer who has to make technical decisions independently at an SMB.
Stage 5: References (structured check)
Call two references: a former tech lead or direct manager and a former developer colleague. 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 made independently? The fourth question delivers the real autonomy signal.
Structured interview questions
BehavioralTechnical decision-making Describe the hardest technical decision in your last role. Why was it hard and how did you make it?
What a strong answer surfacesAbility to structure a decision under uncertainty: identifying the conditions, explicit trade-offs, consulting the affected people, validating afterwards with data. Bonus: the candidate mentions changing their mind along the way or documenting the decision for the future. Anyone who describes an obvious decision in hindsight rarely weighed it seriously.
BehavioralDebugging and investigation Tell me about a production bug you fixed. What was the symptom, how did you diagnose it and how long did it take?
What a strong answer surfacesA structured debugging method: reproduction, logs, instrumentation, hypotheses validated by experiment. Honesty about duration (a real production bug is rarely done in under 30 minutes). Bonus: the candidate names the root cause and the systemic fix, not just the hotfix. Answers like I restarted the service with no diagnosis point to weak investigative ability.
BehavioralLearning ability and humility Describe a moment when you had to refactor or rewrite code you had written yourself just a few months earlier. What had happened in the meantime?
What a strong answer surfacesTechnical humility and an ability to learn. Bonus: the candidate names what they would do differently from the start today. Anyone who never really had to refactor their own code is lying or never kept code in production over time.
SituationalTechnical courage In a code review you spot a security flaw (SQL injection, a secret in plaintext, a missing auth check) in a senior colleague's PR. How do you react?
What a strong answer surfacesAbility to flag a technical weakness without blocking: a factual comment in the PR (here is the risk, here is my suggested fix), an offer to help solve it, escalation to the tech lead if the PR is merged despite the comment. Anyone who lets it slide because the profile is senior shows a lack of technical courage.
SituationalCommunication with product A Product Manager asks for a feature that you estimate at 3 weeks. The PM wants it in one week. How do you react?
What a strong answer surfacesClarifying the need before negotiating the timeline (perhaps the feature can ship in two phases or be simplified). Offering options: an MVP in one week plus V2 in two weeks, an explicit scope cut, additional resources. Answers like I can do it in a week if I work the weekend are a warning flag (a signal of poor self-management).
SituationalPragmatism and prioritization You join a team with significant technical debt: insufficient tests, manual deployments, barely any monitoring. What does your 30-day plan look like?
What a strong answer surfacesDiagnosis first: no attempt to fix everything at once. Prioritization by risk and impact (typically: monitoring first to see, then tests in critical zones, then deployment automation). Alignment with the team and tech lead before each move. Anyone who dives straight into a full rebuild shows a lack of pragmatism.
CaseSystem design Design: we want to add real-time notifications to our application (example: a colleague commented on your document). How do you design it?
What a strong answer surfacesClarification before proposing (expected volume, latency requirements, supported devices, persistence of unread notifications). A coherent architecture: push (WebSocket or Server-Sent Events) vs. pull (polling), persistence (a notification DB), idempotency, an email fallback. Bonus: acknowledging the zones of uncertainty (I'd build a POC before committing between WebSocket and SSE). Anyone who jumps straight into code without clarifying shows a design weakness.
CaseDebugging and investigation Debug: your API returns a 500 on 2 % of requests. The logs show no obvious error. How do you proceed?
What a strong answer surfacesA structured method: (1) temporarily raise the log level on the affected endpoints, (2) correlate with metrics (latency, payload size, source), (3) identify a pattern (time of day, request type, a specific user), (4) order the hypotheses (DB timeout, race condition, memory). Anyone who jumps straight to it's probably the DB without investigating has a bias.
CaseOptimization Performance: one page of your application takes 8 seconds to load. You have one week to get it under 2 seconds. Action plan?
What a strong answer surfacesMeasure before optimizing: DevTools, Lighthouse, a server profiler. Identify the bottleneck (rendering, DB queries, payload, CDN). Prioritize by effort times impact. Answers like I add caching with no diagnosis point to premature optimization. Bonus: recognizing that 8 seconds in production usually points to a systemic problem (N+1 queries, a huge payload), not a local optimization.
TechnicalCode quality What is your test strategy? Describe your last project: how many tests, which types, what coverage, and what did you really measure?
What a strong answer surfacesUnderstanding of the test pyramid (many unit tests, fewer integration tests, few E2E). Distinguishing coverage from value (90 % coverage on trivial code weighs less than 60 % on critical business logic). Bonus: the candidate cites a case where a test prevented a real regression. Anyone who simply answers 100 % coverage with no distinction shows weak judgment.
TechnicalBackend fundamentals What is the difference between a DB transaction and an application lock? When do you use one and when the other?
What a strong answer surfacesDB transaction: atomicity and isolation are managed by the DB (ACID), limited to the transaction's duration. Application lock: coordination between processes or instances via Redis, ZooKeeper or similar; useful when coordination goes beyond a single DB (microservices, a task queue). Deadlock risk in both. Anyone who cannot separate the two mechanisms builds race conditions into production.
TechnicalPragmatism and prioritization You join a poorly organized React codebase: 500-line components, props drilling across 5 levels, no separation of logic and presentation. Your action plan in 60 days, without breaking everything?
What a strong answer surfacesA stepwise approach: (1) map the critical components and recurring patterns, (2) first extract hooks and business logic (high leverage, low risk), (3) split large components along functional boundaries, not technical schemas, (4) introduce a state manager only where props drilling actually hurts (Context or Zustand at an SMB, Redux at higher volume). Anyone who wants to switch everything to React Server Components right away shows a lack of pragmatism.
ValuesCoachability How do you take a critical code review of code you were convinced was good?
What a strong answer surfacesOpenness: the ability to separate the code from personal ego. Bonus: the candidate cites a case where a review actually made them rethink. Anyone who describes explaining their logic to the reviewer instead of listening shows a coachability weakness; at an SMB with a small tech team that is a hard knock-out signal.
ValuesMentoring and knowledge sharing What role do you play in passing on technical knowledge to junior profiles or new team members?
What a strong answer surfacesAn active mentoring posture: pair programming, educational reviews (not just ok merge), documenting decisions, sharing good practices. Anyone who says I help when I'm asked with nothing more concrete shows a passive posture. At an SMB with a small tech team, the ability to pass on knowledge is decisive for the team's sustainability.
ValuesTeamwork with product How do you work with Product Managers and designers? Describe a situation where you pushed back on a brief.
What a strong answer surfacesA partnership posture: constructive challenging on the basis of feasibility or complexity, alternative proposals. Bonus: the candidate cites a case where they accepted the original brief after discussion (no systematic opposition). Anyone who describes PMs or designers as they don't understand the tech shows a teamwork weakness.
How to recognize a great hire
| Trait | Below bar | On bar | Above bar |
|---|---|---|---|
| Technical soundness | Stumbles over fundamentals (HTTP, DB transactions, asynchrony). Finds solutions by trial and error with no clear mental model. Hard to put on a new language or framework. | Masters the current stack independently. Can learn a new framework in 2-4 weeks. Understands the fundamentals well enough to debug deeply when needed. | A reference for the stack on the team and able to switch to a new stack within a few weeks. Anticipates the classic traps (race conditions, memory leaks, edge cases). Builds useful, not premature, abstractions. |
| System design and pragmatism | Jumps into code without clarifying the conditions. Over-architects (microservices for an MVP) or under-architects (a spaghetti monolith with 50k LOC). Struggles to weigh simplicity against scalability. | Clarifies the need before coding. Pragmatic in the trade-off: no premature architecture for an uncertain future, but identifies zones where a little structure pays off. Can pivot when the initial hypothesis does not hold. | Designs systems that age well: well-chosen abstractions, minimal dependencies, clear functional boundaries. Recognizes their own zones of uncertainty and proposes targeted POCs. Trains the team in systemic thinking. |
| Code quality and hygiene | No clear test strategy; adds tests to produce coverage. Poorly structured code (500-line components, copy-paste, magic numbers). Superficial reviews. | A test pyramid fitting the business-critical zones. Readable code with clear naming and short functions. Structured reviews with actionable feedback. Refactors in passing where it makes sense. | A reference on the team for quality: documented conventions, automation of checks (linter, type checker, CI). Educational reviews that grow junior profiles. Can say no to code that passes the tests but ages badly. |
| Autonomy and resourcefulness | Blocks for hours on an unfamiliar topic without asking for help, or asks at the first obstacle. No structured debugging strategy. | Can diagnose independently on familiar topics; asks for help after investigating first (a summary of the problem, hypotheses, what has already been tried). | High resourcefulness on unfamiliar topics: reads the source of dependencies, instruments the runtime, isolates root causes. Documents the findings for the team. |
| Communication and teamwork | Explains their own work poorly to non-technical people. Defensive in reviews. Works in a silo, shares little context. Systematic opposition to PMs or designers. | Can explain their work to PM or management in clear language. Takes reviews constructively. Shares context in team reviews and 1:1s. | A bridge between tech 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
- Local development environment fully set up and deployment of a (even trivial) PR to production validated
- Read and understood the code of the 3 most business-critical modules of the stack
- First documented 1:1 with the tech lead on conventions, identified debt and priorities
- First substantial PR (bug fix or small feature) reviewed and merged
By day 60
- Delivered a complete feature end to end (frontend, backend, deployment) independently
- First PR review of a colleague with structured feedback, not just an approve click
- First on-call or standby phase (if applicable) handling at least one incident
- Wrote or updated documentation of a recently worked module
By day 90
- Regular delivery (1-2 PRs per week) with quality confirmed in review
- First technical decision made independently on an ambiguous topic (refactor, library choice, design)
- Informal mentoring of a junior or new profile (pair programming, educational reviews)
- Formal review with the tech lead: ramp validated, development plan on 1-2 focus areas
Common hiring mistakes for this role
Hiring on corporate pedigree instead of operational ramp
A top graduate from a prestigious university with 2 years at a DAX corporation or a Big Tech branch is not automatically more productive than a self-taught engineer with 5 years of production practice at a startup or SMB. Large organizations give their engineers clear specs, demanding reviews and solid tooling; at an SMB that scaffolding is usually missing, and the lack of autonomy becomes a burden. Weight the hands-on technical interview and the system-design exercise more heavily than the pedigree on the CV.
Overvaluing algorithmic fundamentals for a product role
A Full-Stack Engineer at an SMB almost never has to optimize a graph algorithm or reimplement a B-tree. LeetCode-style tasks filter for academic profiles at the expense of operational ones (who can deliver a complete feature independently). Prefer tasks that resemble daily work: add a feature, debug an uncovered case, refactor an overloaded component. 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-3 hour task. You want to measure the quality of the reasoning, not completeness. Cap the expected time explicitly and accept incomplete but well-reasoned solutions.
Underestimating stack and ecosystem fit
A good React and Node engineer is not productive on Vue and Python overnight; they need 2-4 weeks of ramp-up. A profile with a close stack (React, TypeScript, Postgres for an SMB on the same stack) is already productive in 1-2 weeks. Stack fit counts more than absolute seniority for a mid-level full-stack engineer. Put your stack prominently in the posting; that filters out poorly matched profiles automatically.
Underestimating cross-functional communication
A Full-Stack Engineer at an SMB talks almost daily with PMs, designers, sometimes directly with management or customers. Someone who is technically strong but weak in cross-functional communication produces friction: misunderstood briefs, opaque timelines, conflicts with product. Assess communication explicitly in the interview (situational questions with a PM angle, explaining a technical topic in everyday language).
Frequently asked questions
What does a Full-Stack Engineer earn at an SMB in Germany?
The reference range for a mid-level Full-Stack Engineer (3 to 6 years of experience) at a German SMB is 50 to 75 k€ gross fixed salary per year (median around 60 k€). Berlin, Munich and Hamburg in the SaaS/scale-up environment pull upward (70 to 90 k€); the classic Mittelstand and provincial locations trend lower. 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 a Full-Stack, Frontend and Backend Engineer?
Frontend Engineers focus on the user interface (React, Vue, CSS, accessibility, perceived performance). Backend Engineers focus on the API, the database, scalability and security. Full-Stack Engineers cover both at an intermediate to advanced level; at a German SMB full-stack is often the default profile, because pure specialization is not justified by the volume. From teams of more than 30 engineers, specialization becomes more relevant.
How long does it take to hire a Full-Stack Engineer in Germany?
Expect 50 to 80 days between posting the role and a signed contract for a mid-level profile. The German tech market remains tight in 2025-2026, especially for profiles with a modern stack (React and Node or Python, Postgres, Kubernetes). Timelines lengthen in late summer and around the turn of the year. Cutting below 50 days usually comes at the cost of an evaluation stage and noticeably lowers hiring quality.
Do Full-Stack Engineers need a specific degree?
No. The German tech market largely accepts self-taught profiles and bootcamp graduates (Le Wagon Berlin, neue fische, CareerFoundry, Spiced Academy) once there are 3 to 5 years of solid production practice. A degree (applied-sciences computer science, a university computer-science degree) is reassuring for junior profiles but loses significance after 5 years of experience. Assess on the basis of the code and problem-solving, not academic pedigree.
What legal requirements apply to tech 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 engaging via freelance or temporary agency work, a clean demarcation from permanent employment to avoid bogus self-employment.
Is a technical test worthwhile in every hire?
Yes, but short (a maximum of 2 to 3 hours) and realistic. A well-constructed technical test is the best predictor of future performance, ahead of degree and pedigree. Avoid purely academic algorithm tasks with no link to daily work (LeetCode hard); prefer tasks that resemble daily work (add a feature, debug, refactor). Cap the expected time explicitly and accept incomplete but well-reasoned solutions.