Zum Inhalt springen

Technische Interviews als Senior Engineer meistern

Was sich in technischen Interviews auf Senior-Level ändert: System-Design, Verhaltensbeispiele und der Wandel vom Kompetenz- zum Urteilsnachweis.

6 Min. Lesezeit
Whiteboard mit einem Systemarchitektur-Diagramm während eines technischen Interviews

Das Senior-Interview ist ein anderes Spiel

Junior- und Mid-Level-Interviews testen, ob du programmieren kannst. Senior-Interviews testen, ob du denken kannst. Der Coding-Anteil existiert weiterhin, verliert aber an Gewicht. System-Design, architektonische Entscheidungsfindung, teamübergreifende Kommunikation und technische Führung rücken in den Vordergrund.

Dieser Wandel überrascht viele erfahrene Ingenieure. Man baut seit Jahren Systeme, aber ein vages Problem unter Zeitdruck am Whiteboard zu zerlegen, ist eine andere Fähigkeit. Der Ingenieur, der im Alltag elegante Systeme entwirft, kann im Interview stolpern, weil er nie geübt hat, seinen Entscheidungsprozess laut zu artikulieren.

Vorbereitung auf Senior-Level bedeutet weniger, Algorithmen auswendig zu lernen, und mehr, zu strukturieren, wie du komplexe Ideen vermittelst. Dieser Leitfaden behandelt die praktische Vorbereitung, auf die es wirklich ankommt.

System-Design: Struktur vor Lösungen

Die System-Design-Runde ist das Herzstück des Senior-Interviews. Du bekommst ein vages Problem gestellt – „entwirf einen URL-Shortener“, „entwirf ein Echtzeit-Chatsystem“ – und sollst dich in 45 Minuten von den Anforderungen bis zur Architektur vorarbeiten.

Der Fehler besteht darin, sofort zu Lösungen zu springen. Getestet wird strukturiertes Denken unter Unsicherheit.

tstypescript
// A framework for approaching system design interviews
interface DesignFramework {
  step: string;
  timeAllocation: string;
  activities: string[];
}
 
const systemDesignFlow: DesignFramework[] = [
  {
    step: "Requirements Clarification",
    timeAllocation: "5-7 minutes",
    activities: [
      "Identify functional requirements (what the system does)",
      "Identify non-functional requirements (scale, latency, consistency)",
      "Clarify scope: what's in, what's out",
      "Establish rough numbers: DAU, QPS, storage",
    ],
  },
  {
    step: "High-Level Design",
    timeAllocation: "10-12 minutes",
    activities: [
      "Draw core components and their interactions",
      "Identify data flow: write path and read path",
      "Choose communication patterns: sync, async, event-driven",
      "Call out key technology choices and WHY",
    ],
  },
  {
    step: "Detailed Design",
    timeAllocation: "12-15 minutes",
    activities: [
      "Deep dive into 2-3 critical components",
      "Data model and schema design",
      "API design for key endpoints",
      "Caching strategy and invalidation",
    ],
  },
  {
    step: "Scaling and Tradeoffs",
    timeAllocation: "8-10 minutes",
    activities: [
      "Identify bottlenecks under load",
      "Horizontal scaling strategy",
      "Database partitioning / sharding approach",
      "Failure modes and mitigation",
    ],
  },
];

Dem Interviewer ist weniger wichtig, ob du dich für Redis oder Memcached entscheidest, sondern ob du begründen kannst, warum du dich angesichts der gegebenen Einschränkungen für das eine statt das andere entscheiden würdest. Jede Entscheidung sollte mit einer Kompromiss-Aussage einhergehen: „Ich habe mich für X statt Y entschieden, wegen Z, auf Kosten von W.“

Überschlagsrechnungen

Schätzfragen sind keine Fangfragen. Sie testen, ob du quantitativ über Systeme nachdenken kannst. Übe sie, bis sie dir in Fleisch und Blut übergehen.

tstypescript
// Common estimation building blocks
const estimationCheatSheet = {
  storage: {
    textMessage: "~100 bytes",
    tweet: "~300 bytes (with metadata)",
    photo: "~200 KB (compressed)",
    video1Min: "~10 MB (compressed)",
    userProfile: "~1 KB",
  },
  throughput: {
    ssdRead: "~100K-500K IOPS",
    hddRead: "~100-200 IOPS",
    networkWithinDC: "~1-10 Gbps",
    databaseQuerySimple: "~10K QPS per node",
    cacheRead: "~100K-1M QPS (Redis)",
  },
  latency: {
    l1Cache: "~1 ns",
    ram: "~100 ns",
    ssdRandom: "~100 μs",
    networkWithinDC: "~0.5 ms",
    networkCrossContinent: "~100 ms",
    databaseQuery: "~1-10 ms",
  },
  scale: {
    secondsPerDay: 86400,
    secondsPerMonth: "~2.5M",
    bytesPerGB: "~1e9",
    bytesPerTB: "~1e12",
  },
};
 
