Vorstellungsgespräche mit Kandidaten für "schlechte" Projekte

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:

  • Einige Vorteile, wie die Arbeit von zu Hause aus und ein freier Nachmittag pro Monat (ja, wir haben einen freien Nachmittag pro Monat, der jederzeit angefordert werden kann) gehen normalerweise verloren, wenn Sie vom Büro des Kunden aus arbeiten. HR lässt das in der Regel weg.
  • Einige Kunden, für die wir arbeiten, pflegen einige APIs, die wir verwenden, aber sie sind nicht gut dokumentiert, obwohl sich die Teams oft beschwert haben. Jedes Mal, wenn der Kunde die API-Verträge ändert, ist es ein Ärgernis für das Team.
  • Einige Projekte verwenden kein Versionskontrollsystem, weil der Client dies nicht zulässt.
  • Andere Clients geben den Entwicklern virtuelle Maschinen, die unglaublich langsam sind – Entwickler können bei jedem Tastendruck Verzögerungen erleben.
  • Da es bei dieser Art von Projekten eine hohe Fluktuation gibt, gibt es keinen "Experten" im Projekt und die Dokumentation ist wirklich schlecht, was zu Projekten mit vielen "Überraschungen" führt.

...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 rate Ihnen dringend davon ab, zu lügen oder Dinge zu erfinden, damit Sie sie nicht dazu bringen, hierher zu kommen und Fragen wie diese zu posten: arbeitsplatz.stackexchange.com/q/69593/50529
Sie sagen, dass sie wahrscheinlich mit diesen schlechten Projekten anfangen werden, aber Sie sagen auch, dass es bei diesen Projekten eine hohe Fluktuation gibt. Erwarten Sie, dass der neue Mitarbeiter mit diesem Projekt beginnt und bald darauf zu einem anderen Projekt wechselt?
wahrscheinlich nicht - Es gibt nicht zu viel Rotation bei Projekten. Normalerweise werden Leute aus anderen Projekten in diese hässlichen Projekte versetzt, weil das Unternehmen möglicherweise niemanden findet, den es einstellen kann
Sie (das Unternehmen) müssen die Alttechnologiearbeit nach Möglichkeit zusammen mit der aktuellen Technologie aufteilen. Kein kompetenter Entwickler wird jemals ausschließlich an veralteter Technologie arbeiten. Es ist ein Karrierekiller.
Ich würde bedenken, dass einige Leute die Herausforderung eines "schlechten" Projekts mögen, bei dem sie einen erheblichen Einfluss haben können. Anstatt sich auf all die Dinge zu konzentrieren, die Sie bei diesem Projekt hassen würden, konzentrieren Sie sich vielleicht auf all die interessanten Herausforderungen und Möglichkeiten, um dieses „schlechte“ Projekt in ein vielleicht „nicht schreckliches“ Projekt zu verwandeln. Wenn sie an diesem Projekt teilnehmen, haben sie möglicherweise eine echte Gelegenheit, ihre Talente von Anfang an zu zeigen, was für talentierte Menschen eine gute Sache sein kann.
@ColleenV Das mag zwar stimmen, aber bisher habe ich noch nie jemanden mit diesem Profil interviewt
@MisterPositive Ich habe meine Frage aufgrund Ihres Kommentars aktualisiert
@Gonzalo.- „alte Technologien, komplizierte Kunden, Bürokratie, Arbeiten im Büro des Kunden statt im Büro des Unternehmens, viel Wartung statt reiner Entwicklung“ Sie haben meine derzeitige Tätigkeit beschrieben. Ich hasse mein Leben jetzt :)
Nur eine Anmerkung an Sie und andere Nicht-Muttersprachler des Englischen: Bitte entschuldigen Sie sich nicht für Ihr Englisch - Sie fühlen sich vielleicht verlegen, aber aus meiner Sicht (und wahrscheinlich auch anderer) ist Ihre Sorge nicht erscheinen gerechtfertigt. Wenn Sie nicht erwähnt hätten, dass Sie kein englischer Muttersprachler sind, hätte ich das nie erraten. Du hast sogar Slang richtig verwendet! („Heck“) Entspann dich – du machst das gut. :-)
Projekte ohne Quellcodeverwaltung zum Beispiel zeigen Ihrem Kandidaten, dass das Unternehmen nicht wählerisch ist, was es an Arbeit übernimmt. Keiner der Gründe dafür (Finanzen nicht stark genug, um schlechte Arbeit abzuwenden, übermäßige Abhängigkeit von einem sehr großen Kunden, Management, das sich der Auswirkungen nicht bewusst ist) sind gute Verkaufsargumente!
Habe ich das richtig gelesen, dass Mitarbeiter je nach Einsatzgebiet im Wesentlichen 6 Tage PTO pro Jahr verlieren, wenn sie keine freien Nachmittage bekommen?
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.
Gibt es eine Entschädigung für Dinge wie fehlende freie Nachmittage? Können Sie Ihr Unternehmen dazu überreden, Entwicklern für schlechte Projekte mehr zu zahlen? Bereitstellung zusätzlicher bezahlter Schulungen oder solcher Leistungen? Wenn Sie erwarten, dass ich solche Bedingungen ertrage, sollten Sie dafür sorgen, dass es sich für mich lohnt, oder ich bin da raus. Ihr größtes Problem ist die Bindung, nicht die Rekrutierung. Rekrutieren bedeutet, Wasser mit einem Eimer über die Schandwand eines Bootes zu gießen. Retention repariert das Leck.
So viele der Antworten und Kommentare hier scheinen einen völligen Mangel an Geschäftsabläufen zu zeigen. Wenn Sie einem anderen Unternehmen eine Dienstleistung erbringen, sind Ihre Möglichkeiten, den Kunden „umzuerziehen“, begrenzt. Sie haben ihre Art, Geschäfte zu machen, und Sie verschwenden wertvolles politisches Kapital, und Sie riskieren, sie als Kunden zu verlieren, wenn Sie versuchen, ihnen vorzuschreiben, wie sie Geschäfte machen sollen. Niemand mag es, belehrt zu werden und ihm gesagt zu werden, dass er Dinge falsch macht, und im Allgemeinen vermeiden es die Menschen, Geschäfte mit Unternehmen zu machen, die so etwas auch nur versuchen würden.
scheint der einzige Weg, das Problem zu lösen, darin zu bestehen, die Leute über die Probleme zu informieren und genug Geld anzubieten, damit es den Schmerz wert ist. Sie sagen, die Projekte sind profitabel, wenn ja, dann sollten sie es sich leisten können, genug zu bezahlen, um Leute zu halten / einzustellen, während sie ehrlich über die Schmerzpunkte sind. wenn die Projekte profitabel sind, aber nicht so profitabel ... das ist nur profitabel, wenn man sich das Geld ansieht und nichts anderes; Der Cashflow ist nur vorübergehend positiv, bis Ihnen die Leute ausgehen, die bereit sind, an dem Projekt zu arbeiten.

