logi sisse meist KKK
5
1

Mõni aeg tagasi jõudsin veendumusele, et programmeerijakandidaadilt otse intervjuul koodi kirjutamise nõudmine on absoluutselt vajalik. Nüüd otsikski ülesandeid, mida kandidaatidele esitada.

Loomulikult on olemas vana-hea Fizz-Buzz, aga otsiks veel sarnaseid, mis kogenud programmeerijale on käkitegu, aga oskamatu nurka suruvad.

Huvi pakuksid ka ülesanded, mis testiksid mingi teatud programmeerimiskeele oskust. Seda eeskätt sellel otstarbel, et kui keegi kirjutab oma CV-s et on ekspert keeles X, siis testida, kas see ka tegelikult nõnda on.

Ülesanne peaks mõistagi olema piisavalt väike, et vastuse saaks väheste ridadega paberile kirjutada.

küsitud Apr 20 '10 at 17:47

Rene%20Saarsoo's gravatar image

Rene Saarsoo ♦♦
1.1k101121


12järgmine leht »

See ehk ei puutu tööintervjuud, kuid koolis on küll üli lihtne testida, kes saab asjast aru ja kes mitte. Võib näidata näiteks suvalist kohta koodist ja lasta seda selgitada. Kood on tööandja poolt. Ma olen küll algaja alles, aga kui vaatan klassikaaslaste koode, siis saan täpselt aru, mis koodiridadel toimub. Kokkuvõttes, kui väidad, et oled X keele spetsialist, siis suudad kellegi teise koodist aru saada. Isegi siis, kui täpselt aru ei saa, siis oled suuteline oma teadmiste põhjal vastust tuletama.

Ma ei suuda praeguse taseme juures alati lambist ilma abimaterjalita korrektseid koode kirjutada. Pea ei ole prügikast, et kõik parameetrite arvud ja komad õiges kohas meelde jääksid. Kui saan abimaterjale kasutada, siis tuleb ka kood õige.

Kuidas kogenud programmeerijad teevad? Kas kõik asjad on tõesti peas? Ma saan aru, et teooria on selge, aga kõike funktsioone ikka pähe ei õpi ju, või õpite?

Nii palju, kui ma õppinud olen, suudan ka paberil asja valmis kirjutada, kuid seda meil koolis ei pooldata. Kui ma vahel alustan paberil koodi kirjutamist, siis õpetaja küsib, et miks ma arvutis ei kirjuta. Mulle lihtsalt meeldib paberil mõelda. Ma olen koodi kirjutades nii enesekindel, et ma ei pea seda alati testimagi, sest tean, et on õige. Seda kõike muidugi ainult õpitud osa piires.

link

vastatud Apr 22 '10 at 17:42

oivik's gravatar image

oivik
71113

edited Apr 22 '10 at 17:50

1

Jah, koodist arusaamise testimine tundub hea mõttena. Samas päris enda koodi kasutamine tundub mõneti ebaausa võttena... ja kandidaat võib ju alati selle peale vastata: "sitt kood, muidugi ma ei saa aru!" Kas just päris nii, aga midagi mind häirib. Ma vist suhtun sellesse intervjueerimisprotsessi kui mingisse teaduslikku eksperimenti. Märksa "õiglasem" variant tundub mulle kasutada hoopis koodi mõnest vaba tarkvara projektist.

