Wie kann ich einen potenziellen Arbeitgeber bitten, den Produktionscode zu zeigen?

Meiner Erfahrung nach neigen Führungskräfte und sogar Mitarbeiter eines potenziellen Arbeitgebers dazu, in Vorstellungsgesprächen den Qualitätsanspruch in ihrem Unternehmen oder ihrem Team zu betonen. Ich werde auch regelmäßig nach meiner Kompetenz im Umgang mit Tools und Prozessen zur Verbesserung und Aufrechterhaltung der Codequalität gefragt. Es ist auch üblich, während des Interviews oder als Aufgabe einen Code zu schreiben.

Aufgrund meiner Erfahrung mit mehreren Wartungsprojekten musste ich den Wert von gutem Code auf die harte Tour lernen. Es ist mir sehr wichtig geworden, wenn ich meinen eigenen Code schreibe. Und ich möchte nicht bei einem Unternehmen angestellt werden, das sich nicht dafür einsetzt, guten Code zu schreiben, abgesehen von den Definitionen für guten Code.

Sobald jedoch der Legacy-Code auf dem Tisch liegt, bin ich oft enttäuscht, da sich herausstellt, dass die Verpflichtung zur Codequalität eher eine Redensart ist. Es wimmelt nur so von einfachen Fehlern, die vor Jahren eingeführt wurden, hat keine konsistente Formatierung, keine konsistenten Redewendungen und zeigt manchmal ein groteskes Missverständnis grundlegender Codierungstechniken und -prinzipien. Wahrscheinlich predige ich hier zum Chor :)

Ist es eine gute Idee, einen potenziellen Arbeitgeber zu bitten, zuerst den Quellcode zu zeigen? Insbesondere würde ich gerne einige Produktionscodebeispiele sehen.

Wie kann ich danach fragen, damit ein potenzieller Arbeitgeber meine Bedenken versteht und mir tatsächlich erlaubt, einen Blick darauf zu werfen?

Werden sie wahrscheinlich aus anderen Gründen als schlechter Codequalität (Vertraulichkeit usw.) ablehnen?

Wenn sie sich weigern, wie können wir dann eine für beide Seiten zufriedenstellende Einigung erzielen?

Nehmen wir der Argumentation halber an, dass ich die Codequalität anhand einer relativ kleinen Stichprobe bestimmen kann - meine Frage bezieht sich wirklich nur darauf, ob und wie ich danach fragen soll. Mich vor niedrigen erwarteten Renditen zu warnen, ist nett, aber nicht zum Thema.

Ich bin kein Bewerber. Ich wurde aufgrund meiner Qualifikation angesprochen und möchte gerne prüfen, ob ich tatsächlich Interesse habe. Ich habe keine Angst, vom Rennen ausgeschlossen zu werden. Mein primäres Ziel ist es, herauszufinden, ob mir das Essen schmeckt, ohne den ganzen Teller aufessen zu müssen.

Kommentare entfernt: Kommentare sollen helfen, einen Beitrag zu verbessern oder um Klärung zu bitten. Bitte beantworten Sie nicht die Fragen in den Kommentaren. Diese können nicht einfach als die besten Antworten bewertet werden, und sie können versehentlich andere Benutzer daran hindern, echte Antworten zu geben. Siehe Wie soll ich eine nützliche Nicht-Antwort posten, wenn es kein Kommentar sein soll? für mehr Anleitung.
Kommentare sind nicht für längere Diskussionen gedacht; Diese Konversation wurde in den Chat verschoben .
@IanLewis, für Diskussionen können Sie und andere gerne The Workplace Chat nutzen . Kommentare haben auf unserer Website jedoch einen ganz bestimmten Zweck . Weitere Informationen finden Sie insbesondere in den Abschnitten „Wann sollte ich kommentieren“ und „Wann sollte ich nicht kommentieren“ oder unter Welche Kommentare sind nicht zulässig? Hoffe, das hilft bei der Klärung. Vor diesem Hintergrund habe ich diese Kommentare automatisch in ihren eigenen Chatroom verschoben, damit die Diskussion um diese Frage unvermindert fortgesetzt werden kann. Siehe den vorherigen Kommentar für den Link.
Keine Antwort auf Ihre Frage, aber halten Sie Ausschau nach verwandten kurzfristigen Beratungsprojekten sowie Möglichkeiten zum Chatten mit Entwicklern, die für das Unternehmen arbeiten oder gearbeitet haben (z. B. Hackathons).

Antworten (13)