Antworten (4)

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).

Das Problem bei der Arbeit im Büro des Kunden besteht darin, dass einige Vorteile (wie die Arbeit von zu Hause aus und andere) verloren gehen, und das ist etwas, was die Personalabteilung normalerweise nicht sagt. Das andere Problem ist, dass diese Kunden normalerweise ihren IT-Bereich haben, also zahlen sie nur für die Personalressourcen des Unternehmens. Also schicken sie normalerweise Juniors, die sich mehr um technische Fähigkeiten kümmern, als sich mit Stakeholdern Soft Skills anzueignen.
Ich würde dann im ersten Teil ganz vorne mit dabei sein, besonders wenn sie fragen, ob es Möglichkeiten gibt, von zu Hause aus zu arbeiten. Zum zweiten... Ich bin mir nicht sicher, was Sie sagen; könntest Du das erläutern?
Entschuldigung, wenn ich nicht klar bin. Englisch ist nicht meine Hauptsprache, also bin ich sicher, dass es einen "Begriff" für das gibt, was ich erklären wollte, aber ich kenne ihn nicht. Die Sache ist: Der Kunde hat einen IT-Bereich und Stakeholder. Sie bezahlen meine Firma für Entwickler – meine Firma stellt Entwickler ein, aber sie schicken sie zu dieser Art von Kunden, um an dem zu arbeiten, was sie wollen. Aus diesem Grund werden normalerweise Junioren (Jrs.) geschickt, die billiger sind ... und sich normalerweise mehr darum kümmern, neue technische Fähigkeiten zu erlernen, als etwas über Bürokratie oder den Umgang mit Interessenvertretern zu lernen
Ah, OK, es sind die neuen Mitarbeiter selbst, die sich weniger Sorgen um Soft Skills machen. Ich meine, das verstehe ich, aber wie gesagt, ich denke, es ist eine Chance für Sie, ihnen eine Fähigkeit zu verkaufen, die sie tatsächlich genauso dringend benötigen wie die sogenannten „harten“ Fähigkeiten. Ich weiß, dass mein Hintergrund – bevor ich in die Softwareentwicklung eingestiegen bin, im Kundenservice tätig war – mir oft im Umgang mit Menschen geholfen hat, selbst wenn mein Job zu 99 % darin besteht, sich hinzusetzen und Code zu schreiben.
Ich glaube nicht, dass Sie ein Projekt verkaufen können, das keine Quellcodeverwaltung als etwas anderes als "ein schlechtes Projekt" zulässt ...
@Erik Meine Mutter hat immer gesagt, wenn du nichts Nettes sagen kannst, sag gar nichts.
Huch! Das wurde nach meinem Kommentar hinzugefügt. Ich werde bearbeiten.
@JonathonCowley-Thom "Wie sehen die Projekte hier aus?" "Ich will nicht darüber reden. Kannst du bitte noch etwas fragen?"
@Erik Mar Nein, das sagt noch etwas aus. Sie müssen auf die Frage mit versteinertem Schweigen antworten.
„Arbeiten Sie an Ihren Soft Skills“, „die Anwendung, die Sie erarbeiten werden, besteht bereits seit 10 Jahren und bietet noch Herausforderungen“ -> RED FLAG, RED FLAG. Sie können es präsentieren, wie Sie möchten, es sei denn, Sie interviewen einen Neuling oder jemanden, der nur einen Wartungsjob ohne großes Interesse daran haben möchte, der nicht funktioniert. Es ist einfach am besten, wenn Sie langfristig jemanden dafür suchen Art von Jobs, um jemanden zu suchen, der die Fähigkeiten hat, aber nicht zu sehr leidenschaftlich ist.
Ich habe mir angewöhnt, in Interviews nach der Versionskontrolle zu fragen. Akzeptable Antworten wären CVS, Subversion, Git oder ähnliches. Nicht akzeptable Antworten wären RCS und SCCS. Ein leerer Blick wäre ein Dealbreaker.

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.

