Interviewfrage für Softwareentwickler

Ein Service, der gestern noch in Ordnung war, hat jetzt eine p99-Latenz von vier Sekunden. Wie debuggst du das?

Worauf der Interviewer abzielt, wie du deine Antwort aufbaust und ein gesprochenes Beispiel zum Anpassen.

Kurzantwort

Grenz es zuerst ein: jeder Endpoint oder einer, alle User oder ein Tenant, und wann genau hat es angefangen. Leg diesen Zeitstempel neben Deploys, Flag-Umschaltungen und Traffic-Änderungen. Dann arbeite dich mit der Telemetrie nach unten, die du schon hast: Traces, um den gewachsenen Span zu finden, Slow-Query-Logs der Datenbank, Sättigung des Connection Pools, CPU und Speicher des Hosts. Mitigier zuerst, ob per Rollback oder Lastabwurf, und such die Ursache danach.

Warum Interviewer das fragen

Unter Druck zu debuggen ist der Großteil von Senior Engineering, und der Interviewer will Methode statt Raten. Er hört auf Fragen zur Eingrenzung vor Hypothesen, auf die Nutzung von Telemetrie, die längst da sein sollte, auf die Korrelation mit Änderungen, und auf das Urteilsvermögen, vor der Untersuchung zu mitigieren. Wer sofort anfängt, Ursachen zu raten, macht das im echten Incident genauso.

So baust du deine Antwort auf

  • Grenz das Problem ein, bevor du eine Theorie bildest.
  • Korrelier die Startzeit mit Deploys und Traffic.
  • Folg dem Trace zum langsamsten Span.
  • Mitigier zuerst, jag die Ursache danach.

Beispielantwort

Gesprochenes Beispiel, erste Person

Zuerst will ich Grenzen, weil sie den Suchraum schnell verkleinern. Ist es ein Endpoint oder alle, eine Region, ein Tenant, und wann hat es angefangen? Dann lege ich diesen Zeitstempel neben Deploys, Feature-Flag-Umschaltungen und Config-Änderungen, denn meistens hat sich etwas geändert und die Antwort liegt genau da. Wenn sich auf unserer Seite nichts geändert hat, gehe ich zu den Traces und suche, welcher Span gewachsen ist, was mir sofort sagt, ob es an uns liegt, an der Datenbank oder an einem nachgelagerten Aufruf. Die Datenbank ist der übliche Verdächtige: eine Query, die bei einer Million Zeilen in Ordnung war, ist es bei zehn Millionen nicht mehr, oder ein Index fehlt, oder der Pool ist gesättigt und die Zeit geht fürs Warten auf eine Verbindung drauf statt für die Query selbst. Letzteres ist heimtückisch, weil jede einzelne Query isoliert weiterhin schnell aussieht. Und während ich das alles mache, nehme ich eine offensichtliche Mitigation wie das Zurückrollen des letzten Deploys zuerst mit. Kunden interessiert die Latenz, nicht meine Erklärung.

Steht dieses Vorstellungsgespräch bald an? GhostPilot hört bei deinem Live-Call mit, erkennt die Frage in dem Moment, in dem sie gestellt wird, und bringt dir eine strukturierte Antwort in Echtzeit auf den Bildschirm. Probier es im nächsten Mock aus, oder hol dir einen $29 Session Pass, kein Abo, für den Ernstfall.

So funktioniert es

Nachfragen, mit denen du rechnen solltest

  • Was, wenn die Traces zeigen, dass die Zeit im Warten auf eine Verbindung liegt?
  • Wie unterscheidest du eine langsame Query von Lock Contention?
  • Was würdest du ergänzen, damit das nächste Mal schneller zu diagnostizieren ist?

Weitere Fragen für Softwareentwickler

Dein Interviewer stellt seine eigene Version davon. Kopier deine echte Stellenbeschreibung in den kostenlosen Question Predictor und bekomm die 20 Fragen, die diese Rolle am wahrscheinlichsten stellt, samt dem, worauf jede wirklich abzielt.

Meine Fragen vorhersagen

Üb die harten Fragen, bevor sie gestellt werden

Trainier mit einem Live-Copiloten und geh dann vorbereitet rein. Ein $29 Session Pass bringt dich durch das Vorstellungsgespräch, ohne Abo und ohne Bindung.

GhostPilot holen