Es ist höchst unwahrscheinlich, dass sie Ihnen ein Beispiel des Codes zur Verfügung stellen werden, also müssen Sie wirklich herausfinden, wie Sie Ihre Fragen beantworten können, ohne den Code zu sehen. Sie versuchen sicherzustellen, dass sie Wert auf gute Programmierpraktiken legen, also fragen Sie sie danach .

Hier sind einige Beispielfragen, die Ihnen helfen sollen zu verstehen, wie viel Wert das Unternehmen auf die Pflege von Qualitätscode im Laufe der Zeit legt. Es gibt viele andere Dinge, die Sie speziell für Ihre Situation und Prioritäten fragen können.

  • Welche Art von Quellcodeverwaltung verwenden Sie?
  • Wie meldet das Team Fehler?
  • Führen Sie Peer-Reviews für Code durch?
  • Wie stellen Sie sicher, dass Code, der von einem Entwickler geschrieben wurde, von einem anderen leicht gelesen und verstanden werden kann?
  • Wie pflegen Sie Legacy-Code im Laufe der Zeit?
  • Wie halten Sie Ihre Teammitglieder über die besten Programmierpraktiken und -techniken auf dem Laufenden?
  • Verwenden Sie statische Analysetools wie Checkstyle, um Codierungsstandards durchzusetzen? (@ Ryan)
  • Wie lange friert Ihr Code vor einer Veröffentlichung ein? (@Sandra Walters)
  • Was ist Ihr Testframework? (@m24p)
  • An welchem ​​Punkt der Entwicklung haben Sie mit der Implementierung guter Programmierpraktiken begonnen? (@dotancohen)

BEARBEITEN:

Einige Leute weisen darauf hin, dass nur weil der Interviewer Ihnen etwas sagt, es nicht bedeutet, dass es ganz wahr ist. Ihre Standards für Peer-Reviews stimmen möglicherweise nicht mit Ihren überein, oder vielleicht weiß der Manager nicht so viel über die Programmierpraktiken seines Teams, wie er denkt. Das gilt für alles, was einem in einem Vorstellungsgespräch gesagt wird, über alle Themen hinweg, und man muss sich ab einem gewissen Punkt auf Vertrauen verlassen. Wenn Sie sich wirklich wohler fühlen würden, wenn Sie Code sehen würden, dann fragen Sie auf jeden Fall! Ich glaube nur nicht, dass Sie davon ausgehen können, dass die Antwort ja sein wird.

+1 Macht absolut Sinn. Ich denke, ich werde damit beginnen, die Fragen zu stellen, die Sie vorgeschlagen haben, und nur nach Code fragen, wenn die Reaktion ausweichend/erschrocken/murmelnd ist.
Um die Liste der zu stellenden Fragen zu ergänzen, würde ich nach statischen Analysetools oder Tools fragen, die den Prozess der Durchsetzung eines Codierungsstandards automatisieren. Ich weiß, Java hat Checkstyle.
Hmm, während eines tatsächlichen Interviews habe ich darum gebeten, einen Code von nicht wesentlichen Teilen der Anwendung zu sehen, und es wurde mir gezeigt. Ich habe es einfach als Teil des „Kennenlernens der Firma“ gesehen. Dies war jedoch bereits an dem Punkt, an dem das Unternehmen wusste, dass es mich wollte, und ich wahrscheinlich akzeptieren würde.
+1. Ein kleines Codebeispiel sagt Ihnen nicht viel aus dem Zusammenhang. Ob die Codebasis als Ganzes gut ist oder nicht, wird stark davon beeinflusst, ob der gesamte Entwicklungsprozess dazu beiträgt, guten Code zu produzieren.
Außerdem würde ich dieser Liste die Frage hinzufügen : Wie lange friert Ihr Code vor einer Veröffentlichung ein? Wenn die Antwort keine oder eine sehr kurze ist, dann könnte es ein Geschäft sein, das die Produktion übt ... und die daraus resultierende Heiterkeit, Fehler mit dem kürzlich veröffentlichten Produkt zu beheben.
Sie könnten all das tun, und danach finden Sie im Kern der C++-Anwendung eine Seite voller Gotos. Es gibt wirklich keine sichere Möglichkeit, die Teamfähigkeiten (oder die des Unternehmens für kleinere Szenarien) zu bewerten, ohne daran zu arbeiten.
Eine Sache, die ich beim Vorstellungsgespräch mit potenziellen Arbeitgebern gefragt habe, war: „Was ist Ihr Testrahmen“? Wenn ich nichts von automatisierten Komponententests usw. gehört habe, war das kein gutes Zeichen. Eine weitere gute allgemeine Frage sind solche, die den Interviewer zwingen, etwas Negatives über das Unternehmen zu sagen. Normalerweise finden Sie ein Muster, das Ihnen etwas Nützliches sagt. Wenn die Codeintegrität ein Problem ist, könnte es jemand erwähnen.
Ich glaube, Sie haben eine Schlüsselfrage übersehen: Was sind die Schritte im Build-Test-Zyklus und wie lange dauert er?
„Haben Sie automatisierte Prozesse wie das Erstellen und Ausführen von Tests?“ Fragen Sie im Wesentlichen nach Praktiken der kontinuierlichen Integration.
Ich war einmal bei einem Interview, wo sie mir den Live-Code zeigten, ohne zu fragen. War keine große Sache.
Vergessen Sie nicht, zusätzlich zu diesen Fragen zu fragen, an welchem ​​Punkt der Entwicklung mit der Implementierung guter Programmierpraktiken begonnen wurde . Ich habe viele Entwickler und Unternehmen gesehen, die Programmierpraktiken erwähnt haben, aber wenn der Code ein Durcheinander ist, antworten sie: "Oh, das ! Das wurde vor bla bla bla geschrieben". Das macht natürlich 90 % der Codebasis aus.
"Zu dieser Liste würde ich auch die Frage hinzufügen, wie lange ist Ihr Code vor einer Veröffentlichung eingefroren?". IMO ist die Notwendigkeit, überhaupt ein Code-Freeze zu haben, eine rote Fahne. Sie sind nicht erforderlich, wenn Ihr Code gut getestet ist und alle Bereitstellungen vollständig automatisiert sind

