Joel on Software

Joel on Software   От Джоел за софтуера

 

Други статии от "Joel on Software" на български

Други статии от "Joel on Software" на английски

Пишете на автора (само на английски)

 

Партизанско ръководство за интервюиране


От Джоел Сполски
Превод: Евтим Георгиев
Редакция: Mariela Kopcheva
23 март, 2002

Да се наемат подходящите хора е от изключителна важност за Fog Creek Software. В нашата област има три типа хора. От едната страна стоят напълно некомпетентните, на които им липсват дори най-примитивните умения за този вид работа. Лесно е да бъдат изловени и елиминирани, често само с преглед на резюмето им и два-три бързи въпроса. На противоположната страна са брилянтните мегазвезди, които пишат lisp компилатори за собствено удоволствие, през уикенда, на Асемблер, за Palm Pilot. А по средата имате голям брой от "може би"-та, които изглеждат сякаш могат да допринесат с нещо. Номерът е да откриете разликата между мегазвездите и "може би"-тата, защото във Fog Creek Software наемаме само мегазвездите. Ето няколко техники как се прави това.

Първо, основеният критерий номер едно за наемане във Fog Creek:

Умни и
Свършват Работата

Това е. Това е всичко, което търсим. Запомнете го. Рецитирайте си го всяка вечер преди лягане. Нашата цел е да наемем хора, притежаващи дарба, а не определен набор от умения. Всеки набор от умения, с който хората започват работа, така или иначе ще бъде технологична отживелица след две-три години, затова е по-добре да се наемат хора, които по-скоро ще могат да овладеят която и да е нова технология, отколкото хора, които случайно знаят да програмират на SQL точно в този момент.

Умен е трудно за дефиниране, но разглеждайки няколко възможни въпроси за интервю, ще разберем как можете да откриете умните кандидати. Свършва Работата е решаващо качество. Хората, които са Умни, но не Свършват Работата, често имат професорска степен и работят в големи компании, където никой не им обръща внимание, защото са напълно безполезни. Те по-скоро биха се отклонили към абстрактната страна на даден проблем, отколкото да го завършат навреме. Този тип хора могат да бъдат разпознати, понеже често обичат да изтъкват теоретичните сходства между две широко разминаващи се концепции. Например, те ще кажат "Spreadsheets са наистина просто частен случай на програмен език" и после ще се измъкнат за седмица, и ще напишат вълнуваща, брилянтна статия за теоретичните атрибути на изчислителната лингвистика на sphredsheet като програмен език. Умни, но не и полезни.

Сега, хората които Свършват Работата, но не са Умни, биха направили глупави неща, привидно без да се замислят, а после някой друг ще трябва да оправя бъркотиите им. Това ги прави пасив за компанията, защото те не само не допринасят нищо, но и прахосват времето на добрите. Те са този тип хора, които по-вероятно да копират големи отрязъци код напред-назад, отколкото да напишат подпрограма. Това свършва работата, но не и по най-добрия начин.

Най-важното правило при интервюирането:

Вземи Решение

В края на интервюто ще трябва да сте готови да вземете трудно решение за кандидата. Съществуват само две възможности за това решение: Наемете или Не Наемайте. Обърнете се към компютъра си и изпратете незабавен отговор на работодателя. Заглавието на писмото трябва да бъде името на кандидата. Първият ред на писмото трябва да е Наемете или Не Наемайте. После би трябвало да отделите около 2 параграфа в подкрепа на решението си.

Няма друг възможен отговор. Никога не казвайте "Наемете го, но не и в моята група". Това е грубо и намеква, че кандидатът не е достатъчно умен, за да работи с вас, но може би е достатъчно умен за онези загубеняци в другата група. Ако се хванете, че се изкушавате да кажете "Наемете го, но не в моята група", просто механично заменете с "Не наемайте" и всичко ще е OK. Дори и ако имате кандидат, който ще е брилянтен в една определена работа, но не би бил много добър в други неща, това е Не Наемайте. Нещата се променят толкова често и скоростно, че ние се нуждаем от хора, които могат да успеят навсякъде. Ако, поради някаква причина, откриете идиотa учен, който е наистина, наистина, наистина добър в SQL, но напълно неспособен някога да научи други неща, Не Наемайте. Такъв човек няма бъдеще във Fog Creek.