(Apr 24 '10 at 08:56) Rene Saarsoo ♦♦

Kõiki funktsioone ei õpi tavaliselt pähe ka kogenuimad programmeerijad. Kuid olulisimad lihtsalt kuluvad pähe. Isiklikult leian, et kui ma pean mingit funktsiooni pidevalt manuaalist järgi vaatama, siis on probleem keele disainis. PHP-st ma ei hakka üldse rääkimagi, aga näiteks JavaScriptis on massiividel meetodid .shift() ja .unshift() ning mul on raskusi meelde jätmisega kumb neist lisab elemente massiivi ja kumb eemaldab. Probleemi põhjus on mu meelest see, et un-eesliite järgi võiks nagu oletada, et unshift võtab midagi ära, kuid tegelikult on vastupidi.

(Apr 24 '10 at 09:14) Rene Saarsoo ♦♦
1

PS. Oskus kirjutada koodi nõnda, et sa oled kindel selle töötamises ilma testimatagi, ongi vast üks olulisemaid asju. See on hiiglaslik samm ülespoole nendest "programmeerijatest", kes katse-eksitus meetodil koodi tööle saavad ning hiljem seda enam torkida ei julge, sest nad ise ka ei tea, kuidas see töötab. Neid viimaseid tahakski intervjuu käigus rangelt välja sõeluda.

(Apr 24 '10 at 09:25) Rene Saarsoo ♦♦

Samas koodi kirjutamine ilma testimiseta on selline kahe otsaga asi. Ühelt poolt räägivad paljud arendajad, et automaattestid on vajalikud vaid arendajale, kes ei tea täpselt, mida ta kirjutab. Teisalt on väga palju maailma tipptasemel arendajaid, kes väidavad, et automaattestid (või lausa testipõhine arendus) on kasulik olenemata arendaja tasemest, kuna aitab rakendust paremini (testitavalt) disainida ning teeb lihtsamaks hilisemad muudatused koodis. Aga eks see ole juba pigem eraldi arutlusteema.

(Apr 26 '10 at 13:01) Samuel Paal
1

Selle ilma testimata koodi kohta väike hoiatav näide: http://www.cypherpunks.to/~peter/04_verif_techniques.pdf, lk 13-14.

See on peatükk "Verification Techniques" Peter Gutmanni raamatust "Cryptographic Security Architecture: Design and Verification" (Springer, 2004).

Lühikokkuvõte: 25-realise programmilõigu korrektsust tõestati paberil umbes 5 korda; iga järgmine artikkel näitas, et eelmises artiklis toodud variandis on mingi viga, mis oleks vähese testimisega kindlasti välja tulnud, aga paberi peal jäi kahe silma vahele. Ja nende artiklite autorid polnud mingid tordisööjad :)

(Apr 08 '11 at 10:21) Ahto Truu ♦♦

Rene, "shift()" meeldejätmiseks pane tähele et sellise nimega funktsioon on olemas peaaegu kõikides skriptikeeltes, kusjuures ilmselt alguse see sai käsureaprotsessoritelt (nagu bash), kus massive polegi, ning shift liigutab argumente. Unshift on ilmselt JS loojate looming.

Teiseks, mõnede keelte puhul, minu arust (eelkõige C++), arusaam et saab "olla kindel programmi töötamises ilma selle testimatagi" (mis kiiresti tekib mõne teise keelega töötamise käigus) on praktikas eksitav.

(Apr 08 '11 at 11:14) kt ♦♦

JavaScript'i shift/unshift on tõenäoliselt selliste nimedega Perli mõjutustel, Perl aga laenas shift'i nime lugematutest shellidest ja AWK'ist, kus säärane käsk parameetriloetelu vasakule nihutab. Isegi MS-DOS'i command.com evib shift'i juba iidamast-aadamast (mis kurjade keelte andmeil võib tähendada versiooni 3.0).

See on umbes samasugune ajalooline pagas nagu car ja cdr listi esimese ja ülejäänud elementide nimedena — intuitiivne on ta siis, kui alusidioom tuttav on. Uued och Puhtad(tm) keeled nagu OCaml kasutavad muidugi palju intuitiivsemaid ja loetavamaid nimesid nagu hd ja tl.

(Jul 03 '11 at 23:00) dig
näitan 5/7 näita kõiki

Isiklikult olen kasutanud JavaScripti teadmiste testimiseks sellist ülesannet:

Defineeri funktsioon liida nõnda, et:

liida(2)(3) === 5;
liida(1)(2) === 3;
jne...

Selle lahendamine näitab kas kandidaat mõistab kõrgemat järku funktsioone ja sulundeid, mis JavaScripti puhul on küllaltki tähtis.

link

vastatud Apr 21 '10 at 08:47

Rene%20Saarsoo's gravatar image

Rene Saarsoo ♦♦
1.1k101121

Kordan sama mõtet, mis oivik juba ütles - koodi lugemine on raskem kui kirjutamine.

Mul ei ole olnud võimalust seda veel testida, aga olen mõelnud anda ette mingi lihtne algoritmike ja paluda esiteks kandidaadil selgitada, mida see algoritm teeb, ning teiseks paluda tal arvutada peast vastused paari parameetrikomplekti kohta. Minu arvates võiks see testida:

  • kandidaadi võimet konstrueerida oma peas lihtsustatud mudel selle algoritmi kohta (programmeerijana peame me iga päev looma oma peas mudeleid - kuidas mingi API käitub, millist käitumist kasutaja UI-lt ootab jne);
  • võimet seda mudelit seletada teistele (töötades meeskonnas pead sa pidevalt kommunikeerima oma ideid teistele);
  • võimet simuleerida peas algoritmi või selle lihtsustatud mudelit (see on minu arust kõige tähtsam - programmeerijana pead sa kõigepealt oma peas veenduma, et algoritm töötab õigesti, ühiktestid jms on lihtsalt selle veendumuse kinnistamiseks. kui kandidaat on algoritmi ideele pihta saanud, siis ta suudab parameetrikomplektile vastava tagastatava väärtuse välja öelda peaaegu momentaalselt, ilma muutujate väärtusi ükshaaval väljaarvutamata ja mustandpaberit kasutamata).
link

vastatud Apr 26 '10 at 08:32

Tambet%20Matiisen's gravatar image

Tambet Matiisen ♦♦
77791125

Mul oli paar aastat tagasi "au" olla kutsutud töövestlusele Skype'i. Läksingi, räägiti siit ja sealt, kõik oli tore, aga siis selgus, et oleks vaja teha ka mingi väike kodutöö. Meilile saadeti siis ülesanne ja see... see oli terve süsteem, mille pidid valmis kirjutama, kusjuures tuli kasutada just neid raamistikke ja andmebaase ja metoodikaid, mida nemadki. Mind häiris siis selle asja juures see, et seal olid tõesti asjad, mida nad ise kasutavad ja mida ma võib-olla ei olnud varem kasutanud. Ja häiris seepärast, et kui ma oleks ülesande täies mahus ära teinud, siis oleks mul vaja olnud paar nädalat kogu selle raamistiku, andmebaasi omapärade jmt õppimiseks. JA MA OLEKS SEDA TEINUD JU TASUTA!!! Ehk siis, ma teen tasuta endale asjad selgeks, siis ei pea firma vaeva nägema mu koolitusega.

Olin siis ja olen praegugi piisavalt hõivatud, et mitte oma aega raisata. Niiet, Skype'i ma ei läind.

link

vastatud Apr 21 '10 at 13:03

Muidumeez's gravatar image

Muidumeez
81113

1

Minu kogemus oli küll hoopis vastupidine.

Kodutöö oli tõesti parasjagu keerukas, raamistik ja andmebaas minu jaoks uued ning omamoodi takistus oli ka see, et üsna palju seni omandatud harjumustest tuli kõrvale jätta. Aga see tegigi kogu asja huvitavaks, väljakutsuvaks.

Sain kodutööga hakkama, sain ka tööle ja võin öelda, et siiamaani on see töö huvitav :)

(Apr 26 '10 at 19:30) Anti Veeranna

Ega siis inimesed on erinevd, sulle see sobis, mulle selline asi ei sobinud.

(May 02 '10 at 11:32) Muidumeez

Kahtlen sügavalt, kas mingi süntaksi korrektsuse kontrollimine midagi arendaja tasemest räägib. Mingi keele süntaks on õpitav paari nädalaga, see on pigem tehniline nüanss. Pigem oleks kasu ülesandest, mis kontrollib mingite ülesannete lahenduskäikude loogikat ja lahenduste disaini. Mingite algoritmide puhul võiks kasutada ka pseudokoodi ja OOP disaini võiks esitada näiteks UML-is vms. Tehnoloogiatest peaks aru saama, aga tehniliste detailide pähe tuupimine on natuke totter. Selleks on olemas manuaalid. Üks näide tööintervjuust: http://www.catonmat.net/blog/my-job-interview-at-google. See on muidugi natuke hardcore, aga äkki leiad sealt mingeid ideid, mida intervjuu käigus võiks küsida.

link

vastatud Apr 21 '10 at 08:16

Samuel%20Paal's gravatar image

Samuel Paal
862

Jah, täpne süntaks kindlasti pole oluline. Samas kui kandidaat väidab oma CV-s et on keeles X kõrgel tasemel, kuid ei suuda kirjutada korrektse süntaksiga näiteks for-tsüklit vms, siis see on mu meelest selge ohu märk.

(Apr 21 '10 at 08:40) Rene Saarsoo ♦♦

Avastasin sellise toreda asja: http://codility.com/

link

vastatud May 14 '10 at 23:44

ptr's gravatar image

ptr
31136

1

Tegemist on siis teenusega mis võimaldab töölesoovijaid testida mitmetes keeltes ja tasemetel. Seal on ka väike demo, proovige järgi ;)

(May 15 '10 at 01:07) ptr

Jagan ühte oma väga ammust "tööintervjuu-kogemust". Esimesele kohtumisele pidin kaasa võtma oma seniste tööde näidised, vestlus toimus vabas vormis ilma otseselt mingeid ülesandeid koha peal lahendamata.

Paar nädalat hiljem paluti koduse ülesandena kirjutada ühe CAD tarkvara jaoks lehtmetall-materjalist valmistatavate torude pinnalaotuste koostamise tarkvara. Testülesanne pidi oskama joonistada ühe tüüpelemendi - tüvikoonuse, mis võib kummastki otsast olla lõigatud mingi soovitud nurga alla - pinnalaotuse, ning pidi võimaldama täiendavate tüüpelementide (ka kandiliste) lihtsat lisamist. Pinnalaotuse joonistamine pidi toimuma nö. reaalajas, nii et iga parameetri või mõõdu muutmise järel oleks uus joonis koheselt valmis. Edasine tööprotsess pidi käima nii, et jooniste põhjal lõigati tükid välja, painutati või volditi ning keevitati kokku.

Eelnevalt leppisime kokku kui palju testülesande eduka lahendamise korral tunnis makstakse, ise pidasin tööajaarvestust. Lahendusega jäädi väga rahule. Kui hiljem ausalt ütlesin, et kõikide erinevate elementide pinnalaotusi ei oska/viitsi ma ise leida, siis piirduski kõik ainult testülesandega ja lahkusime sõpradena, mille üle mul tagant-järele tõeliselt hea meel oli, kuna sain rahulikult koolis edasi käia. Tohutult põnev oli, ja väga hea kogemus.

Võib-olla ei olnud sel ajal konkurents nii tihe, kuid nii mahukat kodust ülesannet ma tasuta küll sama innukalt ei oleks teinud.

link

vastatud Apr 07 '11 at 00:24

Taavi%20Tiirik's gravatar image

Taavi Tiirik
411

Üks vastustest siin pakub OOP kontrollimise jaoks küsida asju stiilis "kirjuta klass ...". Minu arust testib see küsimus ainult seda, kas inimene teab kuidas süntaktiliselt "klass" kirja pannakse, kuid ei ole absoluutselt seotud OOP idee teadmisega. Õige küsimus siin peaks võiks pigem näha välja nagu midagi sellist:

Näed projektis sellist koodi:

// Outputs file content
void output_file(int file_type, string& file_content, const void* fileMetainfo) {
  FileData* file_data = new FileData(file_content);

  if (file_type == TYPE_1) { 
    preprocess(file_content); 
     postProcess(file_content, *((long*)fileMetainfo));
    output_as_xml(file_data);    
  }    
  else if (file_type == TYPE_2) 
      perform_output(file_data, const_cast<A*>(fileMetainfo));
  else if (file_type == TYPE_3 || file_type == 42) 
  {
     output_as_string(file_content, 3, 4);    
  }
  else throw new Exception("Error in output_file: Unrecognized file type");

  delete file_data;
}

Mis on selle koodi probleem(id) ja kuidas seda paremaks teha?

link

vastatud Apr 08 '11 at 00:27

kt's gravatar image

kt ♦♦
112228

edited Apr 11 '11 at 13:47

See on kindlasti hea küsimus programmeerija hindamiseks: haritud programmeerija taipab, et temast oodatakse OOP rakendamist (või maagiliselt nummerdatud konstantide ümbernimetamist või veel midagi, mis parajasti popp ja noortepärane on), aga kogenud programmeerija küsib, millest Sa järeldad, et tegemist on probleemiga, mida tuleks lahendama asuda. Nende kategooriate ühisosa võib ka kenasti silma torgata.

(Jul 03 '11 at 23:13) dig

Kui programmeerija asub "vastuseks" küsima, miks ma arvan et siin probleem on, selle asemel et probleemile sõrmega näidata, pole ta vist eriti kogenud.

Tõsi küll, sõltuvalt sellest, milliseid probleeme vastaja suudab siin identifitseerida, võib midagi järeldada tema kogemuse kohta. Kas ta hindab koodi stiili? Kas ta oskab asju modulariseerida ja abstraheerida? Kas ta oskab OOP-d? Kas ta teab const modifierit? Kas ta oskab kasutada Exceptioneid? Kas ta teab mis on auto_ptr ning näeb siin mäluleket? Jne.

(Jul 04 '11 at 00:17) kt ♦♦

Pärismaailmas on Sul alati mingisugune põhjus probleemi kahtlustamiseks või mingit laadi kriitika tahtmiseks. Kas on plaanis kaua seisnud koodi uues raamistikus kasutada? On ehk märke dokumentatsiooni puudulikkusest?

Ilma kontekstita ei ole ükski mainituist probleem, puhtesteetilistel kaalutlustel võõra koodi muutmisega on kogenud programmeerija aga ettevaatlik.

Mäletatavasti saaksid paljud klassikalised Unixi riistad kenasti hakkama inkrementaalse malloc()'iga ja tühja free()'ga. Kui protsess sureb, siis vabaneb ka mälu. Kas selles ülesandes midagi säärast leidub, sõltub kontekstist.

(Jul 11 '11 at 23:49) dig

Küsimus pole selles "kas koodis olevaid vigu tuleb kohe hakata parandama", küsimus on selles, milliseid vigu intervjueeritav koodis näeb. Kui ta vastusena hakkab ajama mingit filosoofilist udu enne seda kui potentsiaalsete bugide peale sõrmega näitab, ma kahtleks tema kõrges kvalifikatsioonis. Aga kui juba udu ajama, siis võta kõrgemini - milles on elu mõte? Kas on üldse mõistlik tegeleda mingisuguste ülesannete lahendamisega kui selle asemel tasuks pigem minna oma Qi-energiat puhastama? Enne kui see selgeks saab, pole üldse selge kas antud ülesanne omab mõtet! Jne.

(Jul 13 '11 at 14:16) kt ♦♦

Parim programmeerimisülesanne on keelespetsiifiline ülesanne, mis koheselt näitab programmeerija taset. Ntx kuna enamus keeli on OOP, siis anda ülesanne teha klass, mis ntx korrutab ja teine klass, mis on selle järglane ntx jagab jne.

Sest elu näidanud, kui tase oli nõrk ei saadud OOP stiilis programmeerimises hakkama.

Soovitan selle näite teha paberi peale, kui kohapeal testimine, see muudab paljudki. Ei ole helpi ega Googlet

Igasugune algoritmidega testimine täiesti mõttetu, sest värskelt ülikooli lõpetaja mäletab neid veel, vanemad tegijad ei mäleta neid nii hästi enam. Boyer-Moore, Taylori rida jne

Koju võib anda ülesande, see oleks optimaalne, aga mitte nii, et ülesanne võtaks üle 2 päeva, siis see tõesti tasuta tööjõu kasutamine. Kui keegi teine ära teeb, selleks ongi küsimuste voor, sest kui inimene ei oska soravalt vastata, mida siin või siin tehakse, siis koheselt see näha.

Mina ntx kui Delphi programmeerimiskeele esindaja andsin ühe ülesande inimestele, programmi lähtetekstid tegin eelnevalt valmis. Oli vorm, kus peal 50 labelit ja palusin paaritud punaseks värvida. Reaalselt oli lahendus 4 koodirida, aga paljud hakkasid ükshaaval neid värvima label1.color:= .... jne

Siis istusin kõrvale ja palusin teha ühe ülilihtsa andmebaasi rakenduse, mis ühest tabelist andmed loeb ning ekraanile kuvab.

Viimaseks oligi eelpool kirjeldatud ülesanne, kus palusin nö klasside ülesande lahendada, kus pärimised sees, abstraktsionism jne

3 lihtsast testist piisas, et nõrgad lülid välja selekteerida

link

vastatud Apr 21 '10 at 06:32

Ingmar%20Tammev%C3%A4li's gravatar image

Ingmar Tammeväli
61246

Oskad ehk mõne näite tuua sellisest OOP-teadmisi testivast ülesandest? Su kirjeldatud korrutamise ja jagamise klasside loomine tundub kuidagi liiga lihtne. Teen lihtsalt klassi meetodiga korruta(a,b) ning teise klassi meetodiga jaga(a,b)? See vist pole päris see, mida mõtlesid.

(Apr 21 '10 at 11:17) Rene Saarsoo ♦♦

Ära seda korrutamist tõsiselt võta, enda kogemusest võin öelda, et kui OOP on nõrk, siis pole mõtet midagi head töötajalt loota. Samas Js OOP pole just parim; seal oleks Teil lihtsam lasta teha üks AJAX request ja saadud andmete kuvamine.

Ülesanne võiks sisaldada: pärimist/polümorfismi/abstraktseid meetodeid/constructori ülekirjeldamist

Ntx kasvõi ülesanne sõidukid sõidavad Tartu, sõidul on kestvus, sõidukil on nr jne. Ta ei peagi lõpptulemusena reaalselt midagi tegema, kui näed, et inimene järjest kirjeldab sama asja iga klassi all või tulevad glob.muutujad , siis tead, on probleem.

(Apr 21 '10 at 13:02) Ingmar Tammeväli

Mina isiklikult olen vestluse käigus küsinud tehnilisi küsimusi huvitava programmeerimiskeele spetsiifika kohta. Java korral näiteks, mis vahe on x == y versus x.equals(y). Samuti, mis vahe on x = "foo" versus x = new String("foo"). Vajadusel saab kirjutada mingeid lühikesi koodilõike, stiilis map funktsiooni realiseerimine anonüümsete klassidega. C/C++ puhul saab küsida põnevaid asju mäluhaldusest, C++ juures veel klasside defineerimise nüansid (virtual destructor, anyone?).

OO projekteerimisest saab lihtsalt juttu ajada või siis lasta teha klassiskeemi tasemel mingi ülesanne (näit. ilmajaam koos eri tüüpi anduritega).

Kodus ülesande lahendamist olen ka proovinud, aga see ei anna IMO eriti häid tulemusi. Häid ülesandeid on väga raske välja mõelda ja tulemuste põhjal on ka sageli raske järeldada. Kohapeal inimesega rääkides saab palju paremini aru, kuidas ta tegelikult mõtleb ja mis teemad talle raskusi valmistavad.

link

vastatud Apr 21 '10 at 12:15

Margus%20Freudenthal's gravatar image

Margus Freudenthal
212

Sinu vastus
lülita eelvaade

Jälgi seda küsimust

By Email:

Pärast sisselogimist saad tellida muudatuse teavitusi siit

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *kaldkiri* või __kaldkiri__
  • **paks kiri** või __paks kiri__
  • link:[tekst](http://url.com/ "pealkiri")
  • pilt?![alt tekst](/path/img.jpg "pealkiri")
  • nummerdatud nimekiri: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • põhilised HTML märgendid on samuti toetatud

Pinu tööpakkumised

kõik pakkumised »

Küsimuse sildid:

×1
×1

küsitud: Apr 20 '10 at 17:47

nähtud: 8,473 korda

viimati uuendatud: Jul 13 '11 at 14:16

Sarnased küsimused

Litsents: Creative Commons Attribution License | Kontakt: info@pinu.ee