Wenn Sie Code warten, können Sie genauso gut davon ausgehen, dass der Code, den Sie pflegen, in irgendeiner Weise strukturell mangelhaft ist.

  1. Es ist nicht sinnvoll, Code zur Überprüfung zu verlangen, da dieser Code als vertraulich und urheberrechtlich geschützt gilt, es sei denn, er ist Open Source. Sie könnten sich den Open-Source-Code ansehen, aber wenn er gut geschrieben und gut strukturiert ist, gibt es keine Garantie dafür, dass der Legacy-Code genauso gut geschrieben und strukturiert ist.

  2. Selbst wenn Sie proprietären Code sehen durften, gibt es keine Garantie dafür, dass dieser Code nicht wirklich ihr bester Schritt nach vorne ist.

  3. Wenn Sie mit mir ein Vorstellungsgespräch führten und Sie darum bitten, einen Teil unseres proprietären Codes zu sehen, werde ich die Haltung einnehmen, dass Sie die Bedeutung der Wörter „vertraulich“ und „proprietär“ nicht kennen, und Sie als Kandidat übergangen. Warum sollte ich Sie überhaupt einstellen, wenn ich mir Gedanken darüber machen muss, welchen Legacy-Code Sie bereit sind zu pflegen?

4. Wenn sie Ihnen tatsächlich erlauben, ein Beispiel ihres Codes zu sehen, gibt es keine Garantie dafür, dass der Rest des Codes die gleiche Qualität/Struktur hat.
@Vietnhi Danke für deine Antwort, Vietnhi. Ich stimme Ihren Punkten 1 und 2 zu. Es gibt keine Garantien, aber dies ist für die Frage nicht relevant. Ich habe keine Angst vor einer Absage – das Unternehmen hat sein Interesse ganz klar bekundet. Ich frage nach einer Möglichkeit zu beurteilen, ob ich auch interessiert sein sollte. Hast du da zufällig einen Rat?
@kostja Am Ende des Tages läuft die Annahme eines Jobangebots auf ein Mistshooting hinaus, bei dem man auf das Beste hofft. Wenn Sie speziell eingestellt werden, um an neuen Projekten von Grund auf zu arbeiten, werden Sie nicht auf Legacy-Code stoßen. Zumindest anfangs. Junior-Programmierer werden eingestellt, um den Legacy-Code zu pflegen, damit die Senior-Programmierer in die lustigen Projekte einsteigen können :) Während des Interviews können Sie fragen, ob Sie voraussichtlich bei den neuen Projekten eingesetzt werden, die von Grund auf neu sind, oder bei den Legacy-Projekten. Ein neues Projekt, das viel Legacy-Code enthält, zählt nicht als neues Projekt :)
1. ist sinnlos: wenn sie wollen, können sie es dir zeigen. Und das Zeigen von ein paar Dateien aus einem ganzen Projekt wird nichts untergraben, es ist nicht so, als könnten Sie sie irgendwie verwenden.
Ergänzend zu dem, was @Lohoris geschrieben hat: geschweige denn in ein paar Minuten, in denen Sie es sich angesehen haben, worum es wahrscheinlich gehen würde, wenn Sie vor Ort danach fragen würden. Wenn Sie darum bitten, dass es Ihnen zugeschickt wird, ändert das natürlich etwas, aber nicht so viel; Das Unternehmen kann sicherlich einen Teil des Codes auswählen, der weniger kritisch ist und/oder nichts Wichtiges tut. Ich könnte Code aus einem größeren System herausziehen, der in vielerlei Hinsicht trivial ist, dem Leser aber dennoch den Gesamtstil des Codes in diesem System vermittelt. Ich nehme an, das ist es, wonach der OP sucht.
@ra_htial Dein Punkt 4 ist genau derselbe wie der Punkt 2 der Antwort.
Das ist eine sehr anschauliche Antwort. Diese Art der Reaktion auf eine gute Frage ist für mich ein klarer Showstopper. Ich glaube, ich würde das Interview gleich nach dem 3. Punkt abbrechen und dich mit deinem Shitcode allein lassen.
"Warum sollte ich Sie überhaupt einstellen, wenn ich mir Gedanken darüber machen muss, welchen Legacy-Code Sie bereit sind zu pflegen?" Nun, ist das nicht der Punkt? Wenn Sie nur bereit sind, jemanden einzustellen, der gerne beschissenen Legacy-Code pflegt, dann bedeutet das vermutlich, dass die Pflege von beschissenem Legacy-Code Teil der Stellenbeschreibung ist, was bedeutet, dass kostja nicht für Sie arbeiten möchte . Das ist der ganze Sinn der Frage!
@BenAronson Es gibt überall beschissenen Code. Fühlen Sie sich frei, aus dem Geschäft auszusteigen.
Der erste Satz ist absolut wahr: Wenn Sie aus Gründen der Wartbarkeit eingestellt werden, erwarten Sie von vornherein keinen großartigen Code
Diese Antwort von Vietnhi ist negativ und akzeptiert nicht, dass unterschiedliche Codegrade vorhanden sind, unterschiedliche Wartungsgrade vorhanden sind, oder das OP dabei unterstützt, festzustellen, ob es sich bei diesem Unternehmen um eine "angemessene" oder "schlechte" Situation handelt.
@VietnhiPhuvan -- und lesen Sie bitte die Antwort von mhoran unten, workshop.stackexchange.com/a/34137/25730, um zu sehen, was eine echte Antwort auf diese zugegebenermaßen nicht einfache Frage ist.
@ThomasW Und da du gerade Punkt 1 und 2 meiner Antwort widersprochen hast, musst du an deinem Leseverständnis arbeiten. Ich nehme Ihre Bevormundung sehr übel.
Der Rat von @ThomasW mhoran_psprep zur Auftragsvergabe ist dahingehend fundiert, dass ein Auftragnehmer wissen sollte, woran er arbeiten wird, bevor er überhaupt an ein Angebot denkt - aber das ist ein Wohlfühlratschlag: Der Auftragnehmer hat keine Möglichkeit zu wissen, dass der Code, an dem er arbeiten wird zwei Wochen nach Ablauf der Probezeit - ob dieser Code etwas taugt. Die Analogie zum Bauauftrag ist falsch: Ein Haus und seine Probleme sind für einen Bauunternehmer sichtbar. Nicht so bei Legacy-Code: Der Code-Auftragnehmer macht einen Vertrauensvorschuss basierend auf dem Rest des Codes, der auf dem Code basiert, den er sehen durfte.
Es liegt in der Verantwortung des Arbeitgebers zu erkennen, dass er tatsächlich jemanden anstellt, um einen Berg Scheiße umzugestalten , und nicht, um eine Codebasis zu pflegen. Der Arbeitgeber muss diesbezüglich offen sein und einen Kandidaten suchen, der sowohl bereit als auch in der Lage ist, diese Art von Arbeit zu erledigen. Die in dieser Antwort zum Ausdruck gebrachte Haltung wäre für den Arbeitgeber selbstzerstörerisch, da er höchstwahrscheinlich einen Mitarbeiter haben würde, der sofort kündigt, wenn er den Kodex sieht, einen schäbigen Jasager, der sein Geld umsonst oder ernsthaft nimmt Anfänger, der alles nur noch schlimmer machen würde.
Bei der Frage ging es nicht darum, uneingeschränkten Zugriff auf die gesamte Codebasis zu verlangen. Mit nur wenigen Minuten überwachtem Zugriff auf einen kleinen Teil der Codebasis wäre es sogar jemandem mit einem fotografischen Gedächtnis schwer, etwas zu bekommen, das er böswillig verwenden könnte.