"... wenn nicht, bekommt man sowieso nach einiger Zeit die Möglichkeit, das Projekt zu wechseln." - Sagen Sie das nicht, es sei denn, Sie können es versprechen. Daran würde ich persönlich festhalten.
Das Unternehmen setzt Mitarbeiter nicht in Altsysteme ein, „um mit etwas anzufangen“, sondern weil es in diesen Projekten eine hohe Rotation gibt. und wie Wesley sagte, ich kann das nicht versprechen, weil ich keine Leute Projekten zuweise
"Ich habe Bewerbern schon einmal etwas sehr Ähnliches sagen müssen" Und als Sie es gesagt haben, war es wahr? Gonzalo hat uns bereits gesagt, dass Entwickler selten Projekte an seinem Arbeitsplatz ändern, also kann er es einem Bewerber definitiv nicht sagen.
Ein Versprechen zu geben, von dem Sie nicht sicher sind, dass Sie es in Zukunft halten werden, ist schlimmer als jetzt zu lügen.

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.

Zum letzten Punkt, Geld ist normal.. so etwas wie jedes kleine Unternehmen hier zahlen würde. Ich werde zum Beispiel gut bezahlt, ich weiß, dass ich in einem großen Unternehmen besser bezahlt werden könnte, aber ich mag den Unternehmensstil des Konzerns nicht – nicht zuletzt den, den ich aus meinem Land kenne
@Gonzalo, wenn sie für ähnliches Geld arbeiten können, aber mit Zugriff auf die Versionskontrolle und auf Computern, die sie tatsächlich tippen können, werden Sie es schwer haben. Ich sehe keinen Weg daran vorbei.