Нека поговорим за интервюта за бяла дъска и възможните алтернативи

За никого не е новина, че много инженери мразят въпросите на интервютата, базирани на бяла дъска.

Независимо дали е в Twitter, Medium или LinkedIn, лесно е да намерите някой, който да обезвъздуши. Фразата „процесът на наемане е нарушен“ се използва толкова често, че се превръща в клише.

За съжаление, голяма част от това разочарование пада върху глухите уши.

Въпреки припева на гнева около него, „бялата дъска“ все още е основна част от интервютата за софтуерно инженерство. Част от това се дължи на факта, че разработчиците бързо изразяват недоволството си, но бавно предлагат по-добри алтернативи.

Има ли по-добри алтернативи?

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

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

Това затруднение ме доведе до два въпроса:

  1. Интервютата за бяла дъска най-добрият избор ли са?
  2. Ако не, кои са по-добрите алтернативи?

В този пост ще се опитам да отговоря на тези въпроси. Имайте предвид, че това са моите лични мнения, които са оформени от собствения ми интервюта.

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

Най-лошите ли са интервютата за бяла дъска?

Първата стъпка в този процес е да се проучи внимателно бялата дъска.

Професионалисти:

  1. Бързо и ниско усилие
  2. Не зависи от език или домейн
  3. Знаете (като цяло) какво да очаквате
  4. Подкрепа от общността (Glassdoor, LeetCode, Pramp и т.н.)

Минуси:

  1. Късметът е голям фактор (лотария на алгоритъма)
  2. Не е задължително да се тества инженерната способност
  3. Предпочита млади инженери и скорошни студенти

За компаниите, които изискват инженерите да разбират добре основите на CS, алгоритмите на ниско ниво и не зависят от библиотеките, интервюто за бяла дъска е идеално.

SpaceX, MacOS / Windows и React на Facebook са създадени от инженери с такива познания. Очаква се да получите интервю за бяла дъска от една от тези компании.

Като кандидат за работа обичам интервюта за бяла дъска. Знам какво да очаквам. Повечето въпроси относно алгоритмите попадат в тези общи теми:

  • Масиви / низове
  • Двоични дървета
  • Свързани списъци
  • DFS / BFS
  • Обратно проследяване
  • Динамично програмиране

Да знам това преди време означава, че мога да уча за това. И има множество инструменти за изучаване, от които да избирате. Подготовката за техническо интервю е цяла собствена индустрия.

Поради тази причина интервютата за бяла дъска не са най-добрият вариант за всяка компания. Толкова много се свежда до късмет, запаметяване и този, който е прекарал най-много време в учене.

Не всеки може да учи дълго време, за да овладее алгоритми.

Имах късмет, че можех и надминах други инженери, които не можеха. По-добър инженер ли съм от всички тях? Може би, но не съм сигурен, че интервюто за бяла дъска е най-доброто средство за разкриването му.

Така че, ако има съмнение, че интервюто за бяла дъска е най-добрият инструмент за работа, какво може да бъде по-добро?

Нека да разгледаме някои от алтернативите.

Предизвикателства за кодиране чрез компютър

Професионалисти:

  1. Вземете да използвате компютър и познатата среда за разработчици
  2. Може да се направи дистанционно чрез споделяне на екрана
  3. Всички останали предимства на интервютата за бяла дъска

Минуси:

  1. По-строги по отношение на синтаксиса и функционалността.
  2. Програмиращата среда и приставки могат да играят голям фактор
  3. Същите недостатъци на интервютата за бяла дъска

Предизвикателствата за кодиране на лаптоп са по-малко строгият братовчед на интервюто за бяла дъска.

Кандидатите имат предимството да използват собствените си компютри. Те могат да се извършват дистанционно или в среда за програмиране по двойки.

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

Недостатъкът на това е, че има много по-голям акцент върху функционалността.

По време на търсенето на работа бях зададен два пъти за проблема за смяна на монети. Единият като предизвикателство за бяла дъска, а другият като редактор.

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

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

Не е така с предизвикателствата на кода.

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

Да се ​​надяваме само да не се изнервяте по време на интервюта. Една малка грешка, която причинява неуспешни тестове и няколко минути отстраняване на грешки, може да бъде разликата между „силно наемане“ или пропуск.

Предизвикателствата на кода все още страдат от същите кратки идвания като бялата дъска, защото много от тях са базирани на алгоритми.

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

Вземете домашни оценки

Професионалисти:

  1. Може да работи върху него в пижамата си
  2. Обикновено се дава повече от седмица за работа по задание
  3. Вземете да използвате вашия собствен редактор и среда за разработчици
  4. Може да бъде ново допълнение към портфолиото
  5. Обикновено по-забавно от бялата дъска

Минуси:

  1. Нивото на трудност може да варира драстично
  2. Много повече усилия и време отнема от предизвикателствата за кодиране
  3. Може да зависи от домейн
  4. Може да доведе до пълзене на характеристиките поради конкуренция
  5. Не представлява ежедневна работа

Много инженери предпочитат да вземат домашни задачи. Сроковете за предаването им обикновено са гъвкави и кандидатите всъщност стигат до кода. Не е шок, че програмистите предпочитат това, отколкото да стоят пред бялата дъска, докато са мълчаливо съдени.

Въпреки това тестовете за вкъщи имат някои основни недостатъци.

Първо, те са лесни за манипулиране.

Много компании са домакини на тестовете си на GitHub. Въведете „Предизвикателство“ или „Тест“ в търсенето с GitHub и ще намерите много. Това ще даде на умния кандидат достатъчно време за превантивно проучване на предизвикателството.

Това всъщност не е оплакване. Просто по-скоро професионален съвет.