Einfach fragen. Stellen Sie kein Ultimatum, dass Sie zur Tür hinausgehen, wenn Sie den Code nicht sehen. Es kann legitime Gründe geben, warum sie es nicht zeigen können. Wenn Sie der Meinung sind, dass dies ein Deal Breaker ist, lehnen Sie das nächste Interview einfach ab.

Obwohl sie keine kommerzielle Software verkauften, habe ich während eines Interviews Code gesehen und musste nicht einmal danach fragen. Sie wollten wissen, ob ich es verstehe.

Das Bereinigen von Code wird immer Teil der Arbeit sein. Sie haben vielleicht das Gefühl, dass Sie sehr hohe Standards für Ihre aktuellen Programmierpraktiken haben, aber in einem Jahr oder so sind Sie vielleicht nicht mehr so ​​zufrieden damit.

Sei nicht so hart. Ein Bild mag mehr als tausend Worte enthalten, aber es zeigt nur eine Seite der Geschichte.

Bearbeiten: Ich denke, ein Schlüssel hier ist, ob sie Sie in die Lage versetzen werden, schlechten Code zu schreiben. Das könnte der Grund für eine aktuelle Codebasis von geringer Qualität sein, oder es kann sein, dass die vorherigen Programmierer nicht so geschickt waren. Aufräumen macht nicht immer Spaß, ist aber erträglich, wenn Sie wissen, dass das Unternehmen Sie in die Lage versetzen wird, erfolgreich und qualitativ hochwertig zu arbeiten.

