Kodėl programavimo interviu Lietuvoje tokie specifiniai?
Lietuvos IT rinka per pastaruosius dešimt metų išaugo taip greitai, kad net pačios įmonės kartais nesuspėja susiorientuoti, ko iš tikrųjų nori iš kandidatų. Vilnius, Kaunas, Klaipėda – visur auga technologijų centrai, startuoliai, outsourcing’o kompanijos ir produktų įmonės. Kiekviena jų turi savo „receptą”, kaip atrinkti programuotoją. Ir tas receptas dažnai labai skiriasi.
Viena vertus, turime globalias kompanijas kaip Vinted, Tesonet, Hostinger, kurios jau seniai perėmė Silicon Valley standartus – algoritminiai klausimai, sistemos dizainas, elgesio interviu pagal STAR metodą. Kita vertus, šimtai mažesnių lietuviškų įmonių vis dar klausia „Ar moki Java?” ir tikisi, kad tai pakankamas filtras. Realybė yra ta, kad pasiruošimas interviu Lietuvoje reikalauja suprasti šį kontrastą.
Dar vienas niuansas – lietuviška IT kultūra yra gana tiesmuka. Čia retai rasite tą amerikietišką „hype” aplink interviu procesą. Žmonės kalba atvirai, klausimai kartais būna nepatogūs, o vertintojai tikisi, kad kandidatas irgi bus tiesmukus. Tai ne blogai – tiesiog reikia žinoti, į ką eini.
Techniniai klausimai: nuo bazinių iki „o tai jau rimta”
Pradėkime nuo to, kas beveik garantuotai atsitiks bet kuriame techniniame interviu. Nepriklausomai nuo pozicijos lygio, tikėkitės klausimų apie duomenų struktūras ir algoritmus. Tai nėra tik Google ar Facebook praktika – net vidutinio dydžio lietuviška įmonė, kuri kuria, tarkime, logistikos programinę įrangą, norės pamatyti, ar suprantate skirtumą tarp O(n) ir O(n²) sudėtingumo.
Dažniausiai pasitaikantys klausimai:
- Paaiškinkite skirtumą tarp stack ir heap atminties
- Kaip veikia hash map ir kokia jo vidutinė paieškos sudėtingumas?
- Parašykite funkciją, kuri apverčia sąrašą be papildomos atminties
- Ką reiškia rekursija ir kada jos geriau vengti?
- Paaiškinkite, kas yra binary search ir kada jį naudoti
Tačiau čia svarbu suprasti vieną dalyką: lietuviški interviu dažnai yra labiau praktiškai orientuoti nei teoriniai. Jums gali duoti realų kodą ir paprašyti rasti klaidą, o ne prašyti iš galvos pasakyti visus rūšiavimo algoritmus. Tai iš tikrųjų yra sveikesnis požiūris – ir geriau atspindi kasdienį darbą.
Vienas praktinis patarimas: prieš interviu peržiūrėkite įmonės GitHub repozitorijas (jei viešos) arba jų techninį blogą. Hostinger, Vinted ir kitos stambesnės įmonės reguliariai rašo apie savo technines problemas ir sprendimus. Tai suteikia neįkainojamą kontekstą.
OOP, dizaino šablonai ir visa ta teorija, kurios niekas nemėgsta mokytis
Objektinio programavimo klausimai – tai ta zona, kur daugelis kandidatų „paskęsta”. Teoriškai visi žino, kas yra paveldimumas ir polimorfizmas. Praktiškai – supainioja, kada naudoti kompoziciją, o kada paveldimumą, arba negali paaiškinti, kodėl Liskov Substitution Principle egzistuoja.
Lietuviškuose interviu OOP klausimai dažnai atrodo taip:
- „Paaiškinkite SOLID principus ir pateikite realų pavyzdį iš savo patirties”
- „Kuo skiriasi abstrakti klasė nuo interfeiso? Kada naudotumėte vieną ar kitą?”
- „Paaiškinkite Dependency Injection – kodėl tai naudinga?”
- „Kokie dizaino šablonai jums atrodo naudingi ir kodėl?”
Dėl dizaino šablonų – nereikia mokėti visų 23 GoF šablonų mintinai. Bet tikrai verta gerai suprasti Singleton, Factory, Observer, Strategy ir Decorator. Kodėl būtent šie? Nes jie dažniausiai pasitaiko realiame kode ir dažniausiai klausiami interviu metu.
Praktinis patarimas: mokydamiesi dizaino šablonų, nebandykite jų įsiminti abstrakčiai. Geriau pagalvokite apie realias situacijas. Singleton – tai kaip duomenų bazės konnekšnas, kurio nenorite kurti kaskart iš naujo. Observer – tai kaip naujienų prenumerata. Tokios analogijos padeda ir pačiam suprasti, ir interviu metu paaiškinti natūraliai.
Duomenų bazės: SQL vis dar karalius
Nepaisant NoSQL revoliucijos, MongoDB, Redis ir viso to triukšmo – SQL žinios Lietuvoje vis dar yra beveik privalomas reikalavimas absoliučiai daugumai backend pozicijų. Ir tai logiška: didžioji dalis verslo sistemų vis dar remiasi reliacinėmis duomenų bazėmis.
Ko tikėtis duomenų bazių klausimų srityje:
- JOIN tipai – INNER, LEFT, RIGHT, FULL OUTER. Ir ne tik teorija, bet ir praktinė užduotis parašyti konkretų query
- Indeksai – kaip veikia, kada padeda, kada gali pakenkti
- Normalizacija – bent jau 1NF, 2NF, 3NF supratimas
- Transakcijos ir ACID savybės
- N+1 problema ir kaip ją spręsti
N+1 problema yra ypač mėgstamas klausimas, nes ji yra labai reali ir dažna. Jei dirbate su ORM (Hibernate, Entity Framework, ActiveRecord), tikrai turėtumėte suprasti, kaip lazy loading gali sukelti šimtus nereikalingų query ir kaip tai ištaisyti naudojant eager loading arba JOIN fetch.
Dėl NoSQL – jei pozicija susijusi su dideliais duomenų kiekiais arba real-time sistemomis, tikėkitės klausimų apie Redis (caching, session storage) arba MongoDB (dokumentų modelis, agregacijos). Tačiau net ir tada SQL pagrindai bus tikrinami.
Vienas konkretus patarimas: pasitreniruokite su LeetCode SQL sekcija arba HackerRank SQL užduotimis. Tai ne tik padės pasiruošti interviu, bet ir realiai pagerins jūsų SQL rašymo įgūdžius.
Sistemos dizainas: kur atsiskiria junior nuo senior
Sistemos dizaino klausimai Lietuvoje vis labiau populiarėja, ypač vidutinio ir aukštesnio lygio pozicijoms. Prieš kelerius metus tai buvo tik didelių tarptautinių kompanijų praktika, bet dabar net ir vidutinio dydžio lietuviškos įmonės pradeda klausinėti apie architektūrą.
Tipiniai sistemos dizaino klausimai:
- „Kaip suprojektuotumėte URL shortener servisą?”
- „Kaip sukurtumėte sistemą, kuri apdoroja 1 milijoną mokėjimų per dieną?”
- „Paaiškinkite, kaip veikia load balancing ir kodėl jis reikalingas”
- „Kuo skiriasi microservices nuo monolito? Kada rinktumėtės vieną ar kitą?”
Svarbu suprasti: sistemos dizaino interviu nėra apie tai, kad duotumėte „teisingą” atsakymą. Nėra vieno teisingo atsakymo. Vertintojai nori pamatyti, kaip jūs mąstote – ar klausiate apie reikalavimus, ar galvojate apie skalabilumą, ar žinote kompromisus tarp skirtingų sprendimų.
Praktinis patarimas: prieš pradedant projektuoti sistemą, visada paklauskite patikslinančių klausimų. „Kiek vartotojų tikimasi?”, „Kokie yra latency reikalavimai?”, „Ar sistema turi būti globally distributed?” – tokie klausimai parodo brandą ir supratimą, kad architektūra priklauso nuo konteksto.
Rekomenduojama literatūra: „Designing Data-Intensive Applications” Martin Kleppmann – tai tikriausiai geriausia knyga sistemos dizainui suprasti. Ji nėra lengva, bet verta kiekvieno puslapio.
Elgesio klausimai: lietuviška versija
Čia įdomiausia dalis. Elgesio klausimai (behavioral questions) Lietuvoje yra… keisti. Didelės įmonės, kurios perėmė tarptautinius standartus, klausinės pagal STAR metodą (Situation, Task, Action, Result). Mažesnės įmonės gali tiesiog paklausti „O kodėl tu čia atėjai?” ir tikėtis sąžiningo atsakymo.
Dažniausiai pasitaikantys elgesio klausimai:
- „Papasakokite apie sudėtingiausią techninę problemą, kurią teko spręsti”
- „Kaip elgiatės, kai nesutinkate su komandos sprendimu?”
- „Apibūdinkite situaciją, kai reikėjo išmokti kažką naujo labai greitai”
- „Kaip dirbate su deadline’ais, kai atrodo, kad nespėsite?”
- „Kodėl norite dirbti būtent šioje įmonėje?”
Dėl paskutinio klausimo – lietuviški interviu vertintojai labai greitai pajunta, kai kandidatas duoda šabloninį atsakymą. „Nes jūsų įmonė yra inovatyvi ir aš noriu augti” – tai nieko nesako. Geriau pasakykite konkretų dalyką: „Perskaičiau jūsų techninį blogą apie tai, kaip perkėlėte sistemą į Kubernetes, ir tai man buvo įdomu, nes aš pats dirbu su panašiomis problemomis.”
Svarbus niuansas: lietuviška kultūra vertina nuoširdumą labiau nei performansą. Jei kažko nežinote – sakykite. Jei padarėte klaidą projekte – pripažinkite ir paaiškinkite, ko išmokote. Bandymas „parduoti” save per daug gali sukelti nepasitikėjimą.
Techniniai testai ir namų darbai: Lietuvos specifika
Vienas dalykas, kuris Lietuvoje yra labai paplitęs ir dažnai sukelia debatų – tai namų darbai arba techniniai testai prieš arba po pirmojo interviu. Kai kurios įmonės duoda 2-4 valandų užduotis, kitos – visą savaitgalio projektą.
Čia reikia būti sąžiningam: ilgi namų darbai yra problematiškai. Jei įmonė prašo 20+ valandų darbo be jokio atlygio, tai yra raudona vėliava. Gerbiančios save ir kandidatus įmonės arba moka už testinę užduotį, arba riboja ją iki 4-6 valandų.
Kaip gerai atlikti techninį testą:
- Perskaitykite užduotį du kartus prieš pradedant. Dažnai yra paslėptų reikalavimų
- Parašykite README, kuriame paaiškinate savo sprendimus ir kompromisus
- Pridėkite testus – net jei to neprašo, tai rodo profesionalumą
- Nepersistenkite su „fancy” technologijomis – paprastas, švarus kodas yra vertingesnis
- Jei kažko nespėjote padaryti – parašykite, ką darytumėte toliau
Dėl LeetCode tipo testų – tokios platformos kaip HackerRank, Codility yra plačiai naudojamos Lietuvoje. Vinted, Devbridge ir kitos stambesnės kompanijos dažnai naudoja automatizuotus testus kaip pirmą filtrą. Čia tikrai verta pasitreniruoti – ne dėl to, kad tokie klausimai atspindi realų darbą, bet dėl to, kad tai yra žaidimo taisyklės.
Kai interviu baigiasi ir prasideda derybos: ko nežino daugelis Lietuvos programuotojų
Techninė dalis baigėsi sėkmingai. Dabar prasideda kita dalis, apie kurią kalbama daug mažiau – derybos dėl atlyginimo ir sąlygų. Ir čia Lietuva turi savo specifiką.
Pirma, atlyginimų skaidrumas Lietuvoje gerėja, bet vis dar nėra tobulas. Reuse.lt, CVbankas, Linkedin Salary Insights – tai šaltiniai, kuriuos verta patikrinti prieš derybas. IT sektoriuje vidutinis senior backend programuotojo atlyginimas Vilniuje 2024 metais svyruoja tarp 3500-5500 EUR bruto, priklausomai nuo įmonės ir technologijų stack’o.
Antra, derybose svarbu ne tik atlyginimas. Klauskite apie:
- Nuotolinio darbo galimybes – tai vis dar svarbus klausimas po pandemijos
- Mokymosi biudžetą – konferencijos, kursai, knygos
- Techninę įrangą – ar įmonė perka gerą kompiuterį ar duoda savo seną laptopą
- Code review kultūrą – kaip atrodo tipinis PR procesas
- On-call reikalavimus – ar teks budėti naktimis
Trečia – ir tai labai svarbu – jūs taip pat interviu-jate įmonę. Klausimai, kuriuos užduodate pabaigoje, parodo jūsų brandą. „Kaip atrodo tipinė darbo diena?”, „Kokie yra didžiausi techniniai iššūkiai, su kuriais šiuo metu susiduria komanda?”, „Kaip komanda priima techninius sprendimus?” – tokie klausimai yra daug vertingesni nei „Ar yra nemokama kava?”
Galiausiai – neskubėkite. Jei gavote pasiūlymą, turite teisę paprašyti kelių dienų pagalvoti. Jokia rimta įmonė nespaus jūsų priimti sprendimą per valandą. Jei spaudžia – tai irgi yra signalas apie įmonės kultūrą.
Pasiruošimas kaip maratonas, o ne sprintas
Visa tai, kas parašyta aukščiau, gali atrodyti kaip milžiniškas kiekis informacijos. Ir iš dalies taip yra. Bet svarbu suprasti: niekas nesitiki, kad ateisite į interviu žinodami viską. Tikimasi, kad žinosite savo lygį, mokėsite mąstyti balsu ir nebijote pasakyti „nežinau, bet štai kaip bandyčiau tai išsiaiškinti.”
Jei šiuo metu aktyviai ieškote darbo, štai realus pasiruošimo planas:
- Pirmosios dvi savaitės: Pakartokite duomenų struktūras ir algoritmus. LeetCode easy ir medium lygis. Kasdien po 1-2 užduotis
- Trečia savaitė: SQL praktika, OOP principai, dizaino šablonai
- Ketvirta savaitė: Sistemos dizaino pagrindai, elgesio klausimų pasiruošimas
- Lygiagrečiai: Tinkinkite CV, atnaujinkite LinkedIn, pradėkite siųsti CV
Lietuvos IT rinka yra pakankamai maža, kad reputacija rūpėtų. Programuotojai pažįsta programuotojus, HR’ai pažįsta HR’us. Tai reiškia, kad net ir nesėkmingas interviu gali baigtis gerai, jei elgiatės profesionaliai ir paliekate gerą įspūdį. Atsiųskite padėkos laišką po interviu – tai Lietuvoje daro labai mažai žmonių, ir tai tikrai pastebima.
Svarbiausia – nesustokite po pirmų nesėkmių. Interviu yra įgūdis, kuris tobulėja su praktika. Pirmasis interviu visada bus blogesnis nei dešimtasis. Ir tai yra visiškai normalu – net ir geriausių Lietuvos IT kompanijų darbuotojai turi savo nesėkmingų interviu istorijų. Skirtumas tik tas, kad jie tęsė.
