Beszéljünk a táblainterjúkról és a lehetséges alternatívákról

Senkinek nem újdonság, hogy sok mérnök utálja a táblára épülő interjúkérdéseket.

Akár a Twitteren, a Mediumon vagy a LinkedIn-en található, könnyű megtalálni valakit, aki szellőzik. A „megszakadt a felvételi folyamat” kifejezést olyan gyakran használják, hogy közhelyévé vált.

Sajnos ennek a frusztrációnak a nagy része süket fülekre esik.

Annak ellenére, hogy körülveszi a harag, a „tábla” továbbra is a szoftverfejlesztési interjúk alapanyaga. Ennek részben az az oka, hogy a fejlesztők gyorsan hangot adnak ellenérzésüknek, de lassan kínálnak jobb alternatívákat.

Vannak jobb alternatívák?

Ez a kérdés az utóbbi időben nagyon is eszembe jutott. Négy hete adtam le első teljes munkaidős szoftvermérnöki munkámat. Bár még nem veszek részt a felvételi folyamatban, végül mégis az leszek.

Alig egy hónapja az asztal túloldalán vagyok, és megértem, hogy az interjúkészítés mennyire pontatlan lehet. Amikor rám kerül a sor, hogy feltegyem a kérdéseket, szeretnék megbizonyosodni arról, hogy pontosan és tisztességesen értékelem a lehetséges kollégáimat.

Ez a nehéz helyzet két kérdéshez vezetett:

  1. A táblainterjúk a legjobb választás?
  2. Ha nem, mik a jobb alternatívák?

Ebben a bejegyzésben megpróbálom megválaszolni ezeket a kérdéseket. Ne feledje, hogy ezek a személyes véleményeim, amelyeket saját interjúk tapasztalatai alakítottak ki.

Igyekszem a lehető legobjektívebb lenni, ha ezt a feladatot valódi szoftverfejlesztési módon közelítem meg: megvizsgálom az összes lehetőséget és mérlegelem azok kompromisszumait.

A táblainterjúk a legrosszabbak?

Ennek a folyamatnak az első lépése a tábla alapos vizsgálata.

Előnyök:

  1. Gyors és alacsony erőfeszítés
  2. Nem nyelv- vagy tartományfüggő
  3. Tudja (általában) mire számíthat
  4. Közösségi támogatás (Glassdoor, LeetCode, Pramp és így tovább)

Hátrányok:

  1. A szerencse nagy tényező (algoritmus lottó)
  2. Nem feltétlenül teszteli a mérnöki alkalmasságot
  3. A fiatal mérnököknek és a legutóbbi diplomáknak kedvez

Azoknak a vállalatoknak, akik megkövetelik, hogy a mérnökök jól ismerjék a CS alapjait, az alacsony szintű algoritmusokat, és nem függenek a könyvtáraktól, a táblainterjú tökéletes.

A SpaceX-et, a MacOS / Windows-ot és a Facebook React-et egyaránt ilyen tudással rendelkező mérnökök építették. Számítani kell arra, hogy e társaságok egyikétől táblainterjút kapjon.

Állásjelöltként imádom a táblainterjúkat. Tudom, mire számíthatok. A legtöbb algoritmusi kérdés ezekre az általános témákra terjed ki:

  • Tömbök / karakterláncok
  • Bináris fák
  • Összekapcsolt listák
  • DFS / BFS
  • Visszalépés
  • Dinamikus programozás

Ennek idő előtti ismerete azt jelenti, hogy tanulhatok érte. És rengeteg tanulmányi eszköz közül lehet választani. A technikai interjúkészítés egy teljes saját iparág.

Éppen ezért a táblainterjúk nem a legjobb megoldás minden vállalat számára. Annyi minden a szerencséhez, a memorizáláshoz és ahhoz tartozik, aki a legtöbb időt tanulással töltötte.

Nem mindenki tanulhat sokáig algoritmusok elsajátításához.

