Blockchain Developer Vorstellungsgespräch: Fragen & Antworten (mit Musterantworten)

Musterantwort

Ich beginne mit einer klaren Spezifikation der Zustände und Invarianten und halte den Contract bewusst einfach, da Komplexität die Angriffsfläche erhöht. Ich nutze etablierte, geprüfte Bibliotheken wie OpenZeppelin statt eigener kryptografischer Implementierungen und schreibe umfangreiche Tests inklusive Edge Cases. Vor dem Deployment lasse ich den Code prüfen und nutze Tools wie Slither für statische Analyse. Da Contracts nach Deployment unveränderlich sind, plane ich Sicherheit von Anfang an statt nachträglich.

Musterantwort

Ich minimiere teure Storage-Operationen, da das Schreiben in den Speicher mit Abstand am meisten Gas kostet, und nutze stattdessen Memory oder Events, wo möglich. Ich vermeide unnötige Schleifen über große Datenmengen on-chain und packe Variablen sinnvoll, um Storage-Slots zu sparen. Berechnungen verlagere ich nach Möglichkeit off-chain und prüfe nur die Ergebnisse on-chain. So habe ich einmal die Transaktionskosten einer Funktion durch Storage-Packing deutlich gesenkt.

Musterantwort

Ich verfolge EIPs und die Dokumentation zentraler Protokolle sowie Audit-Berichte bekannter Sicherheitsfirmen, um aus realen Schwachstellen zu lernen. Ich experimentiere mit neuen Tools und Standards in Testnetzen, bevor ich sie produktiv einsetze. Außerdem analysiere ich Post-Mortems großer Hacks, da daraus die wertvollsten Lektionen kommen. So kann ich Risiken einschätzen, statt Trends blind zu folgen.

Musterantwort

Ich konzentriere mich auf das konkrete Problem, etwa fehlendes Vertrauen zwischen Parteien oder mangelnde Nachvollziehbarkeit, und erkläre, wie Dezentralität und Unveränderlichkeit es lösen. Ich vermeide Fachjargon und nutze Beispiele aus dem Geschäftskontext der Stakeholder. Wichtig ist mir, auch ehrlich zu sagen, wann eine Blockchain nicht die richtige Lösung ist. So vermeide ich überzogene Erwartungen und schaffe realistische Begeisterung.

Musterantwort

Mich reizt, dass Sie an einer realen Anwendung mit echtem Nutzerwert arbeiten und nicht nur an Spekulation, was im Web3-Bereich nicht selbstverständlich ist. Ihre Ausschreibung erwähnt einen Fokus auf auditierte, sichere Contracts, und genau dieses Qualitätsdenken teile ich. Ich möchte zu einem Produkt beitragen, das Dezentralität sinnvoll einsetzt. Außerdem passt Ihr Stack rund um Solidity und Ethereum gut zu meiner Erfahrung.

Bei einem Reentrancy-Angriff ruft ein externer Contract während eines noch nicht abgeschlossenen Aufrufs erneut die ursprüngliche Funktion auf, etwa um mehrfach Gelder abzuheben. Ich verhindere ihn mit dem Checks-Effects-Interactions-Muster, bei dem Zustände vor externen Aufrufen aktualisiert werden, sowie mit einem Reentrancy-Guard. Der bekannte DAO-Hack beruhte genau auf dieser Schwachstelle.

Bei Proof of Work konkurrieren Miner über Rechenleistung, um Blöcke zu validieren, was sehr energieintensiv ist. Bei Proof of Stake werden Validatoren anhand ihres eingesetzten Einsatzes ausgewählt, was deutlich weniger Energie verbraucht und ökonomische Strafen für Fehlverhalten ermöglicht. Ethereum ist mit dem Merge von Proof of Work auf Proof of Stake umgestiegen.

Eine Coin ist die native Währung einer eigenen Blockchain, etwa Ether auf Ethereum, und dient meist zur Bezahlung von Transaktionsgebühren. Ein Token wird über einen Smart Contract auf einer bestehenden Blockchain ausgegeben, etwa nach dem ERC-20-Standard. Tokens nutzen also die Infrastruktur und Sicherheit der zugrunde liegenden Chain.

ERC-20 definiert eine einheitliche Schnittstelle für fungible Tokens auf Ethereum, mit Funktionen wie transfer, balanceOf und approve. Durch diese Standardisierung können Wallets, Börsen und andere Contracts beliebige ERC-20-Tokens einheitlich behandeln. Das fördert Interoperabilität im gesamten Ökosystem.

Eine Public Blockchain wie Ethereum ist offen, jeder kann teilnehmen, lesen und validieren, was maximale Dezentralität bietet. Eine Permissioned Blockchain beschränkt Teilnahme und Validierung auf autorisierte Akteure, was Performance und Kontrolle erhöht, aber Dezentralität reduziert. Unternehmen nutzen Permissioned-Varianten oft für interne, vertrauensbeschränkte Anwendungsfälle.

Bei einem Review eines Staking-Contracts fiel mir eine ungeschützte externe Auszahlungsfunktion auf (Situation). Ich sollte das Risiko bewerten und beheben (Task). Ich habe eine Reentrancy-Schwachstelle nachgewiesen, das Checks-Effects-Interactions-Muster eingeführt und einen Guard ergänzt sowie Tests dafür geschrieben (Action). Die Lücke wurde vor dem Deployment geschlossen und damit ein potenzieller Verlust von Nutzergeldern verhindert (Result).

Eine Funktion war für Nutzer wegen hoher Gas-Gebühren praktisch unbenutzbar (Situation). Ich sollte die Kosten deutlich senken (Task). Ich habe die teure On-Chain-Schleife durch Off-Chain-Berechnung mit On-Chain-Verifikation ersetzt und Storage-Variablen gepackt (Action). Die Transaktionskosten sanken erheblich und die Funktion wurde wieder aktiv genutzt (Result).

Nach einem Mainnet-Deployment zeigte sich ein Fehler in der Belohnungsberechnung (Situation). Da Contracts unveränderlich sind, musste ich schnell und überlegt handeln (Task). Ich habe über die vorhandene Pausenfunktion den Contract gestoppt, mit dem Team eine geprüfte Migrationsstrategie auf eine korrigierte Version erstellt und Nutzer transparent informiert (Action). Die Mittel blieben sicher und die Migration verlief ohne Verluste (Result).

Ein Stakeholder wollte aus Trendgründen eine Blockchain für interne Datenspeicherung nutzen (Situation). Ich sollte ehrlich die Eignung bewerten (Task). Ich habe erklärt, dass eine zentrale Datenbank bei einem einzigen vertrauenswürdigen Betreiber günstiger, schneller und einfacher ist, und den Mehrwert kritisch hinterfragt (Action). Das Projekt wählte die passendere Lösung und sparte unnötige Komplexität und Kosten (Result).