Никога не казвайте "Може би, не мога да преценя". Ако не можете да прецените, това значи Не Наемайте. Наистина е по-лесно, отколкото бихте си помислили. Не можете да прецените? Просто кажете не! По същия начин, ако сте на границата, това означава Не Наемайте. Никога не казвайте, "Ами, Наемайте, предполага, но съм малко притеснен за ..." Това също е Не Наемайте.

Важно нещо, което трябва да запомните за интервюирането, е следното: много по-добре е да отхвърлите добър кандидат, отколкото да одобрите лош кандидат. Един лош кандидат ще струва много пари и усилия и ще хаби времето на другите хора, за да оправят всичките му бъгове. Ако въобще имате някакви съмнения, Не Наемайте.

Докато провеждате интервюто, не се притеснявайте, че ако отхвърлите много хора, Fog Creek няма да наеме никой. Това не е ваш проблем. Това е проблем на работодателя, това е проблем на личен състав, това е проблем на Джоел, но не е ваш проблем. Не спирайте да се питате кое е по-лошо - да прерастнем в голяма, червива софтуерна компания с много тиквеници, или да останем компактни, но висококачествени? Разбира се, че е важно да търсим добри кандидати и всеки трябва да възприема като част от мисията си да открие и наеме умни хора, които свършват работата. Но веднъж, след като сте интервюирали някого, престорете се, че Fog Creek има предостатъчно добри кандидати. Никога не занижавайте стандартите си, независимо колко трудно ви се струва да откриете страхотни кандидати.

Но как вземете това трудно решение? Просто по време на интервюто трябва постоянно да се питате: умен ли е този човек? Свършва ли работатта? За да можете да си отговорите ще трябва да зададете подходящите въпроси.

Просто за майтап, ето най-лошия въпрос на света: "Каква е разликата между varchar и varchar2 в Oracle 8i?" Това е ужасен въпрос. Не съществува вероятна, въобразима взаимовръзка между хората, които знаят тази конкретна частица безполезна баналност и хората, които Fog Creek иска да наеме. На кого му пука каква е разликата? Всеки може да я открие онлайн за 15 секунди!

Всъщност, съществуват някои дори още по-лоши въпроси. Ще се върна на това по-късно.

Така че, нека сега да се захванем със забавната част: въпроси за интервю. Моят списък от въпроси за интервю идва от първата ми работа в Microsoft. Всъщност съществуват стотици известни въпроси за интервюта на Microsoft. Всеки си има набор от въпроси, които наистина харесва. Вие също ще развиете определен набор от въпроси и личен стил на интервюиране, което всъщност ви помага да вземетерешението Наемай/Не Наемай. Ето няколко техники, които съм използвал и са били успешни.

Преди интервюто, аз прехвърлям резюмето на кандидата и надрасквам план за интервю на късче хартия. Това е просто списък от въпроси, които искам да задам. Ето един типичен план за интервюиране на програмист:

  1. Въведение
  2. Въпрос за скорошен проект, над който е работил кандидата
  3. Невъзможен въпрос
  4. C функция
  5. Доволен ли сте?
  6. Въпрос за дизайн
  7. Предизвикателството
  8. Имате ли някакви въпроси?

Преди интервюто, аз много, много внимавам да избягвам всичко, което би могло да ми създаде предварително мнение за кандидата. Ако си мислите, че някой е умен, преди дори да е влязъл в стаята, просто поради факта, че притежава професорска титла от MIT, тогава нищо, което каже за 1 час, не може да преодолее това първоначално предубеждение. Ако си мислите, че кандидатът е пълна боза, нищо, което каже, не може да преодолее това първоначално предубеждение. Интервюто е като много, много деликатна везна - изключително трудно е да прецените някого с едночасово интервю и това може да изглежда като решение на косъм. Но ако знаете малко за кандидата от преди, това е все едно голяма тежест на едната страна на кантара и следователно интервюто ще е безполезно. Веднъж, точно преди едно интервю, работодател влезе в офиса ми. "Ще се влюбиш в това момче", каза тя. Хей, тя не ме ли ядоса. Това, което трябваше да кажа беше, "ами, ако сте толкова сигурна, че ще го харесам, защо просто не го наемете, вместо да ми губите времето с това интервю". Но бях млад и наивен, така че го интервюирах. Когато той казваше не-толкова-умни-неща, аз си мислех "их, трябва да е изключението, което доказва правилото". Гледах на всичко, което каза, през розови очила. Аз приключих, казвайки Наемете, въпреки че не беше никакъв кандидат. И знаете ли какво? Всеки друг, който го интервюираше, каза Не Наемайте. Така че: не слушайте работодателите; не разпитвайте за хората преди да ги интервюирате; и въобще никога не говорете с други интервюиращи за кандидата, преди и двамата да сте взели решения независимо един от друг. Това е научният метод!