Szerencsém volt, hogy tudtam, és felülmúltam a többi mérnököt, akik nem. Jobb mérnök vagyok, mint mindegyik? Lehet, de nem vagyok biztos benne, hogy a táblainterjú a legjobb eszköz annak feltárására.

Tehát, ha kétséges, hogy a táblainterjú a legjobb eszköz a munkához, mi lehetne jobb?

Vessünk egy pillantást az alternatívákra.

A kihívások kódolása számítógépen keresztül

Előnyök:

  1. Használja a számítógépet és a megszokott fejlesztői környezetet
  2. Távolról is elvégezhető a képernyőmegosztáson keresztül
  3. A táblainterjúk összes többi előnye

Hátrányok:

  1. Szigorúbb a szintaxis és a futtatási képesség.
  2. A programozási környezet és a beépülő modulok nagy szerepet játszhatnak
  3. A táblainterjúk azonos hátrányai

A hordozható számítógépes kódolási kihívások a táblainterjú kevésbé szigorú unokatestvérei.

A pályázóknak előnye, hogy saját számítógépet használnak. Távolról vagy páros programozási környezetben végezhetők.

Egy szép dolog, amit észrevettem ezekben, hogy általában könnyebbek lesznek, mint a táblára vonatkozó kérdések. A legtöbb kérdést vonósmanipulációval vagy olyan egyszerű algoritmusokkal vontam be, amelyeket semmilyen tapasztalt mérnöknek nem kellene tanulmányoznia.

Ennek hátránya, hogy sokkal nagyobb hangsúlyt kap a funkcionalitás.

Álláskeresésem alatt kétszer is megkérdezték tőlem az Érme csere problémát. Az egyik mint tábla kihívás, a másik pedig egy szerkesztő.

A faliújság kihívására megúsztam főleg a megoldásom magyarázatát. A laptopomon elvárták, hogy éles teszteket írjak és garantáljam, hogy a megoldásom működik.

Részben az ok, amiért szeretem a táblát, az engedékenységnek köszönhető. Senki nem fogja lefuttatni az írott függvényét egy fordítón keresztül. Amíg a kérdező megérti, mire gondol, és az írás elég jól néz ki, teljes hitelt kap.

Nem a kódkihívásokkal.

Néhányan azt állíthatják, hogy a funkcionalitás hangsúlyozása nagyobb, mert fizetünk azért, hogy munkakódot írjunk. Ez igaz, de nem kapunk fizetést azért, hogy 30–45 perces sprintekben végezzük.

Reméljük csak, hogy nem fog ideges lenni az interjúk során. Egy kis hiba, amely sikertelen teszteket okoz, és néhány perc hibakeresés lehet a különbség az „erős bérlés” vagy a passz között.

A kódproblémák továbbra is ugyanazokkal a rövid távokkal küzdenek, mint a táblák, mivel sokuk algoritmus-alapú.

A funkcionalitás megnövekedett nyomásával a kényelmes környezet ellenére még nehezebbé teheti a kérdéseket. Ha már nem szereted az algoritmusproblémákat, a kód kihívásai nem lesznek sokkal jobbak.

Vigye haza az értékeléseket

Előnyök:

  1. Pizsamában dolgozhat rajta
  2. Általában egy hétig felfelé kapják a megbízást
  3. Használja saját szerkesztőjét és fejlesztői környezetét
  4. Új kiegészítője lehet a portfóliónak
  5. Általában szórakoztatóbb, mint a tábla

Hátrányok:

  1. A nehézségi szint drasztikusan változhat
  2. Sokkal több erőfeszítés és időigényes, mint a kihívások kódolása
  3. Tartományfüggő lehet
  4. A verseny miatt jellemző kúszáshoz vezethet
  5. Nem jelenti a napi munkát

Sok mérnök szívesebben viszi a házi feladatokat. A benyújtásuk ütemezése általában rugalmas, és a jelöltek eljutnak a tényleges kódoláshoz. Nem megdöbbentő a programozók, hogy ezt inkább választják, mint egy tábla előtt, miközben némán ítélik meg őket.