Das heißt, wenn das Unternehmen bereit und engagiert ist, aufzuräumen. Das mag der springende Punkt sein, wenn man bereit ist, einen Blick auf den aktuellen Code zu werfen.

Fragen Sie nicht nach einer Kopie von irgendetwas: Das klingt einfach gruselig und unklug. Fragen Sie nicht das Management: Die Codebasis entspricht möglicherweise nicht den angestrebten Zielen des aktuellen Managements. Fragen Sie nicht einmal nach dem Joel-Test, da sie möglicherweise Dinge behaupten, die sie nicht wirklich haben.

Bitten Sie jedoch darum , sich mit einem bestehenden Entwickler zusammenzusetzen, um eine Tour durch die Codebasis und Toolchain sowie aktuelle Herausforderungen zu erhalten. Es ist eine vernünftige Bitte, nicht außergewöhnlich ungewöhnlich. Zu diesem Zeitpunkt können Sie Fragen zur Codewartung stellen. Wenn die Codebasis schlecht ist, werden Sie es ziemlich schnell wissen. Wenn es gut ist, haben Sie mit dem Team Kontakt aufgenommen.

+1 Ich würde wahrscheinlich deutlich mehr Einblick bekommen, als einfach darum zu bitten, mir den Code zu zeigen. Guter Rat.

Sie sagen, Sie sehen sich nicht als Kandidat und haben keine Angst vor einer Absage, bestehen aber darauf, den Begriff potenzieller Arbeitgeber zu verwenden; Sie müssen Ihren Fokus ändern.

Sie möchten als Auftragnehmer fungieren. Sie sind kein potenzieller Arbeitgeber; Sie sind ein potenzieller Kunde.

Kein Heimwerker wird einen Kostenvoranschlag abgeben, ohne die Baustelle und die Bedingungen gesehen zu haben und zu verstehen, welche Risiken damit verbunden sind. Sie als Auftragnehmer für die Codeverbesserung müssen die gleichen Schritte ausführen.

Ein Ansatz besteht darin, einen ein- oder zweiwöchigen Auftrag zu übernehmen, um die Situation zu untersuchen und abzuschätzen, was benötigt wird und was es kosten wird. Wenn Ihnen die Situation nicht gefällt, bieten Sie hoch oder weigern Sie sich, die Arbeit anzunehmen.

Selbstverständlich unterzeichnen Sie alle erforderlichen Vertraulichkeitsvereinbarungen.