Въвеждащата фаза на интервюто има за цел да предразположи кандидата. Аз използвам около 30 секунди, обяснявайки на човека кой съм аз и как ще протече интервюто. Винаги обяснявам, че се интересуваме главно от начина, по който решава даден проблем, а не от отговора. Между другото, провеждайки интервюто трябва да се уверите, че не седите на бюро срещу кандидата. Това създава формална бариера, която няма да го предразположи. По-добре е да премесите бюрото срещу стената, или да заобиколите и да седнете от другата страна на бюрото, заедно с него; това наистина ще помогне да го накарате да се отпусне. Така интервюто е по-добро, защото по-малко се изопачава от нервността на кандидата.

Част 2 е въпрос за някой скорошен проект, по който е работил кандидата. Ако интервюирате студенти, питайте ги за дипломната им работа, ако имат такава, или за курс, който са взели и който е включвал дълъг проект, който наистина им е доставил удоволствие. Например, понякога аз ще попитам "кой курс от миналия семестър най-много ви допадна? Няма нужда да е свързан с компютри". Всъщност съм доста щастлив, ако избере курс, който не е свързан с компютри. Понякога гледате програмата му и изглежда, че кандидатът взема абсолютния минимум курсове по информатика, но всеки изборен курс е свързан по някакъв начин с музиката. Тогава кандидатът ще ви каже, че любимият му курс е бил Обектно Ориентирани Бази Данни. Да бе, да. Бих бил по-щастлив, ако си беше признал, че просто харесва музиката повече от компютрите, вместо да се подмазва.

Когато интервюирате кандидати с опит, може да говорите за предишната им работа.

В този въпрос, аз гледам за едно нещо: страст. Когато намерите проект, по който човекът е работил наскоро, всичко това са добри знаци:

  • Кандидатът много се вълнува; започва да говори по-бързо и се оживява. Това показва, че когато се интересува от нещо, ще бъде обладан от него. Намират се прекалено много хора, които могат да работят по нещо без да са заинтересовани по един или друг начин. Дори, ако кандидатът е страстно негативен, това може да е също толкова добър знак. "Работих по инсталацията на Foo Bar Mark II за предишния си работодател, но той беше такъв глупак!" Това са добрите кандидати, които искаме да наемем. Лошите кандидати просто не се интересуват и няма да се ентусиазират въобще по време на интервюто. Наистина добър знак, че кандидатът е развълнуван за нещо е, че когато говори за него, за момент ще забрави че е на интервю. Понякога влиза и е много нервен, защото е на интервю - това е нормално, така че никога не го вземам под внимание. Но тогава, когато го накарате да говори за Изчислителното Монохроматично Изкуство той ще стане изключително развълнуван и ще изгуби всички признаци на нервност. Добре. Обичам страстните хора, на които наистина им пука. (За да видите пример за Изчислително Монохроматично Изкуство пробвайте да изключите монитора си.)
  • Те са внимателни в обясненията. Отхвърлял съм кандидати, защото когато говорят за предишните си проекти, не могат да ги обяснят в термини, които нормален човек би разбрал. Често инженерите приемат, че всеки знае какво е Теорема на Бейтс или Аксиомата на Пеано. Ако започнат да правят това, спрете ги за минута и кажете - "бихте ли ми направили услуга, само в името на упражнението, бихте ли могли, моля ви, да ми обясните това в термини, които баба ми може да разбере". В този момент много хора ще продължат да използват жаргон и напълно ще се провалят в опита си да бъдат разбрани. ГОНГ!
  • Ако проектът е бил общ, търсете белези, че кандидатът е играл роля на водач. Той може да каже "работихме по X, но шефа каза Y, а клиента каза Z." Аз ще попитам, "И вие какво направихте?" Добрият отговор може да бъде "Събрах се с отстаналите от екипа и написах предложение..." Лош отговор може да бъде, "Ами, нямаше нищо, което бих могъл да направя. Беше невъзможна ситуация". Запомнете, Умни и Свършват Работата. Добър начин да откриете дали някой Свършва Работата е да проверите дали в миналото е имал склонност да си свършва работата. Всъщност, можете дори да го попитате директно като го помолите да ви даде пример от близкото минало, когато е поел лидерска роля и е завършил нещо - например е преодолял някакво бездействие на учреждение.