// Example estimation: "Design a system that handles 100M DAU"
function estimateLoad(): void {
  const dau = 100_000_000;
  const actionsPerUser = 10;
  const dailyActions = dau * actionsPerUser; // 1 billion/day
  const qps = dailyActions / 86400; // ~11,574 QPS
  const peakQps = qps * 3; // ~35K QPS (3x peak multiplier)
  const storagePerAction = 500; // bytes
  const dailyStorage = dailyActions * storagePerAction; // 500 GB/day
  const yearlyStorage = dailyStorage * 365; // ~180 TB/year
}

Rechne die Kalkulation laut vor. Der Interviewer will deine Denkweise sehen, nicht nur das Endergebnis. Runde großzügig – Präzision spielt keine Rolle, die Größenordnung schon.

Verhaltensfragen: das STAR-L-Framework

Verhaltensbezogene Interviews auf Senior-Level bewerten Führungsqualität, Konfliktlösung und technische Entscheidungsfindung. Das STAR-Framework (Situation, Task, Action, Result) ist der Standard, doch auf Senior-Level kommt ein L hinzu: Learnings, die gezogenen Lehren.

tstypescript
// ❌ Bad: Vague, unfocused answer
const badAnswer = {
  question: "Tell me about a time you disagreed with a technical decision",
  response:
    "I disagreed with my manager about using microservices. " +
    "I thought we should use a monolith. We discussed it and " +
    "eventually went with microservices. It worked out okay.",
};
tstypescript
// ✅ Good: Structured STAR-L response
interface BehavioralResponse {
  situation: string;
  task: string;
  action: string;
  result: string;
  learnings: string;
}
 
const strongAnswer: BehavioralResponse = {
  situation:
    "Our team of 4 was building a new payment processing service. " +
    "The tech lead proposed splitting it into 6 microservices from " +
    "day one. We had no existing infrastructure for service orchestration.",
  task:
    "I needed to advocate for a simpler architecture without " +
    "undermining the tech lead's authority or creating team friction.",
  action:
    "I wrote a one-page RFC comparing both approaches with specific " +
    "tradeoffs: deployment complexity, latency overhead, debugging " +
    "difficulty. I proposed starting as a modular monolith with clean " +
    "module boundaries that could be extracted later. I presented it " +
    "as 'how do we get to market fastest with the option to split later' " +
    "rather than 'your idea is wrong.'",
  result:
    "We shipped the monolith in 3 months instead of the estimated 6 " +
    "for microservices. After 8 months, we extracted the notification " +
    "module into its own service when load patterns justified it. " +
    "The other modules stayed monolithic.",
  learnings:
    "Framing matters more than being right. Writing the RFC forced me " +
    "to quantify my intuition, which made the conversation productive " +
    "instead of opinion-based. I also learned that 'defer the decision' " +
    "is often the best architecture advice.",
};

Bereite 8 bis 10 Geschichten vor, die Folgendes abdecken: technische Meinungsverschiedenheiten, gescheiterte Projekte, Mentoring-Wirkung, teamübergreifende Zusammenarbeit, den Umgang mit Unsicherheit, Liefern unter Druck und Einfluss ohne formale Autorität. Jede Geschichte sollte sich an verschiedene Fragestellungen anpassen lassen.

Die Coding-Runde auf Senior-Level

Du wirst weiterhin programmieren. Aber die Erwartungen verschieben sich. Sauberer, funktionierender Code ist nur die Grundvoraussetzung. Der Interviewer achtet darauf, wie du das Problem zerlegst, mit Randfällen umgehst, deinen Ansatz kommunizierst und deine Lösung testest.

tstypescript
// The approach matters more than speed
// Demonstrate: problem decomposition, edge case handling, testing mindset
 
// Example: Design a rate limiter
interface RateLimiterConfig {
  maxRequests: number;
  windowMs: number;
}
 
class SlidingWindowRateLimiter {
  private windows: Map<string, number[]> = new Map();
  private config: RateLimiterConfig;
 
  constructor(config: RateLimiterConfig) {
    this.config = config;
  }
 
  isAllowed(clientId: string): boolean {
    const now = Date.now();
    const windowStart = now - this.config.windowMs;
 
    // Get or initialize request timestamps for this client
    let timestamps = this.windows.get(clientId) || [];
 
    // Remove expired timestamps
    timestamps = timestamps.filter((t) => t > windowStart);
 
    if (timestamps.length >= this.config.maxRequests) {
      this.windows.set(clientId, timestamps);
      return false;
    }
 
    timestamps.push(now);
    this.windows.set(clientId, timestamps);
    return true;
  }
 
