Как да наемем по-добри разработчици

[Забележка] Това е статия, написана от гледна точка на наемаща компания или от гледна точка на служител, който би искал да има добри и компетентни колеги.

Ще отбележа аспекти по отношение на разработчиците като цяло, но аз ще говоря повече от опита на fullstack JS разработчик, така че някои неща може да не пасват като ръкавица за вашия случай.

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

  1. Не задавайте глупави въпроси

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

2. Избягвайте да оказвате натиск и / или да задавате време или прекалено сложни задачи на място

Освен ако вашата компания наистина не е c ** p, най-вероятно функция няма да се наложи да бъде пусната след 20 минути и съм почти сигурен, че няма да включва изтегляне или бинарни дървета, нито O (n) оптимизации с помощта на hashmap.

Извличането на отговор от такива или други въпроси също зависи от психическата готовност и настроението на дявола в този конкретен момент и всъщност не ви казва твърде много.

Все още си струва да го направите, ако тестовете са наистина прости и просто се използват за филтриране на наистина лошите или просто за да разгледате мислещия процес и да започнете дискусия за компромиси.

3. Код за писане на хартия (особено специфичен за езика)

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

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

Но .. трябва ли добър разработчик да знае как да прави 4 вида сортиране? Съмнявам се.

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

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

Защото ако той направи всичко това, тогава можете да сте почти сигурен, че може да премине всеки един от онези фантастични графики, които обичате толкова много, за няколко дни и да научите всичко, ако наистина имате нужда от това.

4. Спрете да задавате въпроси за API по отношение на технология / език, който не е свързан с това. Потърсете вместо това концепции

Това, което искам да кажа, е, че питането на някого колко от езика / синтаксиса на заявката за операция в MongoDB няма никакъв залог ... мисля, че хората, които перфектно запомнят синтаксиса на API наизуст, са като цяло по-лоши разработчици, отколкото хората, които го забравят.

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

Къде сега е твоята powa?

Търсейки концепции имам предвид, че трябва например да видите дали той / тя схваща понятия като транзакционност, мащабируемост, видове последователност, лесно интегриране и лекота на използване на наличните API за неговия двигател, различни видове бази данни (документ, sql , графика и т.н.), а също и за какво трябва да се използва, типични случаи на употреба и цялостни слаби точки / силни петна.

Запомнянето на SQL API е друг пример: „как да направите тази ПРИЛОЖЕНИЕ или тази и тази операция“. Не е необходимо да помните, че до края на живота си, ако имате основна представа за релационни бази данни, тогава добрият разработчик трябва да може да ви каже различните мутации на състоянието и начина, по който се извършват операциите в тези типове бази данни, компромиси, които идват с тях.

И всичко това само с незначителна или никаква употреба на API.

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

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

5. Да, но наистина ли познавате тази рамка? Колко опит имате с него?

Понякога има значение, друг път не. На въпрос какъв опит имате с React (говорим за ядрото реагира не цялата игра на тронове колекция от библиотеки парчета) всъщност не иска нищо, ако сте прекарали 2+ години кодиране в JS до този момент.

Самата реакция е на стойност 2-3 дни, за да я използвате практически, това „губено“ време е критично за вашата компания? Е, ако е така, може би това е глупава компания, така че не се притеснявайте да променяте това ... моля продължете и след това си отидете (:

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

Waay по-полезно. Попитайте го какво му харесва в това и какво не прави, това трябва да ви даде бърза и добра представа за дълбочината, която той има в тях, ако наистина сте в него (по някаква причина)

6. Добрият разработчик трябва да знае как да търси нещата

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

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

Лошите разработчици обикновено се опитват да изобретяват колелото, когато това не е така. Опитайте да потърсите тази черта и ако тя липсва, това определено е не-не.

7. Къде се виждате след X години

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

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

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

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

Освен това сега можете да видите колко бързо може да схване „вмъкнете името на рамката ви“.

9. Не вземайте предвид неговите мнения за себе си

А?

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

Колкото повече се учиш, толкова повече разбираш, че не знаеш много, затова синдромът на Импостор е истинско нещо, което се случва в момента, особено в света на JS.

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

10. Давате достатъчно време да докажете себе си

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

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

___________________________________________________________________

Благодаря за четенето :).

Умишлено се опитах да избягвам да пиша специфични за пола местоимения (той / тя), защото това е 2016 г. и искам да избегна обидите на асексуални хора и някои видове морски кончета. Обичам морските кончета.