OK, третата точка от онзи списък е невъзможния въпрос. Това е забавно. Идеята е да зададете въпрос, на който кандидатът няма да може да отговори, просто да видите как ще се справи. "Колко очни лекари има в Сиатъл?" "Колко тона тежи Монументът във Вашингтон?" "Колко бензиностанции има в Лос Анжелис?" "Колко акордьори има в Ню Йорк?"

  • Умният кандидат ще разбере, че не изпитвате знанията му, и ентусиазирано ще се впусне в опити да извади някакъв отговор от задния си джоб. "Ами, я да видим, населението на Ел Ей е около 7 милиона; всеки в Лос Анжелис притежава около 2.5 коли..." Разбира се, няма проблем, ако е напълно грешен. Важното е, че се впуска във въпроса с ентусиазъм. Могат да се опитат да изчислят капацитета на бензиностанциите. "Их, нужни се 4 минути да се напълни резервоара, бензиностанциите имат около 10 помпи и са отворени около 18 часа на ден ..." Може да се опитат да ги изчислят по райони. Понякога ще ви изненадат с изобретателността си или ще ви помолят за телефонния указател на фирмите в Лос Анжелис. Все добри знаци.
  • Не-толкова-умните кандидати ще се объркат и разстроят. Само ще се втренчат във вас, все едно сте кацнали от Марс. Ще трябва да ги подтикнете. "Добре, ако строите нов град с размерите на Лос Анжелис, колко бензиностанции ще разположите?" Можете да им пускате малки подсказки. "За колко време се пълни един резервоар?" И все пак, с не-толкова-умните кандидати, вие ще трябва да ги тикате, докате те седят глупаво и ви чакат да ги спасите. Такива хора не решават проблеми и не искаме да работят за нас.

Колкото до въпросите, свързани с програмиране, аз моля кандидатите да напишат кратка функция на езика C. Ето няколко типични задачи, които бих дал:

  1. Да се обърне стринг на място
  2. Да се обърне свързан списък
  3. Да се преброят вдигнатите битове в даден байт
  4. Двоично търсене
  5. Да се намери най-дългата последователност в стринг
  6. atoi
  7. itoa (чудесно, защото кандидатите ще трябва да използват стек или strrev)

Не бихте искали да им давате задачи, които отнемат повече от 5 реда код; няма да имате време за това.

