Ah, a kódoló interjú.
"Retteg. Fuss el tőle. A sors ugyanúgy érkezik." - Thanos 2018Ok, talán ez egy kicsit drámai, de nem ismerek senkit, aki örülne az interjú folyamatának. Az álláskeresési / interjúfolyamat a legjobb esetben is kimerítő, a legrosszabb esetben sok minden más.
Sokan tanulmányozzák az interjú trükkjeit és taktikáit (és ezekből is adok neked néhányat), de az emberek többsége nem gondolkodik azon, hogy gondolkodásmódja belemegy-e az interjúra.
A gondolkodásmódja megadja a hangszínét annak, hogyan fogja szemlélni és alakítani a helyzetét. Menjen be a megfelelő gondolkodásmóddal, és képes lesz megérteni és eligazodni mindenben, amit rád vetnek. Szétszórt vagy félénk elmével lépjen be, és azon kapja magát, hogy megrengettek és megtépázták.
Te is a kérdező
Egy dolgot a legtöbb ember gyakran elfelejt, hogy te is kérdező vagy.
Igen, te, hogy interjút ennél a cégnél, de akkor is interjút a cég , hogy ha ők jól illeszkedik az Ön számára.
Melyek a vállalat értékei? Milyen a munkamoráljuk? Mit értékelnek az emberek?
Az interjú átadása fontos, de szeretne ebben a cégben dolgozni, ha mégis átmész?
Néha csak munkára van szükségünk - bármilyen munkára -, és ezért nem akarom minimalizálni a munkahely megszerzését. De ha teheti, tegyen egy lépést hátra, és gondolja át, hogy ez a munka hosszú távon hogyan befolyásolja karrierjét. Ha igent mond egy munkára, az azt mondja, hogy nem egy tucat embernek - igen sok alternatív költséget fizet az igennel.
Tehát ez az első dolog, amire emlékezni kell: ez nem egyirányú erődinamika. Lehet, hogy időnként úgy tűnik, de itt van némi irányítása, és vannak lehetőségei. Ez felhatalmaz.
Interjúk típusai
Ok, így vagyunk is értékeli a vállalat alapján az emberek kölcsönhatásba a beszélgetés folyamata, így mit csinálunk ezzel az információval?
Nos, van néhány különféle technikai interjú. Ezek az interjútípusok sokat elárulnak a vállalat gondolkodásmódjáról és arról, hogy milyen ott dolgozni. A különböző típusokat így bontom:
- Táblázat
- Kód kihívás (informatikai kérdések vagy algoritmusok)
- Kód kihívás (ésszerű kódolási probléma)
- Vidd haza projektet
A rettegett tábla
A technológiai ipar által elfogadott első interjú gyakorlatok közül néhány tábla volt. Feladatot kap, és felkéri, hogy írja be a kódot a táblára. Általában ezt a megközelítést lenézik, és manapság megszüntetik a technológiai iparban, de még mindig sok vállalat alkalmazza ezt a gyakorlatot.
Nem arról van szó, hogy a táblára történő kódolás önmagában is rossz -, de a tábla annyira távol áll attól a munkától, amelyet programozóként, akik nap mint nap számítógépeken dolgozunk, valóban elvégezzük . A táblára nehézkes ráírni, szerkeszteni, és nem ad visszajelzést - nincs automatikus kiegészítés, nincs szintaxis kiemelés, és nem is ugorhat be a Google-hez, hogy utánanézzen a standard könyvtár referenciáinak.
Ráadásul sok helyen, akik táblainterjúkat alkalmaznak, egy bizonyos interjúkérdést is feltesznek, amelyek őszintén szólva semmit sem érnek a programozási munkák 99% -ához. Ezek a rettegett informatikai algoritmusok: bináris fa megfordítása, a grafikonon a legrövidebb út megtalálása stb.
Ezekkel a kérdésekkel az a probléma, hogy egyszerűen nem a valós életben merülnek fel programozóként. Ha interjút készít az Amazon-on vagy a Facebookon, akkor biztos, hogy van valamilyen értéke ott, de az emberek többsége soha nem fog karrierje során szembesülni ezzel a problémával. És ha mégis, akkor csak valami csomagot vagy könyvtárat fognak használni, amely már megvalósította ezt a funkciót.
Tehát mit tehetünk a táblák ellen? Nos, a következőt tenném: tennék meg mindent a lehető legjobban, használnák az alábbiakban ismertetett tippeket és trükköket, és komolyan értékeljék, hogy ez az interjú gyakorlat a cégen belüli nagyobb mentalitási probléma tünete.
Kód kihívások
Ha szerencséje van kitérni a tábla elől, akkor a legtöbb hely (és valószínűleg meg is kéri) valamilyen kód kihívás megtételét. Ez megint egyirányú teljesítménydinamikának tűnhet, de ez a kód kihívás valójában jó az Ön számára. Itt ragyoghat és megmutathatja technikai kompetenciáját, és tapasztalatom szerint ez drasztikusan befolyásolja tárgyalási erejét a munkakör és a fizetés terén.
Mielőtt rátérnénk a konkrét tippekre, tisztában kell lennünk azzal is, hogy csak azért, mert elkerülted a táblát, még nem jelenti azt, hogy itt sem fogod megkapni a számítástechnikai algoritmus kérdését - csak egy számítógépen. Ha ez a helyzet, csak vegyen egy mély lélegzetet, és használja az alábbi tippeket és trükköket. Majd átvészeled.
Abban a szerencsében, hogy kitér a tábla és a CS kérdés elől, valószínűleg ésszerű kódolási kihívást jelentett Önnek. Számomra ezek olyan kérdések, mint:
Írjon olyan függvényt, amely 100 centinél kisebb vagy azzal egyenlőbb egész centet (USD) vesz fel, és kinyomtatja az ábrázolásához szükséges legkevesebb érmét.50 => 2 negyed
11 => 1 fillér és 1 fillér
7 => 1 nikkel és 2 krajcár
Olyan kérdéseket is kaptam, amelyek CS-kérdéseknek tűnnek , de valójában nem is olyan rosszak. Például: "implementáljon kétszeresen linkelt listát". Első ránézésre ez CS problémának tűnik a "kétszeresen összekapcsolt lista" rész miatt, de a kérdező valóban arra vágyott, hogy olyan kód legyen, amely ugyanazt a viselkedést valósította meg, mint egy kétszeresen linkelt lista - én nem használtam mutatókat és címzéseket tárgyak a memóriában - csak ugyanazt a viselkedést utánozzák. Ebben az esetben meglehetősen egyszerű kihívás lett.
És ez az első tippemhez vezet:
1. tipp: Tegyen fel tisztázó kérdéseket
A kétszeresen összekapcsolt listás kihívásban kaptam egy üres Ruby fájlt (egy Ruby munkához készítettem interjút) és egy üres tesztcsomagot. Valami ilyesmi:
class DoublyLinkedList end (Ha nem ismeri a Rubyt - ne aggódjon. Az itt található kódot egyszerűen meg fogja érteni. Csak az általános pontok bemutatására szolgál.)
Szóval, kétszeresen linkelt lista? Talán tudod, mi ez, vagy talán nem. Ha nem: tegyen fel kérdéseket. Ez az első elkerülendő buktató. Ha nem érti a problémát vagy azt, amit kérnek, kérdezzen tovább, amíg meg nem teszi.
Láttam, hogy az interjúalanyok rossz nyúlra mentek, és a kérdező csak hagyta őket - miközben csendben kudarcot vallanak. Bár nem értek egyet ezzel a gyakorlattal, győződjön meg róla, hogy a megfelelő problémát dolgozza fel.
Számítástechnikai háttérből származom, így tudtam, hogy a kétszeresen összekapcsolt lista egy olyan listát jelent, amelynek mutatója van egy headés egy tailcsomópontra - ahol minden csomópont rá is mutat nextés a previouscsomópontra.
Most, bár tudtam, mit tettem? Ezt hangosan mondtam, és megkérdeztem, hogy ez helyes-e. Annak ellenére, hogy azt hittem, tudom, mit kell tennem, teljesen biztosra vettem.
Miután úgy gondolja, hogy megértette a problémát, állítsa meg újra a megértő kérdést, hogy kijavítsa vagy eligazítsa.
A következő dolog az volt, hogy feltettem egy újabb kérdést: "Használhatok egy tömböt a csomópontokhoz?" És valami ilyet írtam ki:
class DoublyLinkedList def initialize @nodes = [] end end (Ha nem ismeri a Ruby-t, ez csak egy inicializáló vagy konstruktor, ahol egy új változót állítok @nodesbe üres tömbre.)
De a kérdező azt mondta nekem, nem, ezt nem tudtam megtenni - ennek van értelme. Ha tömböt használtam volna, akkor az a gyakorlat teljes célját legyőzte, amely a csomópontok közötti hamis "mutatókat" építi fel.
És fiú, örülök, hogy megkérdeztem. Nem akartam megragadni azt az esélyt, hogy a kérdező megengedte, hogy használjam a tömböt, majd megbukjon.
Tehát nincs tömb - hát mit tegyek most? Íme a 2. tipp:
2. tipp: Hardcoded -> Dumb -> Jobb
Amikor egy kódolási kihívással néz szembe, a problémát a következő sorrendben dolgozza fel: keménykódolt -> buta -> jobb -> még jobb (ha az idő engedi).
Interjúm és más fejlesztők megkérdezése során tapasztaltam, hogy a legtöbb ember egyszerre próbál túl sokat tenni.
Ha egyszerre túl sokat teszel, könnyen hibázhatsz (ezeket nem fogod elkapni az InterviewBrain ™ miatt). Kezdje tehát egyszerűen - a lehető legegyszerűbbet - kemény kódolással, és haladjon felfelé.
Tehát van egy üres Ruby osztályom, hogyan tudnék kódolni valamit az előrelépés érdekében? Megnéztem az üres tesztcsomagomat, és láttam, hogy van egy úgynevezett függvény, headamely visszaadta a lista első csomópontját, ezért próbáljuk ki:
class DoublyLinkedList def head 'A' end end Készítettem egy headfüggvényt, és keményen kódoltam az A betűt nagybetűként, és lefuttattam ezt a tesztet. Eltelt.
Ez szuper egyszerű? Túl nyilvánvaló? Igen! De ez a kód két nagyon fontos dolgot végez:
- Ez lehetővé teszi számomra a tesztek futtatását és a telepítésem működésének tesztelését (az ostoba vagy szintaxis hibák kiküszöbölését)
- Gyors győzelmet szerezek - ami növeli a bizalmamat
Számtalan olyan interjút láttam, ahol valaki már az elején elkövet egy apró hibát, elborzad, majd az interjú nagy részét azzal tölti, hogy helyrehozza és helyrehozza a rosszat.
Ne becsülje alá a gyors győzelmek értékét az önbizalma érdekében. A kis győzelmek összegyűjtése az interjún keresztül hajtja.
Oké, van egy hardcode kódolt húrunk 'A'. Most hogyan lehet ezt hülye megoldássá tenni? Nos, mit szólnál ahhoz, hogy az "A" betűt hashsá (vagy térképpé) tedd?
class DoublyLinkedList def head { value: 'A' } end end Ez egy kicsit jobb. Most egy karakterlánc helyett a "csomópontunkat" hashként ábrázoljuk egy valuetulajdonsággal. A keménykódolásból néma lettünk. Most hogyan tehetnénk jobbá? Nos, mi lenne, ha bemutatnánk a headmutatónkat a listában?
class DoublyLinkedList def initialize @head = { value: 'A' } end def head @head end end Mit változtattunk itt? Itt adjuk vissza az inicializálónkat, és létrehozunk egy új változót, amelyet úgy hívunk @head, és ezt az új változót használjuk a headfüggvényünkben. Ez kezd valódi kódnak látszani.
Most ez a megközelítés nagyon ostobának tűnhet, de ígérem neked, hogy működik. Ezek a változtatások másodpercek alatt kis, iteratív kódolással készülnek, és egymásra rakódnak, hogy rövid idő alatt működőképes megvalósítást hozzanak létre.
Ha azt gondolja, hogy ez a megközelítés furcsának tűnik egy potenciális kérdező számára, íme a következő tipp, és ez nagyon fontos:
3. tipp: Beszélj. Hangosan.
A kódolási kihívás teljes ideje alatt beszélnie kell - hangosan.
Mondjon mindent, amire gondol - mindent.
(Nos, minden, ami a programozással kapcsolatos.)
Ez a helyzet: a helyes megoldás elérése nagyon fontos, de ha nem is fontosabb, akkor megmutatja a gondolkodási folyamatát. A kérdező tudni akarja, hogyan gondolkodik - hogyan oldja meg a problémákat. Ezt úgy teheti meg, hogy mindent megoszt, amit hangosan gondol.
Minden interjúztató valamikor interjúalany volt - tudnak az InterviewBrain ™ -ről, és hogy az egyszerű dolgok is nehézzé válhatnak egy interjúban. A jó kérdezőbiztosok nem törődnek azzal, hogy a megoldást 100% -ban helyesnek találják - csak azt akarják tudni, hogy jó kritikai gondolkodási képességekkel rendelkezik. A belső gondolatok láthatóvá tételének egyetlen módja az, ha hangosan kimondja őket.
Ha még soha nem tett ilyet, érdemes gyakorolni, mert ez elengedhetetlen az interjú leszögezéséhez.
Hogy néhány gyakorlati példát mondjak, íme néhány dolog, amit minden egyes interjúban elmondok:
"Ok, csak kódoljuk be ezt az értéket, és győződjünk meg arról, hogy a beállításunk működik." "Először szerezzünk be egy működő verziót és tegyük jobbá." "Egyelőre így fogom csinálni, és ha van időnk visszatérni. és tedd. "" Ok, tehát szükségünk van egy olyan függvényre, amely befogad egy tömböt, megadja az X értéket és visszatér. "Bizonyos esetekben ezek az interjúk páros programozási munkának tűnhetnek.
Oké, szóval hangosan mondjuk a dolgokat. De néha hibázunk, vagy elakadunk. Hangosan beszéltük gondolkodási folyamatunkat, de most szükségünk lehet egy esetleges probléma vagy hiba vizsgálatára.
Itt van egy fontos tipp ehhez:
4. tipp: Maradjon logikus folyamatban
Most beismerem: ez néha nehéz lehet.
Ha interjúban van, és problémája vagy hibája van a kódjával, az agya kétségbeesetten akarja kideríteni, hogy mi a baj - de ne legyen túl kétségbeesett, hogy elkezdi dobni a kódot vagy a gondolkodási folyamatot.
Látja, ahogy a kérdező szeretné látni, hogyan bontja le a problémát, azt is meg akarja látni, hogyan hibakereső egy problémát. Ez ugyanolyan fontos, mint elmélete elmagyarázása. Próbáljon meg mindent megtenni, hogy logikus folyamatban maradjon, és ne dobja el a kódot vagy az ötleteit.
Ha jól megy
Tehát a kihívás jól megy, és kiütötte a problémát és az összes egyszerű dolgot.
És most? Hogyan juthat át a pasztól a zúzásig?
Ez rendkívül fontos része az interjúnak, mert itt kapja meg a legtöbb tőkeáttételt a munkaszint és a kompenzációs tárgyalások során. És a tipp:
5. tipp: Mutasd meg, mit tudsz
Te teljesíted a kihívást, hangosan beszélsz, és jól csinálod. A következő dologra, amelyet meg kell keresnie, az a lehetőség, hogy megmutassa tudását és szakértelmét.
Ez az a hely a kódban, ahová e-mailt küldhet? Említse meg, hogy ezt inkább háttérmunkában kell elvégezni (valószínűleg nem is kell végrehajtania).
Validációs logikán dolgozik egy modellben? Beszéljen arról, hogyan adna hozzá adatbázis-korlátozásokat az adatok integritásának biztosítása érdekében. Milyen indexeket adna hozzá? Hogyan valósítaná meg a migrációkat az állásidők megelőzése érdekében?
Amint megkapja a keményen kódolt -> buta -> jobb megoldást, beszéljen arról, hogyan refrakcionálná, ha több időt kapna. Hozzon létre egy modult ehhez? Mi a helyzet egy szolgáltatási objektummal? Mi lenne, ha e logika egy részét háttérmunkába helyeznénk? Beszélje meg a kompromisszumokat.
Miért ilyen fontos ez?
Az interjúk többsége a legalacsonyabb közös nevezőre irányul - ami a munka alapvető követelményeit jelenti. Magukat a kihívásokat vagy kérdéseket nem arra tervezték, hogy valakinek a legfelső szintjét teszteljék . Az interjú valószínűleg nem fogja húzni az információt belőled, így akkor kell megadnia, hogy az információ.
Tehát miközben gondolkodási folyamatát végigbeszéli, említse meg mindazt, amit beépítene egy valós alkalmazásba vagy kódbázisba, és megbeszélje azokat.
Extra tippek és trükkök megragadják a táskát
Tehát így kell megközelítenie az interjút, és meg kell küzdenie bármilyen kihívást.
Íme néhány extra trükk, amelyek néha felhasználhatók kis előnyökhöz.
1. trükk: Ismerje a gyakori problémákat
Van néhány gyakori probléma, amely gyakran megjelenik az interjúk során (különösen a táblákon). Ismernie kell ezeket a problémákat, mert ezek olyan kérdések, amelyekről tudod, hogy tesztelni fogják.
A két fő közül a FizzBuzz és a Fibonacci szekvencia megoldása (győződjön meg róla, hogy ismeri ezeket).
Most egy figyelmeztető szót: nem valaha szeretné letenni egy memorizált megoldás egy interjúban. Ez csak rosszul megy (és én is tanúja voltam annak, hogy megtörtént). Szeretné azonban megismerni a megoldást - és képes legyen újra létrehozni a semmiből.
Tehát használja az interjúkérdés előkészítő könyveit, igen, de győződjön meg róla, hogy megérti a megoldást, meg tudja magyarázni és újra létrehozhatja a semmiből. A memorizált válasz nem fogja eljutni ide.
2. trükk: Általában rendben van, ha megnézzük a dokumentumokat
Az összes interjúban, ahol részt vettem, vagy annak egy részében, senkit nem érdekelt, ha megnézi a szokásos könyvtárat vagy csomagdokumentumokat. A kérdezőbiztosok nincsenek rendben azzal, hogy megkeresik a választ (tehát elkerülném a StackOverflow-t), de a referenciákkal való konzultáció általában fair játék. Ha kétségei vannak, olvassa el az 1. tippet és kérjen magyarázatot.
3. trükk: Vigyázzon a vizuális jelekre
Ez valószínűleg a kedvenc tippem / trükköm. Ez nem a leghasznosabb, de szórakoztató. Az egyik interjúmat távolról készítettem, és képernyőmegosztó programot használtunk, és a képernyőm jobb felső sarkában láttam az interjúztató arcát.
A szeme sarkából vettem észre, amikor kódoltam, hogy a kérdező bólint a fejével. Ah ha! Egy kis vizuális jel arra, hogy tudom, hogy jó úton járok.
Megint nem sok, de hasznos lehet. :)
4. trükk: Ha távoli, akkor legyen jó beállítás
Ha távoli, ha távoli, akkor próbálja meg a lehető legjobban beállítani. Ez azt jelenti, hogy a kamera be van kapcsolva (ha lehetséges, ott állítsa be, ahová egyenesen belenéz), jó internet, számítógép csatlakozik áramforráshoz, csendes szoba, pohár víz a közelben stb.
Ezeknek a dolgoknak nem szabad befolyásolniuk az interjú eredményét, de nem kell bosszantanunk a kérdezőt, vagy különösebb stresszt kell adnunk magunknak az internet vagy a zaj okozta problémák miatt.
5. trükk: Legyen kedves!
Az utolsó trükk az Ön számára, hogy személyeskedjen.
Interjújában legyen valaki, akivel együtt szeretne dolgozni. Mutasd meg nekik a legjobb önmagadat.
Az interjúk megfélemlítőek lehetnek, és a fejlesztők általában csendesebb és visszafogottabb emberek, de meg kell mutatni az embereknek, akikkel kommunikálsz: "Hé, szórakoztató és kedves ember vagyok, akivel dolgozhatok."
Nem arra kérlek, hogy légy valaki, aki nem vagy. De nem akarsz az egyik közeli barátom szerint, aki folyton embereket interjúztat, "tengeri lény" lenni.
Bónusz trükk # 6: Végezze el az összes többi interjú előkészítést (ha akarja)
Ha alulképzettnek érzi magát, vagy ez az első technikai interjúja, végezzen néhány előkészítő munkát, amíg nem érzi jól magát.
Olvasson olyan könyveket, mint Cracking the Coding Interview, vagy gyakoroljon algoritmusokat és rejtvényeket a HackerRank-on.
Olvassa el a Developer News többi remek bejegyzését az interjúkról.
Ha teljes kötegű szerepkört kérdezel, készülj fel egy új projekt vagy tesztfájl beállítására tesztcsomaggal a semmiből.
Kutassa meg a vállalatot, legyen kész a vállalattal, a mindennapi munkával stb. Kapcsolatos nagy kérdésekkel stb.
Végül: ez csak egy interjú.
Végül az van, ami.
El fogod adni, ahogy teljesítesz.
Megkérdezi az a személy, akivel megkérdezik.
Interjúfolyamatuk lesz az interjú folyamata.
Talán szabadnapod volt - talán az interjúztatónak volt szabadnapja.
Utána, ha zavarban van, vereséget szenved, vagy bármi mást - vegyen egy mély lélegzetet, és engedje el! Ne hagyd, hogy a Gyík agyad megterheljen. A rossz interjú nem a világ vége. A karriered, a hírneved és az életed nem romlik el.
Ez csak egy interjú. Tanulj belőle, alkalmazkodj, és legközelebb legyél jobb.
Rendben van ideges
A legtöbb ember (beleértve engem is) ideges lesz, például interjúk, beszélgetések vagy előadások előtt.
Régebben az idegességet rossz dolognak gondoltam - olyan dologra, amit nem akartam. És nem számít, hányszor mondtam magamnak, hogy "ne légy ideges" - tippelj: ez csak idegesebbé tett!
Megtanultam újragondolni, hogy nézek az idegekre. Az idegesség a testem, amely harcra készül - ez az elsődleges harc vagy menekülési válasz.
De mint korábban mondtuk: ez csak egy interjú. Az interjúban nincs tigris. Ez az elsődleges válasz nem szükséges.
Elkezdtem átképezni magam, hogy az idegességet jó dolognak tartsam. Ez azt jelenti, hogy testem és érzékem megemelkedik, így a lehető legjobb teljesítményt tudom nyújtani.
Szóval, öleld át az idegeket. Csak arra készítenek fel, hogy a legjobban teljesíts.
Az interjú készség
Végül az interjú készség. A tanuláshoz némi tanulmány és sok gyakorlat szükséges.
Tehát ne verje meg magát, ha nem úgy teljesít, mint remélte. Tanulj tovább és gyakorold tovább - eljutsz oda!
Ha bármilyen kérdése vagy észrevétele van, forduljon hozzám bizalommal a Twitteren, és ha további információra van szüksége a fejlesztői karrierre való felkészülésről, ilyeneket írok a blogomba.
Köszönöm, hogy elolvasta!
János