Hinweis: Selbst wenn ich Sie ansprechen würde, um ein Mitarbeiter zu werden, würde ich Sie ausschließen, wenn Sie darauf bestehen würden, Zugang zu meiner Codebasis zu haben. Aber wenn ich Sie als Auftragnehmer einstellen wollte, um ein bestimmtes Ziel zu erreichen, würde ich erwarten, dass Sie Ihre Sorgfaltspflicht erfüllen.

+1 guter Punkt. Ich sehe die Situation eher als potenzielle Partnerschaft (während der eigentlichen Beschäftigung). Mit einem Auftrag zu beginnen, kann für beide Seiten von Vorteil sein. Danke, mhoran.
So funktioniert Contracting im Allgemeinen einfach nicht.

Ich würde versuchen, mit zukünftigen Kollegen zu sprechen . Am besten mehr als eine.

Tatsächliche Programmierer erzählen Ihnen eher als ihre Manager die tägliche Wahrheit, anstatt eine Vision davon zu haben, wo das Unternehmen hoffentlich irgendwann in der Zukunft stehen wird. Sie können auch die Ansichten mehrerer Kollegen vergleichen, um Fakten weiter von Wunschdenken zu trennen.

Ein weiterer Vorteil ist, dass die Menschen, mit denen Sie zusammenarbeiten, auch sehr wichtig für Ihre Arbeitszufriedenheit sind, also möchten Sie sie sowieso treffen.

+1. In meiner Firma sind einige der „zukünftigen Kollegen“ die Interviewer, aber das ist nicht überall so.

Stellen Sie einfach einige Fragen aus Joel Test :

Joel-Testbeispiel

Ich glaube nicht, dass dies in der Situation, die das OP beschreibt, überhaupt helfen würde. Er sagt: „Ich bin oft enttäuscht, wenn sich herausstellt, dass das Bekenntnis zur Codequalität eher eine Redensart ist.“ Meiner Erfahrung nach würden viele Leute die Joel-Test-Fragen mit „Ja“ beantworten, aber wenn es darauf ankommt, leben sie nicht wirklich nach dieser Ja-Antwort.
@ Carson63000: und ein Teil des Grundes, warum sie damit durchkommen, ist, dass es wie bei jedem prägnanten Kriterium gute Gründe gibt, einige von Joels Punkten sowieso abzusichern, und diese werden zu schlechten Gründen gedehnt. Für ein erfundenes Beispiel für einen guten Grund, wenn "das beste Tool, das man für Geld kaufen kann" häufig zwischen den verschiedenen Paketen von X und Y wechselt, um dasselbe zu erreichen, da jedes das andere mit jeder neuen Version übertrifft, dann 50% der Nein, wir verwenden nicht "das beste Werkzeug, das man für Geld kaufen kann", wir bleiben bei einem, um die Kosten für ständiges Flip-Flops zu vermeiden ;-)
... ebenso kaufe ich nicht jedes Mal eine neue CPU, wenn eine schnellere veröffentlicht wird. Also benutze ich fast 100% der Zeit auch nicht das beste Werkzeug, das man in dieser Kategorie für Geld kaufen kann. Ich habe eine, die meinen Anforderungen entspricht, aber wenn die Störung für mich, eine schnellere zu bekommen, null wäre, würde ich sie wahrscheinlich nehmen, also ist die, die ich habe, nicht die "Beste". Aber jedes meiner Beispiele kann zu einem Unternehmen voller Leute werden, die veraltete Tools verwenden, wenn Sie am Ende niemals ernsthaft Alternativen zu Ihren aktuellen Tools prüfen und ob Sie das, was Sie haben, verbessern könnten. Sie könnten glauben, dass sie aus Unwissenheit das Beste haben
Ich muss euch allen zustimmen. Ich dachte jedoch eher an einen qualitativen Ansatz als an einen quantitativen. Einige Fragen sind subjektiver als andere, also würde ich zuerst fragen: "Verwenden Sie Quellcodeverwaltung?", und wenn ja, frage ich, welches Tool sie verwenden, wie sie es Tag für Tag verwenden usw. Auf diese Weise zeigen Sie Interesse Ihre Frage, anstatt Verdacht.
Ich kann nur zustimmen; Ich habe vor kurzem begonnen, die Fragen des Tests bei Interviews zu stellen, und es führte immer zu guten Diskussionen mit genügend Einblicken, um eine Vorstellung von der allgemeinen Qualität / dem Legacy-Level der Codebasis zu bekommen.