Нека да разгледаме две-три от тези идеи по-подробно. #1: да се обърне стринг на място. Всеки кандидат, когото съм интервюирал през живота си, първия път греши. Без изключения, всички се опитват да заделят друг буфер и да обърнат стринга в този буфер. Проблемът е, кой заделя буфера? Кой освобождава буфера? Със задаването на този въпрос на дузина кандидати открих един интересен факт. Повечето хора, които си мислят, че знаят C наистина не разбират указателите. Просто не ги схващат. Смайващо е, че тези хора работят като програмисти, но това е факт. С този въпрос, ето няколко начина да прецените кандидата:

  • Бърза ли е тяхната функция? Пребройте колко пъти викат strlen. Виждал съм O(n^2) алгоритми за strrev, когато сложността трябва да е O(n), защото викат strlen отново и отново в цикъл.
  • Използват ли артиметика с указатели? Това е добър знак. Много "C програмисти" просто не знаят как да накарат аритметиката с указатели да проработи. Обикновено не бих отхвърлил кандидат просто защото му липсва определено умение. Обаче съм открил, че разбирането на указателите в C не е умение, а дарба. Сред първокурсниците по информатика винаги има около 200 деца в началото на семестъра, всяко от които е писало сложни приключенски игри на BASIC за техните Atari 800, когато са били 4 годишни. Чувстват се комфортно, когато учат Pascal в гимназията, докато един ден техните професори не им представят указателите, и изведнъж, те не ги схващат. Те просто не разбират нищо повече. 90% от класа се отказват и завършват общо-научни профили, а после казват на приятелите си, че не е имало достатъчно добре изглеждащи колеги от подходящия пол в часовете по информатика и това е причината да се прехвърлят. Поради някаква причина, повечето хора изглежда са родени без тази част от мозъка, която отговаря за указателите. Това е дарба, а не умение - изисква сложна форма на двуяко-индиректно мислене, което някои хора просто не умеят.

За #3, можете да проверите колко добре са научили побитовите оператори в C ... но това е умение, не е дарба, така че можете да им помогнете с този въпрос. Интересно е да ги наблюдавате как пишат функция, която брои всички битове в даден байт, а после да ги помолите да я направят много, много по-бърза. Наистина умните кандидати ще създадат таблица с преизчислени стойности (все пак това са само 256 стойности), която ще трябва да създадат само веднъж. С добрите кандидати, може да проведете наистина интересни разговори за различни компромиси тип памет/скорост. Натиснете ги още: кажете им, че не искате да се изразходва никакво време за изчисляване на таблицата по време на инициализация. Брилянтните кандидати може дори да предложат кешираща схема, където битовете се броят само първия път, когато са използвани, а после се съхраняват в таблицата, така че няма нужда да се броят отново при повторно използване. Наистина, наистина брилянтните кандидати ще се опитат да изобретят начин да изчислят таблицата, използвайки някакви хитрости, базирайки се на битовите последователности.

Когато наблюдавате някого да пише код, ето няколко техники, които могат да бъдат полезни:

  • Винаги демонстрирайте, че ви е ясно колко трудно е да се пише код без редактор и ще им простите, ако листът стане много надраскан. Както така, разбирате, че е трудно да се пишат безгрешни програми без компилатор и имате това впредвид.
  • Някои белези на добрите кандидати: добрите програмисти имат навика да пишат {, после веднага да прескочат до края на страницата и да напишат }, а по-късно да попълнят празното място. Също така често имат някакъв вид конвенция за именоване на променливите, колкото и да е примитивна... Добрите програмисти имат навика да използват кратки имена за индексните променливи в циклите. Ако кръстят индекса на цикъла CurrentPagePositionLoopCounter, това е сигурен белег, че не са писали много код през живота си. Понякога ще видите C програмист да пише нещо от сорта if(0 == strlen(x)), слагайки константа от лявата страна на ==. Това наистина е добър белег. Значи са се парили прекалено много пъти, пишейки = вместо == и са си наложили да научат нов навик, за да избягват този капан.
  • Добрите програмисти планират преди да пишат код, особено когато са замесени указатели. Например, ако ги помолите да обърнат свързан списък, добрите кандидати винаги ще направят малка рисунка отстрани и ще нарисуват всички указатели, както и къде сочат. Това им е необходимо. За човек е невъзможно да напише код за обръщане на свързан списък, без да си нарисува малки кутийки със стрелки между тях. Лошите програмисти ще почнат да пишат код веднага.