A házi teszteknek azonban vannak hátrányai.

Először is, könnyen kezelhetők.

Számos vállalat szervezi tesztjeit a GitHubon. Írja be a „Kihívás” vagy a „Teszt” kifejezést a GitHub keresőbe, és rengeteget talál. Ez rengeteg időt fog adni a hozzáértő jelöltnek a kihívás előzetes kutatására.

Ez valójában nem panasz. Csak inkább egy profi tipp.

Mi az a kérdés, hogy ez elég könnyű találni más emberek választ ezekre a kihívásokra, és másolja őket. Rengeteg mérnök tartja meg a válaszokat, hogy házhoz szállítson kihívásokat GitHub profiljain.

Akár magad is kipróbálhatod. Írja be a „Challenge” kifejezést a GitHub keresőbe, és nézze meg, mit talál.

Brooklynban, az Etsy központja mellett élek, és kíváncsi voltam, hogy találok-e választ néhány tesztjükre. Az „Etsy Challenge” négyet mutatott ki. Még több volt az „Etsy teszt” alatt.

Igaz, hogy a vállalatok megváltoztathatják értékelésüket. Nehézség lehet azonban egy interjúfolyamat pár havonta történő megváltoztatása a részletek kiszivárogtatása miatt.

Másodszor, a kihívások teljesítéséhez szükséges nehézségi szint és idő nagymértékben változik.

A legutóbbi állásvadászatom során négy házi feladatot kaptam. A vállalatok közül három azt mondta, hogy csak 3–5 órát kell igénybe venniük.

Mindegyik több napot vett igénybe.

Ennek fő oka az volt, hogy a kihívások gyakran területspecifikusak voltak. Több órás kutatást igényeltek az API dokumentumok és az új technológiák terén.

A negyedik társaság olyan kihívást fogadott el, amely könnyen eltarthat egy hétig, és két napot adott nekem. Ki kellett építenem egy működő csevegőalkalmazást, amely támogatta a perjelparancsokat.

Szórakoztató és érdekes projekt volt, de megkövetelte, hogy mindent befejezzek, amit két napig csináltam.

Ha a jelöltnek van szerencséje több vállalattal egyszerre interjút készíteni, akkor teljes munkaidős munkává válhat, ha csak ezen kihívásokon dolgozik.

Ezenkívül a professzionális fejlesztőknek meg kell dolgozniuk a régi kódbázisokat és kezelniük kell a határidőket. Egy héten át tartó zöldmezős projekt nem fogja felmérni, hogy az interjúalany mennyire működik gyors iramú környezetben.

Összességében szeretem a házi feladatokat a jelölt képességeinek kezdeti képernyőjeként venni. Ennek ellenére kapcsolatban kell állniuk azzal a munkával, amelyre a jelölt pályázik, és nem szabad, hogy obszcén időt töltsön el a befejezéséig.

Projekt alapú / bérleti szerződés

Előnyök:

  1. Szerezzen esélyt arra, hogy együttműködjön a jelölttel / csapattal
  2. Fizetjen a munkáért
  3. Kezdje el dolgozni valódi projekteken
  4. Értékelik, mennyire működik együtt a csapat és a hajó kóddal

Hátrányok:

  1. Hosszú ideje elkötelezettség
  2. Munka garancia nélkül
  3. Vállalkozóként nincs egészségügyi előnye
  4. Rossz tárgyalási helyzetbe hozhatja a jelöltet
  5. Nyelvfüggő

A projektalapú interjúk ritkák. De jó néhány cég kiáll mellettük, például a Basecamp és az Automatic. Megértem miért.

Ezek az interjúk valószínűleg a legpontosabb módja annak, hogy felmérjék valaki képességeit és értékeljék őket mint csapattagokat. A vállalat közvetlenül velük dolgozik, és megnézheti, hogyan kezelik a csapatban a feladatokat.

