Senior Frontend Engineer
Job description, salary, sourcing, interview questions and a 30/60/90 plan to hire a Senior Frontend Engineer in a German SMB.
Compiled by the Join team from public data and our hiring experience.
Updated
At a glance
- Median salary€80,000€68,000 – €98,000
- Time to fill60–95 days
- Experience7–12 years
How to hire a Frontend 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 frontend hiring at a German SMB.
Question 1: A frontend specialist or full-stack with a frontend tilt? Frontend specialists bring depth in UI architecture, design-system maintenance, accessibility and performance; full-stack profiles bring breadth across frontend and backend, but rarely the same depth in complex UI. At tech SMBs with fewer than 8 engineers, full-stack is often the more efficient choice. A true frontend-specialist role is worth it once the product has a complex UI (workflow tools, data visualization, drag-and-drop, editor functionality), a design system has to be actively maintained, or accessibility and performance are binding requirements (a BFSG-affected B2C product, an SEO-driven business). When in doubt: read the full-stack template in parallel; if frontend dominates that profile, you do not need a dedicated specialist role.
Question 2: Which stack do you have and how mature is it? A good Frontend Engineer on React and TypeScript will not be productive on Vue and JavaScript overnight; they need 2 to 4 weeks of ramp-up, and the reverse switch is just as costly. For a mid-level profile, stack fit counts more than absolute seniority. Put your stack prominently in the posting (framework, state management, styling strategy, build tool); that filters out poorly matched profiles automatically. If your stack counts as legacy (classic jQuery, AngularJS, older CMS frontends with no bundler), say so openly and target profiles who enjoy codebase modernization, instead of importing disappointed switchers.
Question 3: How important are accessibility and performance in your product? In a B2C product under BFSG obligation (e-commerce, banks, telecommunications, e-books, passenger transport), accessibility has been legally binding since mid-2025; without a profile with real accessibility practice you risk lawsuits and rework. In SEO-driven B2B products (lead generation, content marketing), performance is directly relevant to CTR and conversion. In internal tools with a small, closed user base the bars are lower, but not zero. Clarify the real requirement before posting: if both are high, describe the expected practice concretely (axe audits, Lighthouse budgets, keyboard and screen-reader tests); otherwise the profiles with genuine skill in these areas filter themselves out.
If all three answers point to a full-time frontend specialist (and not a full-stack engineer or tech lead), continue to the template below.
JD template
Frontend 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 Frontend Engineer to strengthen a tech team of [X] engineers.
Your mission
You design, build and maintain the user interface of our product ([single-page app / multi-page web app / hybrid]), independently on familiar topics and in alignment on structuring decisions. You report to the [Tech Lead / CTO / technical management].
Key responsibilities
- Deliver frontend features end to end: understanding the product need, alignment with design, technical design of the components, implementation with tests, accessibility and performance check, handover to production.
- Contribute to the maintenance and evolution of the design system (new components, tokens, variants, alignment with designers).
- Treat accessibility and performance as standard, not as a special task: axe audits, keyboard and screen-reader smoke tests, Lighthouse checks, performance budgets.
- Ensure code quality: review colleagues’ PRs, apply the conventions, refactor in passing where it makes sense.
- Work with designers, PMs and backend on product briefs; constructively challenge requirements that are unfeasible or counterproductive.
- Document important technical decisions and non-trivial zones of complexity.
Profile
- Essential: [3 to 6] years of professional frontend-development experience; solid command of at least one modern frontend framework (React, Vue, Svelte) with TypeScript; experience with production operations (deployment, monitoring, incident handling); demonstrable accessibility and performance practice (at least basic tools and routines).
- Desirable: familiarity with our stack [React and TypeScript / Vue and TypeScript / other]; experience maintaining a design system (tokens, components, variants, versioning); open-source contributions or visible side projects on frontend topics; experience at an SMB or startup (high autonomy).
- Disqualifying: no experience with independent production operations; treating accessibility as a pure QA task; treating performance as a task for after delivery; blanket rejection of modern frameworks or blanket attachment to an outdated framework.
What we offer
- Gross annual compensation: [48-72] 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 and conference budget].
- Stack: [to be completed: framework and state management, styling strategy, build tool, test tooling, Storybook, CI/CD, monitoring].
Salary band
Base salary, gross annual
- 25th percentile
- €68,000
- Median
- €80,000
- 75th percentile
- €98,000
Gross fixed salary per year for a senior Frontend Engineer (7 to 12+ years of experience) at a German SMB or Mittelstand company. Berlin, Munich and Hamburg in the SaaS/scale-up environment pull upward (92-118 k€); classic Mittelstand and provincial locations trend lower (60-75 k€). Deep ownership of a design system, a track record in performance and accessibility work, and technical leadership (mentoring, architecture decisions) pull noticeably upward. Engineering roles in Germany usually have no variable compensation component; scale-ups add VSOP/ESOP on top, which matters more at senior level.
Sources: Stepstone Gehaltsdaten Senior Front End Developer Deutschland 2026; Glassdoor Gehalt Senior Front End Developer Deutschland 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 frontend profiles in Germany. Active sourcing via Recruiter Lite plus personalized InMails is far more effective than job posts alone: strong frontend engineers rarely scan the jobs feed anymore, but they are visible in open-source contributions, conference talks (meetups, JSConf, CSSconf) and posts about performance and accessibility. Filter precisely on the stack (React or Vue with TypeScript) and on specialization signals (design-system maintenance, web performance, ARIA) before reaching out. Generic outreach sequences see response rates under 5 %; messages that reference a specific repo, blog post or talk land at 15-25 %.
XING
ProJobs from €195 / monthStill relevant for frontend profiles in the classic Mittelstand outside the Berlin startup scene, especially in NRW, Bavaria and Baden-Württemberg. A good complement for profiles between 30 and 45 with an agency background or experience in CMS-driven frontends (TYPO3, Shopware, Spryker) who do not actively maintain a LinkedIn presence. In classic industry and trade sectors often on par with LinkedIn or better. Weaker signal for pure tech scale-up or single-page-app profiles in Berlin.
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 mid and senior frontend profiles who are not actively searching but open to a move. As a complement: stack-specific boards (German Tech Jobs, We Are Developers, the FrontendLove job board), GitHub sponsorships for visible open-source profiles, and local frontend meetups (Berlin.js, FrontendNRW, ReactJS München) as co-sponsoring channels. Overall lower volume than LinkedIn/XING, but high signal quality per contact; good for topping up a LinkedIn-driven pipeline with specialist profiles for performance, accessibility or design-system work.
Evaluation playbook
The Frontend Engineer role reveals itself across five evaluation stages. The hands-on exercise (stage 3) is the most telling stage: frontend can be discussed in theory for two hours without showing whether someone really masters state management, accessibility and performance day to day. Keep the exercise short (2-3 hours) and close to daily work.
Stage 1: CV and portfolio review
Read the CV, GitHub and (if available) personal website side by side. Look for stack consistency (a profile with 5 years of React now learning Vue is more plausible than someone who jumped between seven frameworks), stability (at least 18-24 months in previous roles) and specialization signals: contributions to design systems, conference talks on performance, accessibility audits, visible open-source maintenance. 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. Negative signal: exclusively tutorial-clone repos with no real product usage.
Stage 2: Phone screen (30 min)
Three questions only: (1) Describe the most recent frontend project you are proudest of; what was your concrete contribution and what usage impact did it have?, (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 trivia questions about framework APIs at this point; look for unfiltered frontend thinking.
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, state management and concrete decisions. A typical task: extend a component with a feature (with tests and accessibility requirements), identify a performance hotspot in an existing component, or debug a UI-bug reproduction case. Assess the ability to think out loud, ask clarifying questions, write tests and watch for accessibility and performance. Avoid purely academic algorithms with no link to daily work.
Stage 4: Frontend system-design exercise (60 min)
An architecture discussion on a concrete frontend case: how would you design [a complex UI component, a multi-step flow, an offline-capable application, a reusable table building block]? Assess the ability to clarify conditions before proposing (browser support, localization, accessibility level, expected data volume), weigh simplicity against reusability, explain the interplay with the design system and backend, and recognize zones of uncertainty. This stage is the most predictive for a Frontend 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 frontend or design colleague. Ask both the same 4 questions: What is she/he strongest at (UI quality, performance, accessibility, design system, tests)? 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 frontend decision in your last role (framework migration, state-management choice, performance refactor). Why was it hard and how did you make it?
What a strong answer surfacesAbility to structure a decision under uncertainty: identifying the conditions (browser support, team skill, existing codebase), explicit trade-offs, consulting the affected people (design, backend, PM), validating afterwards with data (bundle size, Lighthouse, error rate). Bonus: the candidate mentions changing their mind along the way or documenting the decision. Anyone who describes an obvious decision in hindsight rarely weighed it seriously.
BehavioralDebugging and investigation Tell me about a UI bug or performance regression in production that 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 in the browser (DevTools, Performance tab, Network tab), identifying the affected devices or browsers, hypotheses validated by experiment. Honesty about duration (a real production frontend bug is rarely done in under 30 minutes, especially with browser incompatibilities). Bonus: the candidate names the root cause and the systemic fix, not just the hotfix. Answers like I built a CSS workaround with no diagnosis point to weak investigative ability.
BehavioralLearning ability and humility Describe a moment when you had to refactor or rewrite a component you had built 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 (e.g. composition over inheritance, hooks extraction, clearer props contracts). Anyone who never really had to refactor their own components either shipped nothing into real production or never evolved the product over time.
SituationalTechnical courage In a code review you spot an accessibility gap (missing ARIA labels, unreachable focus, no keyboard operability) 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 for keyboard or screen-reader users, 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, or who treats accessibility as a nice-to-have, shows a lack of technical courage and gaps in frontend understanding.
SituationalCommunication with product A Product Manager asks for a frontend feature (a complex filter with 10 dimensions) 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 critical filter dimensions can ship in one week, the rest in V2). Offering options: an MVP in one week plus V2 in two weeks, an explicit scope cut, a workable UI variant with fewer edge cases. 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 frontend with significant technical debt: no TypeScript types, 800-line components, no design system, no clear test setup. What does your 60-day plan look like?
What a strong answer surfacesDiagnosis first: no attempt to fix everything at once. Prioritization by risk and impact (typically: first enforce TypeScript in new components and type the critical existing ones, then consolidate the 8-12 most-used components, then a lightweight test setup for the critical flows). Alignment with the team and tech lead before each move. Anyone who dives straight into a full rewrite or immediately declares a Material UI design system shows a lack of pragmatism.
CaseSystem design Design: we want to add a reusable table with sorting, filtering, pagination and configurable columns to our application. How do you design the component?
What a strong answer surfacesClarification before proposing (expected row count, data source, server vs. client sorting, accessibility requirements, how many places it is reused). A coherent architecture: composition vs. configuration props, a clear slot or render-prop API, virtualization above which row count, keyboard navigation, ARIA roles for tables. Bonus: acknowledging the zones of uncertainty (I'd build a POC with React Aria or TanStack Table before deciding what to build ourselves). Anyone who jumps straight into code without clarifying shows a design weakness.
CaseDebugging and investigation Debug: on mobile in Safari on iOS the app becomes sluggish after 30 seconds of use. In Chrome on desktop nothing is noticeable. How do you proceed?
What a strong answer surfacesA structured method: (1) reproduce on a real device or via BrowserStack, not just the desktop DevTools emulator, (2) profile with Safari Web Inspector over USB debugging, (3) order the hypotheses (a memory leak in a listener binding, excessive re-renders, heavy animations, layout thrashing, large images with no lazy loading), (4) compare metrics (CPU, memory, long tasks, FPS). Anyone who jumps straight to it's probably Safari without investigating has a bias and underestimates iOS-specific quirks (e.g. WebKit memory management).
CaseOptimization Performance: one page of your application scores 35 on Lighthouse Mobile with a 6-second LCP. You have two weeks to get the score above 80 and LCP under 2.5 seconds. Action plan?
What a strong answer surfacesMeasure before optimizing: Lighthouse, WebPageTest, Chrome DevTools Performance tab, RUM data if available. Identify the bottleneck (render-blocking JS or CSS, large unoptimized images, no code splitting, heavy third-party scripts, unused JavaScript, missing caching headers). Prioritize by effort times impact: typically image optimization and code splitting first, then limiting third-party scripts, then server response time. Answers like I add server-side rendering with no diagnosis point to premature optimization. Bonus: recognizing that LCP problems usually sit with images, web fonts or a late hydration step.
TechnicalCode quality What is your frontend test strategy? Describe your last project: how many tests, which types (unit, component, integration, E2E), what coverage, and what did you really measure?
What a strong answer surfacesUnderstanding of the frontend test pyramid (many unit tests on hooks and utilities, component tests with Testing Library on behavior rather than implementation, few E2E in Playwright or Cypress on the critical flows). Distinguishing coverage from value (90 % coverage on presentational components weighs less than 60 % on a checkout flow). Bonus: the candidate cites a case where a test prevented a real regression. Anyone who names snapshot tests as their core strategy or simply answers 100 % coverage with no distinction shows weak judgment.
TechnicalFrontend fundamentals What is the difference between useEffect, useLayoutEffect and a state-driven render in React? When do you use which tool? (Or the Vue equivalent.)
What a strong answer surfacesuseEffect: runs after commit, asynchronously to the browser paint, suited to data fetching, logging, subscriptions. useLayoutEffect: runs synchronously after commit, before paint, suited to measurements and imperative DOM access that must avoid layout flicker. Prefer a state-driven render when the information can be derived from props or state (no effect needed). Anyone who cannot separate the three mechanisms builds the classic frontend anti-patterns: double renders, flicker, race conditions in effects. Vue equivalent: watchEffect vs. computed vs. lifecycle hooks.
TechnicalPragmatism and prioritization You join a poorly organized React or Vue codebase: 500-line components, props drilling across 5 levels, no separation of logic and presentation, mixed styling approaches. 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 or composables 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 Pinia at an SMB, Redux or Zustand at higher volume), (5) unify the styling strategy without a big-bang migration. Anyone who wants to switch everything to React Server Components or Nuxt 4 right away shows a lack of pragmatism.
ValuesCoachability How do you take a critical code review of frontend 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 (e.g. accessibility notes that seemed unimportant at first). Anyone who describes explaining their logic to the reviewer instead of listening shows a coachability weakness; at an SMB with a small frontend team that is a hard knock-out signal.
ValuesAccessibility and quality What role does accessibility play in your daily work? Describe concretely what you checked or implemented on the last component you built.
What a strong answer surfacesAn active accessibility posture: semantic HTML as standard, keyboard navigation tested, focus order and visible focus checked, ARIA roles only where needed, contrast validated, a screen-reader test at least once per non-trivial component. Bonus: the candidate names a concrete tool (axe, Lighthouse, VoiceOver, NVDA) and a case where an accessibility audit delivered a real usage improvement. Anyone who treats accessibility as an end-of-project task or blanket-delegates it to QA shows a gap that gets expensive at an SMB (lawsuits under the BFSG since mid-2025 are real).
ValuesTeamwork with product and design How do you work with designers and Product Managers? Describe a situation where you pushed back on a design brief.
What a strong answer surfacesA partnership posture: constructive challenging on the basis of feasibility, performance or accessibility risk, alternative proposals with a sketch or prototype. Bonus: the candidate cites a case where they accepted the original brief after discussion (no systematic opposition). Anyone who describes designers as they don't understand the tech or PMs as they talk too much shows a teamwork weakness that gets especially expensive at an SMB with a small product team.
How to recognize a great hire
| Trait | Below bar | On bar | Above bar |
|---|---|---|---|
| Frontend soundness | Stumbles over fundamentals (box model, event loop, the chosen framework's render cycle, asynchronous data flows). Finds solutions by trial and error with no clear mental model. Hard to put on a new framework. | Masters the current stack independently (React or Vue with TypeScript, common build tooling, standard state pattern). 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 (re-render storms, hydration mismatches, memory leaks in subscriptions). Builds useful, not premature, abstractions and knows the limits of their own framework choice. |
| Performance, accessibility and quality | Ships without a Lighthouse or accessibility check. Loads heavy libraries with no code splitting, ignores keyboard navigation and screen-reader support. Coverage is an end in itself rather than a safety net. | Routine checks in the workflow: Lighthouse per feature, accessibility smoke tests (axe or Lighthouse audit, keyboard test), targeted tests on the critical flows. Knows the most common anti-patterns (huge images with no next-gen format, render-blocking web fonts, missing ARIA roles) and avoids them. | Actively defends performance and accessibility bars on the team. Establishes budgets (bundle size, LCP, INP) and audit routines. Educates colleagues with concrete examples and tooling setup. Can say no to a design mockup that cannot be built accessibly or performantly without a workaround. |
| Design system and composition | No clear component strategy; every new page introduces new patterns. Copies markup and styles instead of composing. Handovers with a pixel-pushers mentality and no understanding of tokens and variants. | Structures components to fit the team size: tokens for color, spacing and typography, a clear separation between primitives and product-specific components, cleanly typed props contracts. Handovers with documented edge cases (empty state, error state, loading state, responsive). | A reference on the team for design-system maintenance: documented conventions, a versioning pattern, close collaboration with designers on shared tokens, alignment via Storybook or comparable tooling. Can say no to designs that destabilize the system without becoming dogmatic. |
| Autonomy and resourcefulness | Blocks for hours on an unfamiliar topic without asking for help, or asks at the first obstacle. No structured debugging strategy. Never reads library source code. | Can diagnose independently on familiar topics; asks for help after investigating first (a summary of the problem, hypotheses, what has already been tried). Reads a library's source when needed. | High resourcefulness on unfamiliar topics: reads the source of dependencies, instruments the browser (Performance tab, memory snapshots, coverage tool), isolates root causes even in third-party code. Documents the findings for the team. |
| Communication and teamwork | Explains their own work poorly to non-technical people. Defensive in reviews and critique sessions. Works in a silo, shares little context. Systematic opposition to designers or PMs. | Can explain their work to design, PM or management in clear language. Takes reviews constructively. Shares context in team reviews and 1:1s. Can back a technical constraint with a sketch or prototype. | A bridge between frontend, design, backend and product. Facilitates technical debriefs and design handovers, 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 frontend modules plus the design-system library
- First documented 1:1 with the tech lead and with a designer on conventions, identified debt and priorities
- First substantial PR (UI bug fix or small component) with tests and accessibility check reviewed and merged
By day 60
- Delivered a complete frontend feature end to end (component, tests, accessibility, performance check, deployment) independently
- First PR review of a colleague with structured feedback on code quality, accessibility and performance, not just an approve click
- Facilitated the first independent handover session with design for a non-trivial component
- Wrote or updated documentation of a recently worked pattern in the design system
By day 90
- Regular delivery (1-2 PRs per week) with quality in code, accessibility and performance confirmed in review
- First technical decision made independently on an ambiguous topic (library choice, refactor of a main component, new pattern in the design system)
- Informal mentoring of a junior or new profile (pair programming, educational reviews on accessibility or performance)
- Formal review with the tech lead: ramp validated, development plan on 1-2 focus areas (e.g. deeper performance practice, building a component pattern, mentoring responsibility)
Common hiring mistakes for this role
Blending frontend with full-stack requirements
A job posting that asks for React, Node, Postgres, Kubernetes and Docker in the same profile does not describe a frontend role; it describes a full-stack role. Real frontend specialists filter themselves out, because they know they will not contribute meaningfully on backend topics. If you genuinely need depth in frontend (design-system maintenance, performance, accessibility, complex interactions), advertise the role as a frontend role and limit backend expectations to reading an API and writing the occasional glue layer. If you need full-stack, use the corresponding template.
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 frontend engineers clear specs, dedicated design-system teams 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 Frontend Engineer at an SMB almost never has to optimize a graph algorithm or reimplement a trie data structure. LeetCode-style tasks filter for academic profiles at the expense of operational ones (who can deliver a complete component independently). Prefer tasks that resemble daily work: extend a component with a feature, identify a performance hotspot, fix an accessibility bug. 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 in styling and polish), 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, ideally with a short README on the decisions made.
Treating accessibility and performance as nice-to-haves
In the German market, accessibility has been mandatory for many B2C and even B2B products since mid-2025 under the Barrierefreiheitsstärkungsgesetz (BFSG), with fines and litigation risk for violations. Performance directly affects conversion, activation and SEO. Anyone who treats both as an end-of-project task or blanket-delegates them to QA produces expensive rework. Probe concretely in the interview: what did the candidate measure and improve on accessibility and performance in their last feature? Profiles with no clear answer are a risk, especially at an SMB with no dedicated accessibility specialist.
Frequently asked questions
What does a Frontend Engineer earn at an SMB in Germany?
The reference range for a mid-level Frontend Engineer (3 to 6 years of experience) at a German SMB is 48 to 72 k€ gross fixed salary per year (median around 58 k€). Berlin, Munich and Hamburg in the SaaS/scale-up environment pull upward (68 to 85 k€); the classic Mittelstand and provincial locations trend lower. Specialization signals (a maintained design system, performance practice, accessibility experience) pull measurably 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 a Frontend, Backend and Full-Stack Engineer?
Frontend Engineers focus on the user interface: components and the design system, interaction, state management in the browser, accessibility (keyboard, screen reader, contrast), perceived and measured performance (LCP, INP, CLS), the build pipeline. 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; a pure frontend role is worth it once the product has a complex UI, needs a maintained design system, or has accessibility and performance as binding requirements. From teams of around 10 engineers onward, frontend specialization becomes clearly more relevant.
How long does it take to hire a Frontend 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 frontend profiles with a modern stack (React or Vue with TypeScript) and demonstrable specialization in design system, accessibility or performance. Timelines lengthen in late summer and around the turn of the year. Cutting below 50 days usually comes at the cost of the hands-on technical task or the system-design exercise and noticeably lowers hiring quality.
Do Frontend 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, Ironhack) once there are 3 to 5 years of solid production practice. A degree (applied-sciences computer science, a university computer-science degree, media design with a technical component) is reassuring for junior profiles but loses significance after 5 years of experience. Assess on the basis of the code, visible components or open-source contributions and problem-solving, not academic pedigree.
Which tools and stacks should a Frontend Engineer master in 2026?
At German tech SMBs in 2026, two stack families dominate: React with TypeScript (Next.js, Remix or plain Vite) and Vue with TypeScript (Nuxt). Expected mastery: components, hooks or composables, routing, data fetching (React Query or Pinia/Vuex), build tooling (Vite or Webpack), a CSS strategy (CSS Modules, Tailwind, vanilla-extract or equivalent), tests with Vitest or Jest and Testing Library, E2E with Playwright or Cypress. Also important: Storybook or Histoire for design-system work, accessibility tools (axe, Lighthouse, VoiceOver or NVDA), performance tools (Lighthouse, WebPageTest, RUM). AI-assisted tools (GitHub Copilot, Cursor, v0 for UI drafts) are increasingly integrated into the workflow in 2026; test in the interview how critically the profile uses these aids.
What legal requirements apply to frontend job postings in Germany?
Four 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), (4) BFSG compliance for affected B2C products (mandatory since 28 June 2025 under EN 301 549/WCAG 2.1 AA); the expectation is spreading even to products outside the mandatory scope, so describe the accessibility practice explicitly in the ad.