Full-Stack-Entwickler Interviewfragen & Antworten

Beispielantwort

I built a real-time activity feed for a project management tool. On the backend, I designed an event-sourcing system using PostgreSQL: every project action (task created, comment added, status changed) wrote an event record with timestamp, actor, action type, and metadata. I built a Node.js API endpoint with cursor-based pagination and WebSocket channels for real-time updates. On the frontend, I created a React component using a virtualized list (react-window) to handle feeds with 10K+ events without DOM performance issues. New events appeared in real-time via WebSocket with smooth insertion animations. I also added filtering by event type and person, which hit a dedicated PostgreSQL partial index. The feature shipped in 5 weeks and became the most-used page in the application — 78% of daily active users visited it at least once per session.

Beispielantwort

We needed pricing calculations for a quoting tool. The PM wanted instant price updates as users changed quantities and options. The initial implementation put all pricing logic in the React frontend for instant feedback. It worked until we discovered discrepancies — the frontend calculated $1,247 but the order confirmation API returned $1,251 due to different rounding approaches. I moved the canonical pricing logic to the backend API and created a lightweight frontend estimator that used simplified rules for instant feedback, clearly labeled as 'estimated price.' When the user finalized the quote, the backend calculated the exact price. This 'optimistic frontend, authoritative backend' pattern solved both the speed and accuracy requirements. The lesson: business-critical calculations must have a single source of truth on the backend. Frontend can approximate for UX, but the server decides.

Beispielantwort

Our team had separate frontend and backend repos with different deployment cycles. Frontend developers constantly waited for backend APIs to be ready before they could integrate. I introduced two changes. First, I set up a contract-first API development workflow using OpenAPI specs: we'd agree on the API contract before either side started building, then frontend and backend teams developed in parallel using the spec as the source of truth. I configured mock servers from the OpenAPI spec so the frontend could develop against realistic responses before the backend was ready. Second, I created a docker-compose setup that ran the entire stack locally with one command, including database seeding and mock external services. Integration issues that previously surfaced in staging now appeared on developer machines. The result: sprint completion rate improved from 68% to 91% because cross-team dependencies stopped blocking progress.

Beispielantwort

We migrated user data from Firebase to PostgreSQL while keeping the React app running. The challenge: 200K users with nested document structures that needed to be normalized into relational tables. I built a migration pipeline in three phases. Phase 1: schema design — I mapped Firebase document structures to PostgreSQL tables, normalizing nested arrays into junction tables. Phase 2: parallel operation — the app wrote to both Firebase and PostgreSQL simultaneously using a middleware layer. Reads stayed on Firebase. Phase 3: validation and switchover — I wrote a reconciliation script that compared 10K random records between both databases nightly. After 2 weeks with zero discrepancies, we switched reads to PostgreSQL and turned off Firebase writes. Total migration time: 4 weeks with zero user-facing downtime. The reconciliation script caught 3 edge cases in the dual-write logic that would have caused data loss in a big-bang migration.

Beispielantwort

The core challenge is conflict resolution — multiple users editing simultaneously. I'd use Operational Transformation (OT) or CRDTs (Conflict-free Replicated Data Types). CRDTs are more modern and don't require a central server for conflict resolution, making them more resilient. Architecture: the frontend uses a rich text editor (Tiptap/ProseMirror) with a CRDT library (Yjs) that handles local edits optimistically. Changes propagate via WebSocket to a Node.js server that broadcasts to all connected clients. The server also persists the document state to PostgreSQL as a serialized CRDT on every change (debounced to avoid excessive writes). For presence: each client sends cursor position and selection via the WebSocket channel, and other clients render colored cursors. For offline support: Yjs handles merging when a client reconnects, applying their offline changes against the current document state. Scaling considerations: use Redis Pub/Sub to broadcast changes across multiple server instances, partition WebSocket connections by document ID, and implement lazy loading for very long documents.

Beispielantwort

Client-side rendering (CSR): the server sends a minimal HTML shell, JavaScript downloads and renders the page in the browser. Pros: smooth page transitions, reduced server load, good for authenticated dashboards. Cons: slower initial load (blank page until JS executes), poor SEO (search engines may not execute JS), worse Core Web Vitals. Server-side rendering (SSR): the server renders the full HTML for each request. Pros: fast first contentful paint, excellent SEO, works without JavaScript. Cons: higher server load, full page reloads feel slower, harder to implement interactive features. I choose CSR for authenticated applications (dashboards, admin panels, SaaS tools) where SEO doesn't matter and interactivity is primary. I choose SSR for public-facing content (marketing sites, blogs, e-commerce product pages) where SEO and initial load time are critical. Modern frameworks (Next.js, Nuxt, Remix) let you mix both: SSR for the initial load with client-side hydration for interactivity. Static Site Generation (SSG) is even better for content that doesn't change per-request.

Beispielantwort