Wie andere gesagt haben, können Sie sie mit einigen einfachen Fragen vergleichen, aber ich verstehe wirklich, woher Sie kommen ... Aus persönlicher Erfahrung.

Die Leute sagen vor Ort eine Menge Zeug, das sie entweder nicht genau wissen, oder sie antworten, ohne die Frage zu verstehen. So etwas wie der Joel-Test ist wirklich großartig, aber nur, wenn sie die Frage und die Technologie verstehen (und wenn sie keine lügenden Drecksäcke sind).

Eine Bejahung von "Verwenden Sie die Quellcodeverwaltung?" könnte tatsächlich so schrecklich sein wie "Wir arbeiten von FTP und sichern das am Ende des Monats in CVS". Wenn diese Dinge wichtig dafür sind, ob Sie mit diesen Leuten zusammenarbeiten oder nicht, oder (was vielleicht noch wichtiger ist), wie viel Sie ihnen in Rechnung stellen werden, um ihre Unfähigkeit auszugleichen, müssen Sie es durch direkte Beobachtung herausfinden . Leute, die keine Softwareentwickler unter Vertrag nehmen, werden das wahrscheinlich nicht verstehen.

Aber Fachleute verstehen Risikobewertung . Das ist alles, was Sie hier tun. Erklären Sie es, sagen Sie, dass Sie gerne eine [gute, nicht lächerliche] NDA unterzeichnen, und wenn sie sich weigern, lassen Sie sie das Risiko auf sich nehmen, indem Sie das allerschlimmste Szenario (oder einen Faktor davon) zitieren. So handhabt das jede andere Branche.

Ich sage nicht, dass Sie sie nicht auch mit Tests wie dem Joel-Test vergleichen sollten. Stellen Sie einfach sicher, dass Sie gesehen haben, was Ihnen wichtig ist, bevor Sie sich zu irgendetwas verpflichten.

Meiner Erfahrung nach neigen Führungskräfte und sogar Mitarbeiter eines potenziellen Arbeitgebers dazu, in Vorstellungsgesprächen den Qualitätsanspruch in ihrem Unternehmen oder ihrem Team zu betonen.

Jeder Arbeitgeber ist angeblich der Qualität verpflichtet. Dennoch gibt es tonnenweise beschissene Software und tonnenweise Sicherheitslücken.

Im Allgemeinen verwechseln Sie die geschwätzige Geschäftssprache, weil die Aussage „Wir verpflichten uns zur Qualität“ letztendlich eine vage Aussage ist. Wessen Qualität? Was ist der Maßstab? Es ist einfach Bull Crud, damit Sie sich großartig fühlen.

Im Allgemeinen ist alles, was Sie während eines Bewerbungsprozesses hören, – in Ermangelung eines besseren Begriffs – eine „Notlüge“, die Ihnen das Gefühl geben soll, dass der potenzielle Arbeitgeber die beste Wahl für Sie ist.

Mein Rat? Produktionscode werden Sie höchstwahrscheinlich erst sehen, wenn Sie im Unternehmen selbst sind. Und wenn es Ihren Ansprüchen nicht genügt, suchen Sie einfach weiter nach einem neuen Gig.

Die harte Realität ist, dass ziemlich viele Unternehmen beschissene Systeme, beschissene Software und beschissene Praktiken haben. Und das ergibt sich aus der Tatsache, dass diese Art der Computerarbeit für die meisten „unsichtbar“ ist und die meisten Menschen damit durchkommen.

Ganz einfach: Bieten Sie an, eine Geheimhaltungsvereinbarung (NDA) zu unterzeichnen . Dies wird Sie rechtlich (wenn auch nicht technisch) daran hindern, ihren Code in Ihren eigenen Projekten zu verwenden.

Stellen Sie außerdem sicher, dass Ihre Anfrage logisch klingt. Fordern Sie nur die Code-Snippets an, die Sie benötigen . Dies wird Ihnen helfen, Ihre Diskussionen über das Projekt zu leiten und Ihre Anfrage vernünftig klingen zu lassen.