Какво е проблем е, че той е достатъчно лесно да намерите отговори на други хора на тези предизвикателства и да ги копирате. Множество инженери пазят отговорите за домашни предизвикателства в своите профили в GitHub.

Можете дори да го тествате сами. Въведете „Предизвикателство“ в търсенето с GitHub и вижте какво ще намерите.

Живея до централата на Etsy в Бруклин и бях любопитен дали мога да намеря отговорите на някои от техните тестове. „Etsy Challenge“ разкри четири. Имаше още повече в „Etsy Test“.

Вярно е, че компаниите могат да променят своите оценки. Въпреки това може да бъде караница да се променя процесът на интервю на всеки няколко месеца поради изтичане на подробности.

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

По време на последния ми лов на работа ми дадоха четири задачи за вкъщи. Три от компаниите заявиха, че трябва да отнемат само 3-5 часа, за да завършат.

Всички ми отнеха няколко дни.

Основната причина за това беше, че предизвикателствата често бяха специфични за дадена област. Изискваха няколко часа проучване на API документи и нови технологии.

Четвъртата компания прие предизвикателство, което лесно може да отнеме седмица и ми даде два дни. Трябваше да изградя работещо приложение за чат, което поддържаше команди наклонени черти.

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

Ако кандидатът има късмета да интервюира с няколко компании наведнъж, той може да се превърне в работа на пълен работен ден, просто работеща върху тези предизвикателства.

Освен това, професионалните разработчици трябва да работят върху стари кодови бази и да се справят със срокове. Едноседмичен проект на зелено място няма да оцени колко добре интервюираният работи в забързана среда.

Като цяло обичам да приемам домашни задачи като начален екран на способностите на кандидата. С това казано, те трябва да са свързани с работата, за която кандидатът кандидатства, и не трябва да отнемат нецензурно време, за да завършат.

Въз основа на проект / договор за наемане

Професионалисти:

  1. Получете шанс да работите с кандидат / екип
  2. Получавайте пари за работа
  3. Пристъпете към работа по реални проекти
  4. Оценяват се колко добре работите с екип и корабен код

Минуси:

  1. Ангажимент от дълго време
  2. Работа без гаранция за заетост
  3. Без ползи за здравето като изпълнител
  4. Може да постави кандидата в лоша преговорна позиция
  5. Зависим от езика

Проектните интервюта са рядкост. Но немалко компании стоят до тях, като Basecamp и Automatic. Мога да разбера защо.

Тези интервюта са може би най-точният начин да се оцени нечие умение и да се оцени като член на екипа. Компанията започва да работи директно с тях и да види как се справят със задачи в екип.

Кандидатът също така получава шанс да оцени компанията и да определи дали това е типът среда, в която би искал да работи.

Печеливша. Или поне така изглежда.

С всичко казано, като кандидат за работа никога не бих участвал в интервюта, основани на проекти, или в роли за наемане на договор. Негативите далеч надхвърлят положителните.

Първите няколко месеца от всяка работа обикновено са най-трудните. Вие се аклиматизирате към нов екип, култура, кодова база. Сега си представете да работите по проект, без да знаете дали ще имате работа до края.

Един мой добър приятел наскоро взе интервю в Automatic и потвърди колко стресиращо може да бъде. Преценява се всичко - от начина, по който взаимодействате с колегите, до зададените от вас въпроси. В тези среди, има е такова нещо като "глупав въпрос."

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

Освен това договорите поставят търсещия работа в ужасна позиция за преговори. Силата в преговорите идва от желанието да си тръгнете.

До края на периода за наемане на договор, потенциалният кандидат няма да има чипове за договаряне. Те няма да имат други оферти и вече са вложили десетки или стотици часове в своите проекти в зависимост от продължителността на договора.

Те ще бъдат стимулирани да заемат позицията, дори ако това не е техният предпочитан избор. Алтернативата е да се присъедините към пазара на труда отново на първо място.

Най-добрата заблуда на потъналите разходи.

Докато интервютата за бяла дъска може да не са идеални, бих направил сто от тях, преди да направя интервю, базирано на проекти.

И така, кое е най-доброто?

Както може би се досещате: Зависи ™.

Компромисите изглежда са между скоростта и усилието спрямо точността. Всеки метод жертва един за друг. Всяка компания зависи сама да прецени тези компромиси. SpaceX най-вероятно ще има различен процес от малкия стартъп в Ню Йорк.

Истина е, че една SaaS компания трябва да иска от кандидатите да изписват алгоритми за динамично програмиране, само ако това им помага да определят уменията на инженера. Не просто защото Google го прави.

Ако проектирах процеса на интервю за моя екип в DigitalOcean, щях да използвам комбинация от оценки за вкъщи и предизвикателства на кода / упражнения за сдвояване. Бих преценил и тяхното разбиране за наличността и разпределените системи чрез сесия с въпроси и отговори и предизвикателство за проектиране на системата.

Добрата новина е, че екипът ми вече прави това. Трудният, но коректен процес на интервю на DigitalOcean беше една от причините да приема предложението им. Доказа ми, че те вече са преминали през този процес на самопроверка и са разбрали как справедливо да оценят своите кандидати.

Моля, уведомете ме какъв е вашият предпочитан метод за интервю в коментарите по-долу!

И накрая, за всички вас инженери, които искате да видите как се променя процесът на интервюта, започнете да предлагате идеи. Виждал съм твърде много инженери да се заяждат за интервюта за бяла дъска, само за да продължат процеса, след като бъдат наети, защото е прекалено много работа, за да го промените.

Не бъдете този човек.

Спри да се оплакваш.

Намерете решения.