I implement JWT-based authentication with a specific token strategy. The access token (JWT) is short-lived (15 minutes), contains user identity and roles, and is sent in the Authorization header. The refresh token is long-lived (7 days), opaque (not JWT), stored in an HTTP-only Secure SameSite cookie, and mapped to a database record so it can be revoked. The flow: user logs in, server validates credentials, returns access token in the response body and sets refresh token cookie. The frontend stores the access token in memory (not localStorage — XSS vulnerable). When the access token expires, the frontend silently calls the refresh endpoint, which validates the cookie and returns a new access token. On logout, both tokens are invalidated server-side. For OAuth (Google, GitHub), I use the authorization code flow: redirect to provider, receive code on callback, exchange code for provider tokens server-side, create or link the user account, and issue our own JWT. I never trust client-side tokens from OAuth providers directly.

Beispielantwort

I implement error handling at four layers. Backend API: all errors return consistent JSON format with status code, error code (machine-readable), message (human-readable), and optional details field. I use HTTP status codes correctly: 400 for validation, 401 for auth, 403 for authorization, 404 for not found, 409 for conflicts, 500 for server errors. I never expose stack traces or internal details in production responses. Backend service layer: try/catch around external calls and database operations, with specific error types (NotFoundError, ValidationError, ConflictError) that map to HTTP responses. Unhandled errors hit a global error handler that logs the full error and returns a generic 500. Frontend API layer: a centralized API client that handles common errors: 401 triggers token refresh, 403 shows access denied, 429 shows rate limit message, 500 shows a generic error with retry option. Frontend UI: error boundaries catch rendering errors, toast notifications for non-blocking errors, and inline validation for form errors. Every error is logged — server errors to structured logging (Pino), client errors to an error tracking service (Sentry).

Beispielantwort

I'd start with a monolith unless there's a compelling reason not to. Microservices add operational complexity (networking, deployment, monitoring, debugging distributed systems) that's only justified at certain team sizes and scale requirements. I'd choose a monolith when: the team is under 10 engineers, the product is pre-product-market-fit (rapid iteration matters more than scalability), and there's no immediate need for independent scaling or deployment of specific components. I'd choose microservices when: different components have vastly different scaling needs (a CPU-intensive image processor vs. a lightweight API), teams need to deploy independently (10+ engineers, multiple squads), or the domain naturally decomposes into distinct bounded contexts. The pragmatic middle ground: build a modular monolith with clear internal boundaries. If a module needs to become a service later, the separation is clean. This avoids distributed system complexity while maintaining the optionality to split when the need is real.

Beispielantwort

I'd prototype it first rather than speculating. I'd build the animation using CSS transforms and opacity (which are GPU-accelerated and don't trigger layout reflow) and test on a representative mid-range Android device — not my MacBook Pro. If it runs at 60fps on that device, ship it. If not, I'd diagnose the bottleneck using Chrome DevTools Performance panel: is it layout thrashing, paint operations, or main thread blocking? Then I'd propose alternatives based on the specific issue. Maybe we can use the Web Animations API for better frame scheduling. Maybe we reduce the number of animated elements. Maybe we use will-change to promote layers to the GPU. Maybe the animation plays only once instead of continuously. I'd present the designer with a spectrum: 'Here's the full animation at 30fps on mobile. Here's a simplified version at 60fps. Here's a static fallback.' Let them choose the tradeoff. Often designers prefer the smooth simple version over the janky complex one.

Beispielantwort

I'd first understand why: are these calls independent or do they have dependencies? Are they all necessary for the initial render? My optimization strategies in order of impact: First, identify calls that aren't needed for initial render and defer them — load below-the-fold data on scroll, load secondary panels on interaction. This might cut initial calls from 15 to 5. Second, batch related calls: if we're fetching user profile, user settings, and user notifications separately, create a BFF (Backend for Frontend) endpoint that returns all user data in one call. Third, use GraphQL or a composite API pattern if the fragmentation is a systemic problem — let the frontend request exactly the data it needs in one call. Fourth, cache aggressively: use React Query's stale-while-revalidate pattern for data that doesn't change often. Fifth, prefetch: if the user is likely to navigate to page B from page A, start fetching page B's data on hover. I'd measure the impact: total page load time, Time to Interactive, and number of network requests.

Beispielantwort

I'd quantify the debt rather than just labeling it 'technical debt.' What specifically will break or become harder? How many future features are affected? What's the maintenance cost over 12 months? Then I'd propose alternatives. Option A: build it the 'right' way — takes longer but adds no debt. Option B: build the client's version behind a feature flag as a custom extension, with a plan to generalize it when other clients need similar functionality. Option C: build the quick version with a documented debt item, committed timeline for refactoring, and acceptance from the product owner that this creates a maintenance cost. I'd present the tradeoff clearly: 'We can ship in 2 weeks with approach C, but it will slow down Feature X next quarter by 1 week and Feature Y by 3 days.' Usually when you quantify the downstream cost, the decision becomes obvious. If the business decides the speed is worth the debt, that's a legitimate decision — but it should be explicit.