Ich bin ein leitender Entwickler und führe technische Interviews für das kleine Softwareunternehmen, für das ich arbeite.
Ich weiß, dass es Projekte gibt, für die es schrecklich ist, zu arbeiten (alte Technologien, komplizierte Kunden, Bürokratie, Arbeiten im Büro des Kunden statt im Büro des Unternehmens, viel Wartung statt reiner Entwicklung usw.), aber ich arbeite nicht in diesen Projekten ( Glücklicherweise). Es gibt auch eine hohe Fluktuation bei diesen Projekten, weil die Leute sie normalerweise nicht mögen, aber sie scheinen für das Unternehmen rentabel zu sein, zumindest in $$-Betrachtungen [Anmerkung]
Meistens fragen mich Kandidaten, wie ich mich fühle, wenn ich für das Unternehmen arbeite, oder über die verschiedenen Projekte/Technologien, die wir verwenden.
Manchmal, wenn ich einen Kandidaten interviewe, der eine hohe Chance hat, in das Unternehmen einzusteigen und in einem dieser Projekte zu arbeiten, wenn er mich nach dem Projekt fragt, finde ich mich in einer komplizierten Lage wieder, weil ich glaube, dass es mehr schlechte als gute Dinge gibt sagen, und ich möchte sie nicht belügen, aber ich möchte auch nicht, dass das Unternehmen einen Kandidaten verliert, besonders wenn es ein guter ist und wenn es nicht 100% sicher ist, in welche Projekte sie gehen werden Arbeit.
Einige häufige Probleme, die ich gesehen habe:
...und mehr.
Wie soll ich mit diesen umgehen? Bis zu welchem Punkt sollte ich vollkommen aufrichtig sein? Soll ich etwas "erfinden"?
Bearbeiten Sie nach einigen Kommentaren
Zunächst einmal treten diese Probleme nicht bei allen Projekten auf. Es passiert nur wenigen von ihnen. In den anderen haben wir diese Probleme nicht und wir haben keine hohe Fluktuation.
Bezüglich des freien Nachmittags, da die Entwickler im Büro des Kunden arbeiten, möchte der Kunde nicht, dass sie gehen - und deshalb geht dieser Vorteil irgendwie "verloren". Ich weiß, dass es sich um Beschwerden handelte, aber ich weiß nicht, ob das Unternehmen dieses Problem behoben hat.
Die anderen Probleme (die Art von nicht richtig dokumentierten APIs und Verzögerungen bei Tastenanschlägen) treten bei Kunden auf, die große Unternehmen sind, die größer sind als wir (denken Sie daran - wir sind eine kleine Softwarefirma). Und auch diese Kunden gehören zu unseren größte Kunden ... aber das Geschäft dieser Kunden ist nicht IT-bezogen - also haben sie vielleicht einen kleinen IT-Bereich, aber sie haben immer noch Entscheidungsbefugnis, da sie der Kunde sind und der Kunde tut, was der Kunde tun möchte. [Anmerkung 2]
Allerdings weiß ich, dass sie versucht haben, diese Kunden aufzuklären – aber ohne Erfolg. Ich weiß auch, dass sie nach neuen Projekten suchen, also können zumindest die "schlechten" Projekte, die für das Unternehmen in Bezug auf den Gewinn wichtig sind, "weniger wichtig" sein. Aber dies ist, glaube ich, außerhalb des Rahmens der Frage, wie [Anmerkung 1] feststellte.
[Anmerkung] Natürlich muss der Softwareprozess des Projekts dringend verbessert werden, aber das liegt außerhalb meiner Reichweite.
[Anmerkung 2] Ich lebe nicht in den USA (vielleicht haben Sie es aufgrund meiner Grundkenntnisse in Englisch bemerkt), aber ich lebe in einem Dritte-Welt-Land - hier werden viele Dinge immer noch auf Papier erledigt und überhaupt ohne Computer. Obwohl es also eine enorme Verbesserung zu sein scheint, einen IT-Bereich zu haben, gibt es noch viel zu tun. Die Aufklärung des Kunden könnte zu schwierig sein, meistens sehen sie ihn zu kurz und wollen nicht zu viel in Technologie investieren. Verdammt, ich habe viele Kandidaten interviewt, die aus Unternehmen kamen, die CVS überhaupt nicht eingesetzt haben (und das war unter anderem einer ihrer Gründe, sich nach einer anderen Jobmöglichkeit umzusehen).
Ich weiß nicht wirklich, dass es so etwas wie ein "schlechtes" Projekt per se gibt ... aber ich kann sicher verstehen, wo es schwierig wäre, mit potenziellen neuen Mitarbeitern über ein Projekt zu sprechen, das Sie nicht alle finden das macht Spaß. Es gibt vielleicht ein paar Möglichkeiten, wie ich es angehen würde:
„Erfinden“ oder lügen Sie nicht über Sachen. Es ist in Ordnung, ehrlich zu sein, wie Jungs anfangen. Wenn es eine Situation ist, in der wir Leute gerne ausprobieren, um sicherzustellen, dass sie auf dem neuesten Stand sind, aber wenn wir Sie mögen, lassen wir Sie etwas anderes tun, denke ich, dass das eine vollkommen gültige Sache ist, die man jemandem sagen kann. Wenn Sie jedoch jemandem Dinge sagen, die nicht wahr sind, denkt er im besten Fall schlecht über Sie und nicht über das Unternehmen, und im schlimmsten Fall müssen Sie sich noch einmal für die Stelle bewerben paar Wochen nachdem sie aufgehört haben.
Auf der anderen Seite sollten Sie sich auch nicht die Mühe machen, es zu verunglimpfen. Dafür gibt es zwei Gründe: Zum einen ist der Schmerz des einen die Chance des anderen. Wer weiß, vielleicht ist die nächste Person, die Sie einstellen, diejenige, die sich zum Beispiel etwas von dieser alten Technologie ansieht und Ihren Kunden davon überzeugt, auf etwas Neues umzusteigen. Oder, wissen Sie, vielleicht auch nicht, aber es hat keinen Sinn, es einfach zu zerstören. Der andere Grund ist, dass, wenn Sie negative Informationen an Personen weitergeben, diese Sie (und in diesem Fall Ihr Unternehmen durch Stellvertreter) mit Negativität in Verbindung bringen. Das ist einfach die Art und Weise, wie der menschliche Verstand funktioniert, und es ist ein großer Teil dessen, warum alle schlecht über Büroklatsch denken.
Arbeite an diesen Soft Skills! Sie wissen, wie Immobilienmakler ein kleines Haus oft als „gemütlich“ oder ein heruntergekommenes als „reparierend“ bezeichnen? Nun, es gibt sicherlich positive Möglichkeiten, die Erfahrung zu verkaufen. Okay, vielleicht ist dieser Job nichts für Sietun möchten, aber abhängig von den Dingen ... zum Beispiel könnte der Fokus auf Wartung statt Entwicklung als großartige Gelegenheit für eine Person verkauft werden, die neu bei S-Dev ist, aber zum Beispiel einen Hintergrund in QA oder technischem Support hat ihre Fähigkeiten verfeinern, während sie innerhalb eines etablierten Rahmens arbeiten. Wenn Sie im Büro eines Kunden Seite an Seite mit ihm arbeiten, kann dies eine hervorragende Situation sein, um zu lernen, wie man mit Endbenutzern und Stakeholdern spricht und sie versteht (was übrigens für jeden Programmierer eine wirklich, wirklich gute Sache ist). ). Sogar der Umgang mit Bürokratie ist eine Fähigkeit, die verfeinert werden kann und die in manchen Jobs sehr, sehr wertvoll sein kann.
Einige dieser Dinge werden Deal-Breaker sein, oder sollten es zumindest sein. Entschuldigung, ich musste das hinzufügen, weil der ursprüngliche Beitrag geändert wurde. Ich werde versuchen, dies so branchenunspezifisch wie möglich zu halten, aber ich muss sagen, dass es das nicht gibtgute Entschuldigung für das Fehlen einer Quell-/Versionskontrolle, Punkt. Sogar ein kleines Haus hat Zugriff auf Github. Wenn der Kunde dies nicht zulässt, muss der Kunde darüber aufgeklärt werden, warum dies notwendig ist. Da dies auf Ihre Situation zutrifft, ist dies eine schwierige Frage. Wenn ich mich bei Ihnen bewerben würde, würde ich definitiv nach Ihrer Quellcodeverwaltung fragen. Wenn du mich deswegen anlügst, gehe ich vielleicht am ersten Tag raus. Ich würde mit ziemlicher Sicherheit gehen, wenn ich keine Quellcodeverwaltung finden und einen Rückschlag erhalten würde, als ich versuchte, irgendeine Form davon zu implementieren. Ein jüngerer Entwickler "versteht" vielleicht nicht, wie wichtig es ist, und fragt daher vielleicht nicht. Selbst dann, ich weiß nicht, bin ich unschlüssig, ob Sie sich verpflichtet fühlen sollten, dies selbst zur Sprache zu bringen.
Um ehrlich zu sein, all diese anderen Dinge sind praktikable Probleme. Ich musste mich mit langsamen und trägen Workstations auseinandersetzen, mit Bürokratie, als mein eigener BA fungieren, herausfinden, was ich tun soll, während ich weitermache ... tatsächlich gehören all diese Dinge, wie ich finde, dazu die Erfahrung in der Softwareentwicklung. Arbeiten ohne Versionskontrolle ist nicht, oder sollte es zumindest nicht sein (und ich bin mir sicher, dass andere Branchen ähnliche No-Go-Sachen haben).
Ich würde diese Frage beantworten, indem ich so etwas sage:
„Es gibt einige großartige Projekte, an denen Sie irgendwann arbeiten könnten, aber Sie müssen mit einigen unserer älteren Legacy-Projekte beginnen. Sie sind hart, nicht so viele neue Entwicklungen, aber Sie werden viel von ihnen lernen und es wird eine großartige Erfahrung sein. Ich kann nicht sagen, wie Sie die Arbeit daran finden würden, da wir alle unterschiedlich sind. Ich persönlich bin kein großer Fan von Fehlerbeseitigung und der Arbeit mit dem alten Code anderer Leute, aber ich würde zumindest die Gelegenheit genießen, zu zeigen, wie Ich könnte den Code sehr verbessern. Vielleicht gefällt es Ihnen, und wenn nicht, haben Sie nach einer Weile sowieso die Möglichkeit, das Projekt zu ändern. Was die Firma im Allgemeinen betrifft, sie ist großartig, ich habe es wirklich genossen, für sie zu arbeiten ."
Ich habe Bewerbern schon einmal etwas ganz Ähnliches sagen müssen. Ich will sie nicht anlügen, aber man kann auf jeden Fall sozusagen „den Schlag abmildern“.
Ich denke nicht, dass Sie direkt für das Unternehmen lügen sollten, aber gleichzeitig, wenn Sie gerne dort arbeiten, sagen Sie es und konzentrieren Sie sich einfach weniger auf die Projekte, an denen sie wahrscheinlich arbeiten werden.
Vom Lügen durch Unterlassung
Wenn ich nur begrenzte Beschäftigungsmöglichkeiten habe: Ich bin unzufrieden und gehe schließlich, nachdem Ihr Unternehmen viel Zeit und Geld in mich investiert hat.
Wenn ich mehrere Beschäftigungsmöglichkeiten habe: Ich werde sehr schnell gehen und wahrscheinlich anderen, die danach fragen, davon erzählen. Ihr Unternehmensvertreter wird zwangsläufig untergehen, wenn die Personalabteilung zwielichtige Dinge tut (siehe: HR usually omits that
)
Mangelnde Tools, um die Arbeit zu erledigen (keine Versionskontrolle, langsame Computer)
So ziemlich das gleiche wie oben. Kein Entwickler, der sein Geld wert ist, wird bleiben, wenn sein Arbeitsplatz seine Arbeit nicht erleichtert. Das wäre so, als würde man einen Zimmermann bitten, Nägel mit einer Banane einzuschlagen. Der einzige Grund, hier zu bleiben, wäre, wenn es keine andere Möglichkeit gäbe.
Bei Projekten, die "Gepäck" haben
Wenn Sie Projekte mit fehlender Dokumentation, schwierigen Kunden, alter/überholter Technologie erwähnen, sind dies Herausforderungen, denen jedes große Unternehmen irgendwann gegenüberstehen wird. Als Interviewpartner erwarte ich von Ihnen, dass Sie diese Dinge im Voraus erwähnen, denn als Mitarbeiter erwarte ich, dass das Unternehmen eine Strategie hat, um diese Dinge anzugehen . Das Kernproblem hier ist nicht, dass Sie nicht wissen, wie Sie den Interviewpartnern von diesen Problemen erzählen sollen, sondern dass Ihr Unternehmen keine Strategie zu haben scheint, um diese Schwachstellen zu beseitigen, nur weil es Ihnen Cashflow verschafft. Das ist bestenfalls Selbstgefälligkeit.
Wie vermitteln Sie den Befragten die Realität?
Mein Vorschlag wäre, ehrlich zu sein. Wenn Sie sie einstellen, werden sie eher früher als später die Wahrheit herausfinden. Informieren Sie sie jetzt, damit sie eine fundierte Entscheidung treffen können. Diejenigen, die verzweifelt nach einem Job suchen, werden immer noch ja sagen, und diejenigen, die es nicht sind, werden nein sagen (was billiger ist, als sie einzustellen und sie dann schnell gehen zu lassen).
Als Rekrutierte für solche Projekte sehe ich das so:
Stellen Sie sicher, dass Sie nicht lügen oder irreführen. auch durch Unterlassung. Dadurch werden die Leute schnell verschwinden. Wahrscheinlich ohne der Firma viel Gutes zu tun, bevor sie gehen.
Machen Sie niemanden für Fehler verantwortlich, von denen Sie nicht beweisen können, dass sie ihre eigenen sind. Und stellen Sie sicher, dass sie es wissen. "Einige Projekte verwenden kein Versionskontrollsystem, weil der Kunde es nicht zulässt." - das ist einfach schrecklich. Können Sie GIT nicht einmal für Ihre lokale Codekopie verwenden? Wenn das der Fall ist, werden viele Entwickler umkehren und weglaufen. Und das ist eine angemessene Reaktion. Ohne Versionskontrolle wissen Sie nicht, ob der Fehler wirklich bei ihnen liegt. Wenn also ihre Beförderung, ihre Vorteile usw. von den Fehlern abhängen sollen, die jemand anderes in den Code einführen könnte, ist es ihnen gegenüber einfach unfair. Stellen Sie also sicher, dass sie wissen, dass es nicht passieren wird.
Setzen Sie keine festen Fristen für Dinge, die mit APIs in Berührung kommen, die nicht dokumentiert sind oder sich ohne Vorankündigung ändern können. Nochmals - stellen Sie sicher, dass sie es wissen.
Verhandeln Sie mit Ihren Kunden . Verzögerung für Tastendruck ist ein Deal Breaker. Sie können nicht erwarten, dass sich dev auf seine Arbeit konzentriert, wenn er nicht einmal über technische Mittel zum Tippen verfügt.
Sagen Sie ihnen im Voraus, wie lange sie bei einem schlechten Projekt bleiben werden. Ich könnte zustimmen, einen Monat, vielleicht drei, unter solchen Bedingungen zu arbeiten. Vielleicht. Wenn das Geld gut genug wäre. Aber ich würde gerne sicher sein, wann es enden würde.
Anketam
David K
Gonzalo.-
Neo
ColleenV
Gonzalo.-
Gonzalo.-
Ad infinitum
Bob Jarvis - Слава Україні
Julia Hayward
Magisch
Benutzer1602
Some projects don't use any version control system because the client doesn't allow it.
Autsch! Verzeihen Sie, während ich meinen Kiefer wieder vom Boden aufhebe. Ich frage mich, wie profitabel ein Projekt sein müsste, um diese Art von Idiotie zu ertragen.David Thornley
Itsme2003
Benutzer371366