Ich würde nicht so schnell ein NDA unterzeichnen - das könnte Sie nicht nur daran hindern, ihren Code zu verwenden, sondern auch in Zukunft etwas Ähnliches selbst zu tun. Das Recht aufzugeben, selbst an denselben Code zu denken, ist ein echter Preis.
Ja - die Idee, NDA zu unterzeichnen , IST , Sie daran zu hindern, ihren Code zu verwenden ;-) Noch wichtiger, alle Entwickler gehen BEREITS ein Risiko ein, aber Urheberrechtsverletzungen, nicht NDA, jedes Mal, wenn sie an dasselbe Stück Code denken. Aus diesem Grund ist die Unterzeichnung einer Geheimhaltungsvereinbarung kein Problem.
Und wenn der Code so offensichtlich wäre, dass Sie selbst darauf gekommen wären, wenn Sie auf dasselbe Problem gestoßen wären? Wenn Sie in Zukunft auf dasselbe Problem stoßen, werden Sie daran gehindert, es zu lösen. Das ist kein Problem, wenn der Code, den sie Ihnen zeigen, wirklich einzigartig und besonders ist, aber Sie wissen nicht, ob er es ist, wenn Sie zum Vorstellungsgespräch erscheinen. Was ich sagen will, ist, dass Sie etwas aufgeben, wenn Sie den Code sehen und zustimmen, ihn nicht zu verwenden, im Vergleich dazu, ihn überhaupt nie zu sehen.
Wenn Sie einen Code gesehen und kein NDA unterschrieben haben, können Sie ihn, wie Andrew sagt, aufgrund des Urheberrechts sowieso nicht verwenden. Das Problem hier ist also, wenn es eines gibt, "Code zu betrachten", nicht "ein NDA zu unterzeichnen". Das NDA könnte alles sagen, es könnte sagen "Ich werde niemals die Programmiersprache verwenden, in der der Code geschrieben wurde", in diesem Fall unterschreiben Sie es natürlich nicht. Aber ein auch nur annähernd vernünftiges NDA wird Sie nicht daran hindern, Quicksort jemals (sagen wir) zu verwenden, nur weil es ein Quicksort in dem Code gibt, den Sie unter NDA sehen. Der Quicksort-Algorithmus ist nicht das, was die NDA schützt. Ihre spezifische Umsetzung davon ist.
... was das NDA jedoch tut (und was die Person, deren Code es ist, interessiert), verbietet Ihnen, herumzugehen und zu sagen: "Firma X verwendet Quicksort". Das bloße Urheberrecht hindert Sie natürlich nicht daran, und das ist der Hauptgrund, warum Sie unter NDA Zugriff auf Dinge erhalten können, die sie Außenstehenden nicht unter lediglich einer restriktiven Lizenz geben möchten, die Sie daran hindert, den Code selbst für Ihre zukünftigen Projekte anzupassen .

Fragen über:

  • Testabdeckung
  • TDD – Testgetriebene Entwicklung
  • Wie objektorientierte Analyse und Design durchgeführt werden
  • Wenden sie SOLID-Prinzipien an?
  • Verwendung von Sonar, Veracode oder anderen Code-Analyse-Tools
  • CI/CD-Praktiken
  • Die größte Klasse in einem Projekt

Ich sage ... "verschwenden Sie keine Zeit mit Unternehmen, die irgendwie erwarten, dass Sie aus dem Stegreif 'Code schreiben'. Wenn sie wirklich nicht glauben, dass Sie tatsächlich Quellcode in {Programmiersprache hier einfügen} schreiben können, warum- zur Hölle, haben sie dich zu einem Vorstellungsgespräch eingeladen?

Nun – nachdem ich das gerade gesagt habe – muss ich auch anerkennen, dass „es da draußen Prätendenten gibt“. Und es gibt auch Gründe, warum Unternehmen gelernt haben, bei jedem Kandidaten oberflächliche kriminelle Hintergrundprüfungen durchzuführen ...! (Ich könnte dir jetzt Geschichten erzählen, aber ich werde es nicht tun.)

Also – es liegt an Ihnen, denke ich. "Wie sehr willst du diesen Job?"

Sie können nicht gemäß den anderen Antworten.

Es ist jedoch wahrscheinlicher, dass sie zustimmen, Ihnen die Benutzer-IDs einiger ihrer Programmierer mitzuteilen, die Konten bei StackOverflow und Programmer haben.

Wenn Sie sich die Probleme ihrer Mitarbeiter ansehen, erhalten Sie eine Vorstellung davon, wie ihr Code aussieht.

Schrecklicher Rat. Niemand möchte, dass Leute ihn auf Stack Overflow stalken. Und ob Sie es glauben oder nicht, viele exzellente Programmierer stellen keine Fragen zu Stack Overflow. Was würden Sie tun, wenn sie sagen würden: „Wir haben keine repräsentativen Programmierer mit einem Konto?
Wie kann ich einen potenziellen Arbeitgeber bitten, den Produktionscode zu zeigen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v