Weblabor

Elnézést, kicsit pontatlan voltam, köszönöm a pontosítást.

Természetesen az interjúztató sem tud mindent, tőle is lehet olyat kérdezni, amit nem tud :) Sőt, ha ketten megyünk akár ugyanabból a csapatból interjúztatni, akkor azt azért tesszük, mert egyikünk egyik, másikunk egy másik területen tudja jobban felmérni a jelölt tudását.

Ezek a kérdések nem is arra valók, hogy az interjúztató a felsőbbrendűségi érzését kiélhesse. Nálunk ez úgy megy, hogy minden jelölttel adnak egy pozíció leírást is, és azzal kapcsolatos kérdéseket kell feltenni. Meg persze általánosakat is. Átfedés mindig van. Vannak kérdések, amik a jelölt számára öncélúnak tűnnek, és valószínűleg azokról a kérdésekről gondolják ezt, amikre nem tudják a választ. Hisz ha valamire nem tudod a választ, nem is tudod miért kérdezik. Pár kérdéssel ki lehet deríteni valakiről, hogy bizonyos dolgokról, amik szerepelnek pl a cv-jében, milyen mély ismeretekkel rendelkezik. Ha pl beírja, hogy dolgozott x technológiával 2 évig, és azzal kapcsolatban felteszel egy kérdést, hamar kiderül, hogy csak használta, vagy vette a fáradtságot arra is, hogy utánamenjen, hogy mi az, amit használ, és miért. Ha nem ment utána, annak értelemszerűen komoly üzenete van. Ha ez csak 1-2 a cv-jében lévő technológiára igaz, akkor rá lehet fogni, hogy csak érintőlegesen használta. De ha pár technológiára van felfűzve az egész cv, akkor ott kilóg a lóláb, ha nem vágja. Pl volt, hogy valaki azt állította, hogy ismeri a springet. Amikor megkérdeztük, hogy milyen bean scope-okat ismer, akkor azt már nem tudta, pedig ez nem egy eldugott dolog benne... Interjúról kifelé jövet megbeszéltük a kollégával, hogy milyen szimpatikus srác, értelmesnek is tűnik, de sajnos nem tudtuk még biztonsággal felvételre ajánlani. A springes kérdéshez hasonló ez a js öröklődés dolog is. Ha erre a kérdésre nem kerül szóba a prototype akár válasz, akár visszakérdezés formájában, akkor az egy erős felkiáltójel az interjúztatónak.

Fontos még megemlíteni, hogy egy interjún nem kell mindenre tudni a választ. Sőt. Jelöltként én kimondottan azokat az interjúkat szeretem, ahol tudnak olyat kérdezni, amire nem tudom a választ, vagy nagyon el kell gondolkodnom. Ez egy jele annak, hogy jó helyen vagy, és tanulni fogsz, ha megállapodtok. És fordítva is fontos, interjúztatóként is kell tudd azt az érzést kelteni, hogy itt nálatok lehet tanulni, ergo érdemes elfogadja majd az ajánlatotokat. A dolog tehát az arányokon múlik, és persze hogy mire nem tudja a jelölt a választ.

Én jelöltként nagyon utáltam az olyan interjúkat, ahol csak egy igen/nem válasz jött. Abból számomra semmi nem derül ki (kivéve, amit én közben le tudtam mérni). Én nagyon értékeltem mindig az olyan interjúztatókat, akik azt mondták, hogy ezt jól tudtad, de ezek azok a területek, ahol még tanulnod kell, hogy a jövőbeli karriercélodat elérd. Szerintem ez korrekt. Bár tény, hogy kevesen mernek ilyen feedbacket adni, mert veszélyes. Nem mindenki szereti, és nem mindenki tolerálja.

És Pepitával egyetértve, szerintem jó dolog, hogy van ilyen bejegyzés a leggyakoribb interjú hibákról. Bár js területen nincs tapasztalatom, de javaban is megvannak ugyanezek a kérdések: ott főként collection és multithread területen megy a szétlövés. A kettő kombinációja meg aztán végképp magic.

Na de hogy olvasnivaló is legyen, interjú témában egy szerintem nagyon érdekes poszt Verhás Pétertől.

Illetve a java interjúk iránt érdeklődőknek egy angol nyelvű blog, ahol tematikusan össze vannak gyűjtve gyakran feltett kérdések: javarevisited

A "Hogyan adódnak át a paraméterek a függvénynek?" kérdésen nekem is el kellett gondolkodnom, hogy most mi is a kérdés. Nem jutott eszembe, hogy az érték-mutató kettősségre akar rákérdezni.
A "Hogyan működik az öröklődés JavaScriptben?" kérdésben pedig az a nehéz, hogy hogyan mondjak ne túl sokat és ne intézzem el mégis két szóval -- vagyis nehéz megítélni itt is, hogy milyen részletességgel kéri a kérdező.
A "Milyen értéket kap egy változó alapértelmezetten?" pedig lehet erősködni, hogy mondjuk a function zuzu(){} hatására is létrejön egy alapértelmezett változó, mégsem undefined.
Az utolsó kérdés pedig nem is JS.

Nyilván ez csak szőrszálhasogatás :-)

(egyébként a typeof az nem fv)

A jó munkához jó elméleti alapok kellenek, a fenti kérdésekkel pedig ezt jól fel lehet mérni. Szerintem nem gond, hogy a kérdések általánosak, mert így a delikvens szépen kifejtheti, ami a fejében van, meg lehet tudni, hogyan gondolkodik, mit tart fontosnak. Nem az a lényeg, hogy konkrét kérdésekre adjon konkrét válaszokat, hanem az, mennyire látja át a dolgokat, és egy ilyen beszélgetés megindítására a fenti kérdések nagyon jók.

Gyakorlati hasznuk is van a kérdéseknek, mert a referencia szerinti átadás nagyon hasznos dolog, én például sokáig nem voltam vele tisztában, emiatt egy csomó fölösleges kört futottam bizonyos helyeken.

JS-ben egyféle öröklés van, ne keverd ide azt, hogy mások miket szeretnének behozni más nyelvekből.

Hehe, elég figyelmetlenül olvasok, hogy nem szúrtam ki. Király összefoglalás viszont. Lehetne a következő blogposzt ;).

A referencia szerintet úgy értettem, ahogy Java-ban is van, azaz, ha módosítod a kapott elem tulajdonságait, az a hívott fél esetében is látszani fog. Azaz valójában az objektum referenciájának értéke adódik át (mivel máshogy nem is lehet objektumokra hivatkozni).

A függvényen belül amikor kiadod a qux={...} parancsot, akkor nem arról van szó, hogy a kifejezés jobboldalán kreálódik egy objektum, aminek a címét jelenti ezentúl a qux, a régi címet (qux-ot)tartalmazó rész pedig felülíródik ill. eldobásra kerül?
Mert ha így van, akkor mégiscsak a referencia adódott át, csak épp nem használtuk semmire, hanem rögtön ugyanazt a nevet (qux) egy másik objektum referenciájaként definiáltuk. (?)

Ha azt is érték szerinti átadásnak nevezed, ha a referencia értékét adod át, akkor nincs értelme az ilyen fajta megkülönböztetésnek, hiszen nincs olyan "átadás" ami ne valami értéket adna át (vagy ne adna át valami értéket) - mert az nem átadás hanem _semmi_.

Tetszik, hogy kivárod, amíg mindenki kibontja a véleményét, aztán csak a végén foglalsz állást. Én nem ismerem személyesen Poetro-t, csak általánosságban írtam, hogy mit gondolok az ilyen jellegű kérésekről. Plusz tegnap kötekedős hangulatban voltam, valószínűleg mert elmaradt a hétfői edzésem. :-)

A typeof null === "object" története valójában egy egyszerű implementációs hiba / felületesség okán következett be majd utána szabványosításkor bennhagytak a nyelvben (ha már szőrszálhasogatunk :P).

Történt ugyanis, hogy az első js implementációban az egyes JS oldali változók C világbeli mutatóit tartalmazó terület alsó pár bitjeiben tárolta tárolta az adott változó típusát (ezek adott architektúrán egy C "long" méretűek így volt hely, előbb jsword majd jsval lesz ebből a longból) és a 0 -ás érték az "object" típust reprezentálta.

A typoeof operátor csak megnézte a mutatott memóriaterület alsó 3 bitjét (JSVAL_IS_OBJECT(v)) ami simán össze "&"-eli a típus bitmaskokkal, és ez alapján döntött.

A JS-ben lévő null értéket C oldalon a 0 szám literál jsval-ba való castolása reprezentálja aminek alsó pár bitje bizony 0 bitekkel van feltöltve (az egész csupa 0 bit) és így illeszkedik object bitmaskjára és typeof már adja is vissza vidáman, hogy "object".

(Itt jegyezném meg, hogy minden szimpátiám a jövő archeológusaié akiknek esetleg forráskód nélkül kell felderíteni valamit :P)

Amennyire én tudom semmiféle "reprezentáljuk azt, hogy..." gondolat nem volt mögötte eredetileg, sőt maga Brendan Eich is ki akarta javítani ezt ES6-ban, de végül nem sikerült:
http://wiki.ecmascript.org/doku.php?id=harmony:typeof_null
(kettőspontot nem eszi meg bbcode url...)