  // Production consideration: memory cleanup
  cleanup(): void {
    const now = Date.now();
    for (const [clientId, timestamps] of this.windows) {
      const valid = timestamps.filter(
        (t) => t > now - this.config.windowMs
      );
      if (valid.length === 0) {
        this.windows.delete(clientId);
      } else {
        this.windows.set(clientId, valid);
      }
    }
  }
}
 
// Verbalize tradeoffs while coding:
// "I'm using a sliding window for accuracy. A fixed window would be simpler
// but allows 2x the rate at window boundaries. The tradeoff is memory —
// we store individual timestamps instead of a counter."

Sprich, während du programmierst. Erkläre, was du vorhast, bevor du es tust. Wenn dir ein Randfall auffällt, sprich ihn explizit an: „Ich muss den Fall behandeln, in dem …“ Das zeigt genau das diagnostische Denken, das Senior-Ingenieure von reinen Codeschreibern unterscheidet.

Fragen an den Interviewer

Die Fragen, die du stellst, verraten mehr über dein Senioritätslevel als die Antworten, die du gibst. Junior-Kandidaten fragen nach dem Tech-Stack und den Benefits. Senior-Kandidaten fragen nach der Engineering-Kultur, den Entscheidungsprozessen und den organisatorischen Herausforderungen.

tstypescript
const seniorQuestions: string[] = [
  // Engineering culture
  "How do architectural decisions get made here? Is there an RFC process?",
  "What does the on-call rotation look like, and how are incidents handled?",
 
  // Team dynamics
  "How much autonomy do engineers have in choosing technical approaches?",
  "What's the ratio of planned work to interrupt-driven work?",
 
  // Growth and impact
  "What does a successful first 90 days look like for this role?",
  "Can you describe a recent technical decision the team made that was controversial?",
 
  // Organizational health
  "How does the engineering team handle technical debt?",
  "What's the deployment frequency, and what does the release process look like?",
];

Diese Fragen helfen dir auch einzuschätzen, ob das Unternehmen zu dir passt. Ein Unternehmen, das die Frage „Wie geht ihr mit technischen Schulden um?“ nicht beantworten kann, verrät dir etwas Wichtiges über seine Engineering-Reife.

Die Meta-Fähigkeit: das Interview als Zusammenarbeit

Der wichtigste Mentalitätswandel auf Senior-Level besteht darin, das Interview als gemeinsame Design-Sitzung zu behandeln, nicht als Prüfung. Du beweist nicht, dass du das Problem lösen kannst – du zeigst, wie du im Arbeitsalltag daran herangehen würdest.

Stelle klärende Fragen. Schlage Alternativen vor und diskutiere die Kompromisse. Sprich Unsicherheit offen an: „Ich bin mir beim besten Ansatz hier nicht sicher, aber mein Instinkt sagt X, wegen Y.“ Interviewer bei Unternehmen auf Senior-Niveau bewerten, ob sie mit dir zusammenarbeiten möchten – nicht, ob du die optimale Lösung auswendig gelernt hast.

Die Ingenieure, die ein Senior-Angebot bekommen, sind nicht die mit den perfekten Antworten. Es sind diejenigen, bei denen der Interviewer das Gefühl hat, gerade eine produktive Design-Diskussion mit einem zukünftigen Kollegen geführt zu haben.

Die wichtigsten Erkenntnisse

Technische Interviews auf Senior-Level testen Urteilsvermögen, Kommunikation und Führungsstärke – nicht nur die Fähigkeit zu programmieren. Vorbereitung auf System-Design bedeutet, strukturierte Zerlegung laut zu üben, nicht Architekturen auswendig zu lernen. Vorbereitung auf Verhaltensfragen bedeutet, konkrete, quantifizierte Geschichten im STAR-L-Format parat zu haben.

Die Coding-Runde zählt weiterhin, aber die Messlatte liegt anders: sauberer Code, verbalisiertes Denken, proaktives Erkennen von Randfällen und ein Bewusstsein für den Produktivbetrieb. Und die Fragen, die du am Ende stellst, sind deine Chance, Senior-Level-Denken über Engineering-Kultur und organisatorische Gesundheit zu zeigen.

Vorbereitung summiert sich. Verbringe weniger Zeit mit schweren LeetCode-Aufgaben und mehr Zeit damit, architektonische Kompromisse zu artikulieren, überzeugende Geschichten über deine Erfahrung zu erzählen und den kollaborativen Rhythmus eines technischen Gesprächs auf Senior-Level zu üben.

Wilfredo Rujel

Wilfredo Rujel

Full-Stack-Softwareentwickler

Diesen Beitrag teilenX