In letzter Zeit wurden auf der Habra so viele Geschichten über schlechte Interviews veröffentlicht, dass sich manchmal Zweifel einschleichen, und gibt es gute Interviews in der Natur? Aus Gründen der Vielfalt werden wir ein Beispiel für einen guten * Ansatz betrachten. Die Geschichte wird aus der Sicht des Entwicklers des Arbeitgebers gehen, der direkt in den Einstellungsprozess involviert ist.
* wahrscheinlich
Disposition
Ein kleines Produktteam (30-40 Personen) in einem großen Unternehmen (mehrere tausend Personen). Das Team umfasst alle am Projekt Beteiligten: Full-Stack-Entwickler und Front-Endors, Designer und Front-Endologen, Tester, PR-Spezialisten, Analysten, Textautoren usw. Im Allgemeinen versuchen wir, weniger spezialisierte Arbeiten an andere Projekte auszulagern, und die mobile Entwicklung ist keine Ausnahme.
Wir haben eine plattformübergreifende mobile Anwendung, die in Xamarin Native für iOS und Android geschrieben wurde. Gleichzeitig sind wir bereit, das Beste aus dem erfahrenen Entwickler herauszuholen, der nur für eine Plattform geschrieben hat, vorausgesetzt, er ist bereit, die Entwicklung für ein zweites Betriebssystem zu studieren.
Stufe 0 - traf zwei Einsamkeit
Entweder stößt der Entwickler auf eine freie Stelle und sendet einen Lebenslauf, wonach ihm die Personalabteilung einige klärende Fragen sendet, oder die Personalabteilung stößt auf einen Lebenslauf des Entwicklers, wonach er ungefähr dieselbe Reihe von Fragen sendet.
Diese Fragen sind der Mindestfilter für die Angemessenheit, es gibt keine technischen Probleme. Darüber hinaus werden der Lebenslauf und die Antworten bereits vom Arbeitgeber an den Entwickler übermittelt, und er entscheidet, ob er weiter geht oder nicht. Im letzten Monat habe ich mir ein paar Dutzend Lebensläufe angesehen, und ich habe keine Ahnung, was der Kandidat schreiben und beantworten soll, so dass ich zu diesem Zeitpunkt nein sagen musste. Schreiben Sie an die Stelle des Android-Entwicklers "Ich schreibe nur für iOS, weil Android scheiße ist"?
Stufe 1 - Testaufgabe oder Beispielcode
Die Testaufgabe ist zeitlich unbegrenzt, in der Praxis sollte sie jedoch nicht länger als einen Abend dauern. Im Rahmen der Testanwendung werden:
- Drei Bildschirme: zwei verknüpfte Listen + Dateneingabeformular, das bei Bedarf durch ein modales Fenster ersetzt werden kann
- Netzwerkarbeit
- Arbeiten Sie mit dem Data Warehouse (die Aufgabe impliziert eine Datenbank, wenn der Entwickler eine andere Schlussfolgerung rechtfertigen kann - wir sind willkommen)
Da jedoch nicht alle Entwickler bereit sind, einen Test zu schreiben, bieten wir sofort eine Alternative an: Senden Sie den Code einer vorgefertigten Anwendung, in der derselbe Satz vorhanden sein wird (Netzwerk, Datenbank, Navigation auf Bildschirmen, Benutzereingaben). Nun, weitere Optionen sind möglich:
- Die Anwendung ist zu klein, der Code ist nicht indikativ oder verursacht zu viele Fragen. Bitte führen Sie unseren Test durch
- Die Anwendung ist geeignet, aber es gibt Nuancen - bitte kleinere Verbesserungen vornehmen (weniger als abends)
Basierend auf den Testergebnissen rufen wir entweder den Entwickler zu einem Interview an oder wir geben auf, aber im zweiten Fall wird eine detaillierte Überprüfung durchgeführt - was gut gemacht wird, was umstritten ist, welche Fragen auftauchen, was lesenswert ist und so weiter. Als Ergebnis gewinnt jeder:
- Der Kandidat erhält einen Code, der dann bei einem anderen Interview mit ähnlichen Prinzipien wiederverwendet werden kann, sowie Feedback für die Arbeit an sich selbst. Funktioniert es Nun, zumindest haben wir Testaufträge erhalten, die ursprünglich für andere Unternehmen geschrieben wurden, also scheint es zu funktionieren.
- Der Arbeitgeber spart Zeit bei Fragebögen und anderen Dingen. Und wie glücklich ist der Interviewer ein Introvertierter, der nicht 1-2 Interviews pro Woche durchführen muss, wenn Sie nur wüssten!
Stufe 2 - Interview
Beim Interview wird sicherlich nicht nur über das Leben und den bisherigen Arbeitsplatz gesprochen, sondern auch über Fragen zur Testaufgabe. In diesem Stadium ist es ziemlich einfach zu verstehen, ob eine Person einen Test geschrieben hat, ob das, was dort geschrieben steht, ob sie die eine oder andere Lösung rechtfertigen kann, was ihr Horizont ist und so weiter. Fragen werden nicht in der Luft gestellt, sondern mit der Fähigkeit, die Tastatur zu nehmen und genau diesen Code zu stecken. Manchmal bitten wir Sie, etwas im laufenden Betrieb neu zu schreiben oder zu korrigieren. Wir stellen Fragen an das Formular "Aber wenn es noch eine solche Anforderung gab ...".
Als nächstes folgen 1-2 kleine praktische Aufgaben, die von der Testaufgabe abhängen. Wieder geben wir die Tastatur in die Hand (verbunden mit einem Computer, einem Computer mit Monitor!) Und bitten Sie, etwas zu schreiben oder zu bearbeiten. Eine meiner Lieblingsbeschäftigungen ist es, eine funktionierende, aber schlecht geschriebene Funktion für 10 bis 20 Zeilen zu geben und eine Umgestaltung vorzuschlagen. Es wird sofort klar, ob der Kandidat einen schlechten Code hat, was er über die Sprachkonstrukte weiß, ob er den Code eines anderen weiter unten auf der Liste lesen kann.
Und das ist es im Grunde. In maximal ein paar Tagen werden wir dem Kandidaten eine Antwort geben. Meistens wird die Antwort jedoch am selben Tag gegeben. Und im Falle eines Misserfolgs wird es wieder eine angemessene Begründung geben. Wenn dies nicht ausreicht, kann der Kandidat die Entwickler jederzeit um Kontakte aus dem Interview bitten, um einige Punkte zu klären, und sie werden sie höchstwahrscheinlich angeben.
Aber der Kandidat hätte täuschen können
Wahrlich. Könnte sogar
einen Zwilling schicken . Nun, er hat vielleicht nicht getäuscht, wir haben beim Interview nur einen Fehler gemacht. In einem solchen Fall gibt es eine wunderbare Sache, die als „Probezeit“ bezeichnet wird. Wenn Sie in einem großen Unternehmen arbeiten (zumindest in unserem Fall), bedeutet die Nichterfüllung einer Probezeit nicht, dass Sie sich hundertprozentig vom Unternehmen trennen. Am Ende konnte der Entwickler recht gut sein, hat sich aber nicht in einem bestimmten Team etabliert - in diesem Fall gibt es immer alternative Projekte.
Also hör auf! Ich erkannte das fragliche Team, interviewte sie vor ein paar Jahren und dort war das Schema ganz anders
Ja, ich bereue, dann habe ich mit kleinen Umfragen und Interviews ohne Test gesündigt. Verbrachte viel Zeit, sowohl seine als auch die eines anderen. Als es um neue Suchanfragen für den Entwickler ging, entschied ich mich für einen anderen Ansatz. Schreiben Entwickler Code? Großartig! Zeigen Sie mir Ihren Code und ich werde Ihnen sagen, ob wir interviewt werden sollen.
Aber ich habe es in der Firma herausgefunden! Eingelebt in ein anderes Projekt, und auch dort ist alles falsch!
Und hier ist die Situation mit der List. Ein anständiger Strom von Back-End- / Full-Stack-Entwicklern geht zu unserem Unternehmen, und es gibt mehrere Hundert solcher Entwickler im Unternehmen. Daher ist der Rekrutierungsprozess bereits fair geregelt und standardisiert. Mittlerweile gibt es nur wenige Entwickler von Mobilgeräten im Unternehmen, sodass wir leichter mit Interviewansätzen experimentieren können.
Der beschriebene Ansatz hat andere Nachteile!
Ich warte in den Kommentaren auf dich. Wir diskutieren ;-)