Неизбежно, ще видите бъг във функцията им. Така, че стигаме до въпрос 5: Доволен ли сте от този код? Може да искате да попитате, "Добре, къде е грешката?" Типичният "Без Ограничения Въпрос от Ада". Всички програмисти допускат грешки, няма нищо нередно в това, просто трябва да са способни да ги откриват. С функцията за стринговете, те почти винаги ще забравят да сложат нула в края на новия стринг. С почти всяка функция е вероятно да имат грешка тип плюс-минус-едно. Понякога ще забравят точка и запетая. Функцията им няма да работи със стрингове с дължина 0, или ще причини GPF, ако malloc пропадне... Много, много рядко, ще откриете кандидат, който няма никакви бъгове от първия път. В такъв случай, този въпрос е даже още по-забавен. Когато кажете "Има грешка във вашия код", те внимателно ще го прегледат и тогава ще видите дали могат да бъдат дипломатични, но и твърди в уверенията си, че кодът е перфектен ... Обикновено, винаги е добра идея да питате кандидата, дали е доволен от отговора си, преди да продължите. Бъдете Реджис (б.пр. водещ на популярно тв. шоу в САЩ, подобно на "Стани богат", който след всеки отговор от страна на участниците ги пита неколкократно дали са сигурни, с цел да ги изнерви).

Част 6: задачата за дизайна. Помолете кандидатът да проектира нещо. Джейб Блументъл, първоначалният дизайнер на Excel, обичаше да кара кандидатите да проектират къща. Според Джейб, той е имал такива, които отиват до черната дъска и веднага рисуват квадрат. Квадрат! Тези са веднага Не Наемайте. Какво да търсите във въпроси за проектиране?

  • Добрите кандидати ще опитат да получат повече информация за задачата. За кого е къщата? По принцип, аз не наемам някого, който се впуска в проектиране, без да попита за повече информация. Често съм толкова раздразнен, че ги прекъсвам по средата и казвам, "всъщност, забравихте да попитате, но това е къща за семейство от слепи жирафи, високи 48 фута."
  • Не-толкова-умните кандидати мислят, че проектирането е като рисуването: получавате празен лист и можете да правите каквото си пожелаете. Умните кандидати разбират, че проектирането е трудна серия от компромиси. Страхотен въпрос: проектирайте улично кошче за боклук. Трябва да е лесно за изпразване, но невъзможно за крадене; трябва да е лесно да се хвърля в него, но да е трудно да изхвърчи нещо през ветровитите дни; трябва да е устойчиво, но евтино; в някои градове, трябва да е специално проектирано, така че терористи да не могат да скрият вътре бомби.
  • Съзидателните кандидати често ще ви изненадат с интересен, не-очевиден отговор. Един от моите любими дизайни е Проектирайте лавица за подправки за слепи хора. Неизбежно кандидатите ще поставят Брайлово писмо някъде по бурканите, което обикновенно се озовава отгоре на капачката поради разнообразни причини, които ще откриете, след като зададете този въпрос 100 пъти. Имах един кандидат, който реши, че ще е по-добре да постави подправките в чекмедже, защото е по-удобно да четеш Брайлово писмо с върховете на пръстите в хоризонтално положение, отколкото във вертикално. (Пробвайте!) Това беше толкова изобретателно, че ме изненада -- в дузина интервюта, никога не съм чувал такъв отговор. И наистина това беше голям "скок" отвъд границите на проблема. Само заради този отговор, без никакви негативни впечетления, наех кандидата, който се превърна в един от най-добрите програмни мениджъри в екипа на Excel.
  • Търсете заключение. То е част от хората, които Свършват Работата. Понякога кандидатите ще се носят напред-назад, неспособни да вземат решение, или пък ще се опитват да избегнат трудните въпроси. Понякога ще оставят сложните решения без отговор и ще се опитат да продължат. Не е добре. Добрите кандидати имат навика да опитват да движат нещата напред по естествен начин, дори когато се мъчите да ги спирате. Ако разговорът някога започне да се върти в кръг и кандидатът каже нещо от сорта "ами, можем да си говорим за това цял ден, но имаме работа са вършене, така че нека продължим с решение X" това наистина е добър знак.

Което ни довежда до #7, Предизвикателството. Това е забавно. През цялото интервю вие внимавате кандидатът да каже нещо, което е абсолютно, позитивно, неуспоримо вярно. Тогава казвате, "я чакай малко, чакай малко" и прекарвате 2 минути в ролята на адвокат на дявола. Спорете с кандидата, само когато сте сигурни, че той е прав.

  • Слабите кандидати ще се предадат. Не наемайте.
  • Силните кандидати ще намерят начин да ви убедят. Те ще разполагат с цял списък от техники на Дейл Карнидж (б.пр. автора на "Как да печелим приятели и да влияем на хората"), с които да ви спечелят. "Може би не ви разбирам добре", ще кажат. Но ще отстояват позицията си. Наемете.

