Angular Developer – Enterprise SPA

About the Role

We’re hiring an Angular Developer to help build and maintain large-scale enterprise single-page applications. The work involves real technical depth — performance, maintainability, accessibility, and well-structured architecture. You’ll be part of a cross-functional product team that cares about engineering quality and straightforward collaboration. What You’ll Work On Build and maintain Angular applications used daily by enterprise clients. Implement modern state management and reactive patterns with NgRx and RxJS (or Signals, where relevant). Write clean, testable TypeScript following strict type safety and code review standards. Work closely with design to translate UI/UX into accessible, consistent components. Maintain a shared design system using Storybook and Angular Material (with optional theming). Optimize for performance — from bundle sizes and lazy loading to runtime efficiency. Ensure conformance with WCAG 2.2 accessibility guidelines. Integrate APIs built with REST and GraphQL. Contribute to automated tests (Jest, Cypress, Playwright) and CI/CD pipelines. Example of the Stack Angular 16+, TypeScript, RxJS / NgRx / Signals SCSS / Tailwind, Angular Material, Storybook Jest / Cypress / Playwright Vite / Webpack, Docker, GitHub Actions REST / GraphQL Accessibility audits via Lighthouse and axe-core What We’d Like to See 3+ years of experience building production-grade SPAs in Angular. Good understanding of component-driven architecture and modular design. Confidence working with reactive state and TypeScript at scale. Familiarity with accessibility standards and practical implementation. Clear understanding of testing, deployment, and version control workflows. Ability to collaborate with both developers and designers effectively.

Nice to Have

Experience with monorepo setups (NX, Turborepo). Familiarity with SSR or static rendering using Angular Universal or AnalogJS. Interest in frontend tooling, design tokens, or performance monitoring. What You Can Expect Established engineering culture that values maintainable solutions over quick fixes. Up-to-date tech stack and clean CI/CD setup. Cooperative, no-nonsense environment where good work is recognized. Time and space to do things properly — from architecture to documentation. My Transparency Disclaimer: 🤖 How I Use AI in This Hiring Process — and What That Means for You I use Teamtailor Co-pilot, an AI-powered assistant built into my ATS, to help me process applications faster. I want to be explicit about what it does and what I do myself, because you deserve to know exactly how you're being evaluated. What Co-pilot does: Reviews your CV and application answers against predefined criteria Generates a CV summary so I can orient quickly before reading in full Flags how your profile maps against must-have requirements What I do: I personally read every single application. No one gets rejected by an algorithm alone. I make all decisions — Co-pilot surfaces signals, I draw conclusions. I reply to every candidate, whether you progress or not. 🚨 Automated Screening Criteria — All 5 Are Non-Negotiable Co-pilot screens every application against the following criteria automatically. These are not "nice to haves" or weighted preferences — if your application doesn't demonstrate all 5, it will not progress to the reviewing stage. I'm being explicit about this so you can self-select honestly before applying. That's better for both of us. 1. NgRx or RxJS experience You must have hands-on, production-level experience with reactive state management in Angular — NgRx, RxJS-based patterns, or Signals. Reading about it doesn't count. I'm looking for applied exposure in real projects. 2. Angular experience You must have meaningful professional experience building and maintaining Angular applications. Framework familiarity is table stakes here; I'm assessing depth, not exposure. 3. TypeScript experience You must actively write TypeScript, not just tolerate it. This role involves a codebase where TypeScript discipline matters — types, interfaces, generics in practice. 4. Storybook or Design System maintenance You must have real experience with Storybook or have contributed to maintaining a component library or design system. UI documentation is treated as an engineering deliverable on this team, not an afterthought. 5. Accessibility implementation You must have implemented web accessibility in shipped work. This is a hard requirement. Projects where accessibility was theoretically considered but not practically applied don't satisfy this criterion. ⚠️ If you're missing even one of these five, please don't apply hoping it goes unnoticed. I'll see it, and I'll tell you honestly why it didn't work — but it's a better use of your time to apply when you genuinely meet all five. 🎯 Application Questions — Answer Them Honestly Your responses to the 10 mandatory questions are the main input at the screening stage. Co-pilot reads them. I read them too. There's no right answer to game — I'm looking for accuracy, not optimisation. Here's exactly what I'm asking and why: State management libraries used in production (NgRx, RxJS, Signals, Akita, None) — to assess which reactive patterns you've actually shipped with CI/CD pipeline confidence (scale 1–5) — to understand how independently you can own pipelines, not just use them Frontend testing tools actively used (Jest, Cypress, Playwright, Karma/Jasmine, None) — testing culture is part of this role's expectations GraphQL integration in Angular — a direct question; carries real weight in the assessment Years of professional Angular experience — context for everything else Version control systems used — baseline signal; Git experience is expected Lazy loading familiarity (scale 1–5) — angular architecture awareness at module and component level Build tooling: Vite or Webpack in Angular projects — distance from modern Angular workflows matters Storybook experience (scale 1–5) — because we treat component documentation as a deliverable Angular Material components customised with SCSS/theming — practical evidence of frontend styling depth 🧠 What I Assess in the Interview If your application progresses, the interview goes deeper into areas that can't be evaluated from a form alone. Here's what I'll be looking at: Technical depth — real trade-offs, not textbook answers I'll ask about architecture decisions you've made, why you made them, and what you'd do differently. I'm not looking for perfect answers — I'm looking for how you think when things get complicated. State management under pressure How you reason about NgRx vs Signals vs RxJS in different contexts, and where you've seen each approach break down. Testing philosophy Not just which tools you've used, but how embedded testing is in your actual workflow. Do you write tests because you're told to, or because you'd feel unsafe without them? Build pipeline ownership Whether you've configured and maintained CI/CD pipelines yourself, or whether you've operated within what someone else built. Component architecture and documentation How you think about Storybook as a living contract, not a documentation checkbox. Accessibility approach in practice How you've made accessibility decisions under real project constraints — timelines, legacy code, team pushback. Work artifacts I'll ask to see real things: code samples, a repository, a Storybook instance, anything that shows how you build. It doesn't need to be polished. It needs to be real. 🔄 The Process in Full Inbox → Reviewing → Interview → Offer Every stage has a human decision point. Co-pilot assists at the Inbox stage. I take over from there. Transparency commitment: I reply to every applicant. If you don't progress, I'll tell you why as specifically as I can — not a template, a real note. You'll also receive a short NPS survey after the process. I read every response, and it directly shapes how I run this. — Hubert, Tech Recruiter @ WhyHireWrong? Apply To This Job