A jelölt lehetőséget kap arra is, hogy értékelje a vállalatot, és megállapítsa, hogy az milyen típusú környezetben szeretne dolgozni.

Win-win. Vagy legalábbis úgy tűnik.

Mindezek alapján állásjelöltként soha nem veszek részt projektalapú interjúkban vagy szerződéses bérbeadási szerepekben. A negatívumok messze felülmúlják a pozitívumokat.

Bármely munka első pár hónapja általában a legnehezebb. Új csapathoz, kultúrához, kódbázishoz igazodik. Most képzelje el, hogy egy projekten dolgozik, és nem tudja, hogy a végére lesz-e munkája.

Egy jó barátom nemrég interjút készített az Automatic-nál, és megerősítette, hogy ez milyen stresszes lehet. A munkatársakkal való kapcsolatfelvételtől kezdve a feltett kérdésekig mindent megítélnek. Ezekben a környezetekben is van olyan dolog, mint a „hülye kérdés”.

A legrosszabb, hogy a három hónapos szerződés után elengedték. Szerencsére nem hagyta, hogy ez befolyásolja önértékelését. Ismeri képességét, és előre tölt. Nem vagyok benne biztos, hogy én vagy sok más mérnök ugyanolyan könnyen megtehetnénk ugyanezt.

Továbbá a szerződések borzasztó tárgyalási helyzetbe hozzák az álláskeresőt. A tárgyalások erősségét a távozásra való hajlandóság adja.

A bérleti szerződés végére a potenciális jelöltnek nincs alku. Nem lesznek más ajánlataik, és már több tucat vagy száz órát öntöttek projektjeikbe, a szerződés hosszától függően.

Ösztönzést kapnának arra, hogy állást foglaljanak, még akkor is, ha ez nem az általuk preferált választás. Az alternatíva az első helyen való visszatérés a munkaerőpiacra.

A Sunk Cost Fallacy a legjobbak szerint.

Bár a táblainterjúk nem biztos, hogy ideálisak, százat megcsinálnék, mielőtt valaha is készítettem volna projektalapú interjút.

Tehát melyik a legjobb?

Ahogy sejteni lehetett: Attól függ ™.

Úgy tűnik, hogy a kompromisszumok a sebesség és az erőfeszítés, illetve a pontosság között vannak. Mindegyik módszer feláldozza a másikat. Minden vállalatnak saját maga kell megítélnie ezeket a kompromisszumokat. A SpaceX valószínűleg más lesz, mint a kis New York-i indítás.

Igaz, hogy egy SaaS vállalat csak akkor kéri a jelölteket, hogy írják ki a dinamikus programozási algoritmusokat, ha ez segít nekik meghatározni a mérnök képességeit. Nem egyszerűen azért, mert a Google csinálja.

Ha az interjú folyamatát tervezném a DigitalOcean-i csapatom számára, akkor a házhoz szállítás és a kód kihívások / párosítási gyakorlatok keverékét használnám. A rendelkezésre állás és az elosztott rendszerek megértését egy Q&A munkamenet és egy rendszertervezési kihívás révén is felmérném.

A jó hír az, hogy a csapatom már ezt is csinálja. A DigitalOcean kemény, mégis korrekt interjúfolyamata volt az egyik oka annak, hogy elfogadtam az ajánlatukat. Számomra bebizonyosodott, hogy már átestek ezen az önvizsgálati folyamaton, és megtudták, hogyan kell méltányosan értékelni jelöltjeiket.

Kérjük, tudassa velem, mi az Ön által preferált interjú módszer az alábbi megjegyzésekben!

Végül kezdje el ötleteivel mindazokat a mérnököket, akik szeretnék látni az interjú folyamatának változását. Túl sok mérnököt láttam a táblainterjúk miatt, hogy folytassák a folyamatot, miután felvették őket, mert túl sok munka változtatni rajta.

Ne légy az a személy.

Fejezd be a panaszkodást.

Megoldások keresése.