Несъмнено, в едно интервю, не сте равни партньори. Затова съществува риск кандидатът да се страхува да спори с вас, понеже вие сте в позицията на силата. НО, добрите кандидати имат склонността да стават доста пламенни в спора и може за момент да забравят, че са на интервю и много ще се увлекат, опитвайки се да ви убедят. Това са хората, които искаме да наемем.

Най-накрая, би трябвало да питате кандидата, дали има някакви въпроси. Някои хора обичат да гледат дали кандидата ще зададе интелигентни въпроси, което е стандартна техника в книгите за интервюиране. Лично на мен не ми пука какви въпроси ще зададат; до този момент вече съм взел решението си. Бедата е, че кандидатите трябва да се срещнат с около 5-6 души в един ден и е трудно да зададат на 5-6 хора различни, брилянтни въпроса, така че ако нямат въпроси - чудесно.

Аз винаги, винаги оставям около 5 минути на края на интервюто, за да "продам" Fog Creek. Това е много важно, дори ако възнамерявате да наемете кандидата. Ако сте бил с достатъчно късмет, за да намерите наистина добър кандидат, бихте искали да направите всичко, което ви е по силите в този момент, за да се уверите, че той иска да дойде във Fog Creek. Дори ако е лош кандидат, искате да го развълнувате за Fog Creek Software, така че да си тръгне с положително впечатление за компанията. Мислете си го по този начин: тези хора не само са потенциални служители; те са също така и клиенти. Те са също търговските агенти за кампанията ни за наемане: ако те мислят, че Fog Creek е страхотно място за работа, ще окуражат приятелите си да кандидатстват.

О, току-що си спомних, че обещах да ви дам още няколко примера за наистина лоши въпроси, които трябва да се избягват.

Преди всичко, избягвайте незаконните въпроси. Всичко, което има връзка с раса, религия, пол, националност, възраст, военна служба, статус на ветеран, сексуална ориентация или физически недъзи е просто незаконно. Ако в резюмето им се казва, че са били в армията през 1999, не ги питайте, дори с цел само приятен разговор, дали са участвали във Войната в Залива. Това е противозаконно. Ако в резюмето им се казва, че са посещавали Технион в Хайфа, не ги питайте, дори разговорно, дали са евреи. Това е противозаконно. Доста добра дискусия за това, кое е законно, можете да откриете тук. (Но останалите въпроси за интервю на този сайт са доста глупави).

След това, избягвайте каквито и да е било въпроси, които може да направят да изглежда така, като че ли се интересуваме от, или правим дискриминация, базирана на неща, от които всъщност не ни пука и не са база за дискриминация. Най-добрият пример, който мога да измисля, е да питаш някого дали има деца или дали е женен. Това може да създаде невярно впечатление, че мислим, че хората с деца няма да посвещават достатъчно време на работата си или че възнамеряват да се измъкнат и да поискат отпуск по майчинство.

Накрая, избягвайте задачки-загадки, като тази, където трябва да подредите 6 еднакви по дължина кибритени клечки, за да направите точно 4 идентични равностранни триъгълника. Ако това е "аха!" въпрос, не получавате каквато и да е информация за "умен/свършва работата", от това дали са направили умствения скок или не.

Интервюирането е повече изкуство, отколкото наука, но ако запомните принципа Умни/Свършват Работата, ще бъдете в добра форма. Когато имате възможност, питайте колегите си какви са техните любими въпроси и какви видове отговори търсят. В стола на Сграда16 в Редмънд това е постоянна любима тема за разговори през обедната почивка.



Първоначалната версия на статията е на английски с име The Guerrilla Guide to Interviewing  

Джоел Сполски е основател на Fog Creek Software, малка софтуерна компания в Ню Йорк. Той е завършил университета в Йейл и е работил като програмист и мениджър в Microsoft, Viacom и Juno.


Съдържанието на тези страници представя възгледите на един човек.
Цялото съдържание е защитено от авторски права на Джоел Сполски ©1999-2005. Всички права са запазени.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky