Comments 151
Статья хороша тем, что правильно убирает фокус от не нужных вещей, типа "НЕ спрашивать про частности, про конкретные инструменты, про люки".
И содержит много полезных мелочей во вспомогательных темах (типа раздела "мотивация").
Тем не менее, хотя на собеседовании важно ответить на 4 важных вопроса (типа "может ли кандидат работать на этой должности", "хочет ли работать на этой должности" и т.п.) ключевой раздел — компетенции — освещён недостаточно.
То есть неплохо бы раскрыть более подробно как именно проверить знание алгоритмов, архитектуры… И не "от противного", а без этих "не", которыми полна эта статья.
Так что было бы неплохо увидеть продолжение!
Есть только одно требование к подобным собеседованиям: все представители команды должны работать как единый организм, а не тянуть одеяло на себя.
Меня лично собеседовали и 5 технарей (вся дев команда) и солянка из представителей каждого организационного уровня. Что мне, как собеседуемому, позволяло понимать куда я попал и что будет дальше если принять оффер. В роли собеседующего (лида) за последние 2 года мы выработали практику, что в собеседовании участвуют минимум 2 технаря и всегда заранее обсуждаем некую стратегию чтобы не устраивать хаос. Не всегда, но частенько так же участвует hr дабы спрашивать другие правильные вопросы. После чего принимаем коллективное решение.
А уж привлекать на техническое собеседование HR — это с какой целью? Разработчики, а тем более высококвалифицированные, мягко говоря, бывают весьма нестандартными людьми. У них могут быть свои нюансы в общении и мышлении, что может показаться HR-специалисту подозрительным, он будет против них и отсеет вполне годных кандидатов.
Зачем накладывать на себя бремя разруливать конфликты нового члена команды из-за несовместимости со старыми, если это можно проверить на берегу?
А уж привлекать на техническое собеседование HR — это с какой целью? Разработчики, а тем более высококвалифицированные, мягко говоря, бывают весьма нестандартными людьми. У них могут быть свои нюансы в общении и мышлении, что может показаться HR-специалисту подозрительным, он будет против них и отсеет вполне годных кандидатов.
Собственно это же и есть прямая обязанность HR: управлять людьми и одна из сторон этого управления — оценивать кто впишется, а кто — нет. Если вы считаете что ваш HR не способен правильно оценить разработчика, то либо вы неправы, либо у вас некомпетентный в своей области HR.
Я стараюсь больше уделять внимание тому, КАК кандидат мыслит, а не ЧТО он знает.
Конкретные знания конечно же важны, но в каком-то пределе, а вот умение мыслить — бесценно.
А тестовые не даем по нескольким причинам одна из которых — хорошие спецы в них не нуждаются и более того с высокой вероятностью сразу Вас пошлют при первом же намеке на тестовое (я и сам не люблю тестовые)
А Мне вот дали тестовое и я не послал. Может я не senior? И тестовое было интересным и я понимал почему оно именно такое.
у вас просто много времени или желания
Если обычная средняя компания, то давая тестовое, ты отсекаешь часть годных кандидатов.
Не факт. Есть и вторая сторона. На работу искал себе в команду мидла-сеньора — все как на подбор джуны оказываются. Ни знаний, ни умений, ни опыта.
Тестовое даём реально на 1-2 часа делать дома без ограничения по времени — оно отсекает около 90% джунов, желающих получать сеньорскую зп.
При одинаковых условиях, для экономии своего времени, я сначала выбирал вакансии без тестовых задач. А то 10 конторам сделать тестовые на 1-2 часа уйдет часов 50, пока будешь стараться сделать как можно лучше и перепроверять.
Как я понял, вы судите исключительно по тестовому заданию — и тут либо вы его даете просто всем (естественно, что 90% людей оказываются неподходящими) либо ваше мерило уровня не совпадает с общепринятым.
Когда мы практиковали тестовое задание — до половины кандидатов его проходило… чтобы потом неприятно удивить на собеседовании. Поэтому сейчас я предпочитаю сессию парного программирования тестовому. Очень сложно правильно судить о специалисте только по его «искуственному» коду.
(очень давно) Как-то сделал тестовое(большое, и гарантированно ему нет применения на практике) оно вроде как о очень понравилось (и отняло у меня прилично времени, т.к. я от этой темы уже отошёл к тому моменту), в итоге мы не сошлись чем-то(на мой взгляд оценкой важности тех или иных вещей хотя кто знает) с непосредственным "будущим начальником", вот и зачем я его заранее делал...
Мне както предложили поработать недельку а потом они мне скажут подхожу я или нет. Причем это стандартная практика у них.
Компания довольно интересная, гео расчеты, свой супер компьютер (в 5ке самых мощных в южном полушарии), но как то нереалистично для не студентов.
Вот они отсекают очень немало хороших кандидатов.
Имхо, одно дело тестовое для реально крутой компании а-ля Гугла, Яндекса, Амазона, Мейл.ру и совсем другое для Васи Пушкина.
У меня есть три вопроса, и не только к автору, буду рад если увижу много ответов: сколько разработчиков в вашей практике покидали команду из-за некомпетентности (недостаточных знаний, медленной работы, большого количества ошибок)? Сколько из-за денег? Сколько по другим причинам?
Спасибо, я так понял что из-за недостаточной квалификации практически ни с кем не приходится расставаться.
А как вы определяете, держать спеца или нет?
Держат тех, кого заменить тяжело. Например Вася знает хорошо проект, успешно развивает значительную его часть и у него нет серьезных конфликтов.
Т.к. думаю, что очень сложно, уловить «уплывающего» тёпленьким, прежде чем он объявит об уходе…
Или у Вас это проходит стабильно, раз, два, н раз в году собеседование и премия или повышение?
Квалификация проверяется на собеседовании
А как вы отбираете людей на собеседование?
Какой процент пришедших на интервью его проходит?
Есть не техническое интервью после технического? Какой процент проходит его?
Устроился 3 года назад в контору на ЗП мидла в нижней планке по городу, т.к. только переехал в крупный город и деньги физически заканчивались, а других офферов не было.
Сейчас я тут тимлид, фулстек, девопс, 3 человека в подчинении (сам набирал)… Сам с нуля поднимал и настраивал прод, жиру, гитлаб. Скрипты, вебхуки и прочее. Задачи раскидываю по команде, скрипты автоматизации писал…
… спросил за повышение хотя бы до уровня сеньора — сказали "у нас нет таких зарплат" и подняли на 10%. Обидно.
Так как уволить они меня не могут (понимают что контора раком станет моментально), постепенно ищу другое подходящее место с комфортными условиями и, желательно, сложными задачами, т.к. от админок для лендинга уже блевать хочется.
Когда тебя взяли на эту роль другие люди.
— решения нескольких нестандартных сложнейших задач (архитектурно-производительных)
— когда остался одним опытным разработчиком на проекте и все лежало на мне продолжительное время, соответственно научился ответственности
Вроде 5+ лет опыта есть — значит, сеньор.
С другой стороны, чем я занимался-то? Круды писал первое время, во фронт лазил, разве ж это опыт… Наверное миддл…
Хотя — последние несколько лет тяну проект, поднимал его вообще в одиночку, и вроде неплохо спроектировал — значит, всё же сеньор?
С другой стороны, проект-то так себе, внутри костыли, особо интересных задач нет, вокруг много таких же — кто угодно бы справился. Миддл?
Но опять же — уже на 7к рпс вышли, миллионы крутятся, куча технологий использована, наверное сеньор.
Но… Я же алгоритмов не знаю почти, паттерны программирования так и не изучил, какой я сеньор, так, миддл.
Но, мне же платят зарплату вполне себе сеньорскую по рынку, и повышают регулярно, со мной советуются другие разработчики, значит — сеньор?
Да блин, я за технологиями не слежу, более менее знаю только php, всё остальное по верхам нахватал, регулярно гуглю варианты — миддл?
И вот на таких качелях постоянно качаюсь. Кто я — хз, то ли я сеньор с синдромом самозванца, то ли миддл которому повезло получить хорошее место с высокой зарплатой.
Наверное, всё зависит от компании и того, какую роль Вы выполняете в команде. У одних ты можешь быть сеньором, а у других — средним мидлом.
Опять же, есть люди кто и 5, и 10, и 15 лет работает в какой-нибудь веб-студии или что-то сам пытается не совершенствуясь и оставаясь максимум на переходном состоянии из джуна в мидлы.
Так что время я бы лично вообще не учитывал в определении сеньорства да и любого другого статуса.
Эта градация относительная, кто вы, зависит от вашего окружения.
Когда осознал что мой практический опыт значительно выше многих мидлов, с которыми работал. Также коллеги постоянно спрашивают как лучше организовать ту или иную архитектуру приложения и какие подводные камни я вижу.
У меня случай был, спрашивали вопросы только по шейдерам.
Только после собеседования я понял, что им шейдерщик был нужен. Я бы и сам на эту позицию не пошел, т.к. игровую логику хотел писать, а не шейдеры.
То что HR глянул резюме и увидел слово «шейдер», я не сомневаюсь. То, что его не читал собеседующий, я тоже не сомневаюсь.
Только это цель одной стороны, а не общая
Хотелось бы ознакомиться и так сказать выслушать ваши учения и тезисы, которые вы бы подкрепили реальными результатами, а не голословными утверждениями.
Ни разу еще мне не удавалось с помощью собеседований и тестовых заданий определить станет ли кандидат хорошим коллегой впоследствии…
Понял лишь что если сразу что-то явно не нравится, то надо извиняться и вежливо расставаться.
У меня есть один хороший пример: канидат на собеседовании показал себя понимающим и опытным разработчиком, но по факту оказался неспособен работать в условиях малейшей неопределенности (а это в нашей сфере, к сожалению, норма). В итоге любая задача без исчерпывающей спецификации, с которой Senior должен как раз справляться без проблем, растягивается в три-четыре раза — и 10% лишнего времени уходит на собственно уточнения требований, а 90% — на фрустрацию и прокрастинацию от безысходности. В итоге разработчик чувствует себя, извините, говном (а это плохо не только для него); менеджмент периодически полыхает; перестроить процесс, работающий для остальных — невозможно. Спасает только парное программирование, но применять его постоянно тоже не выход.
О! Практикуете парное программирование!? Через TDD? Это замечательная техника! Я как раз считаю что применять это надо постоянно.
Если говорить про кандидатов, то 95% процентов из них показывают себя на собеседованиях вполне перспективно, а затем проваливаются в повседневной производственной коммуникации. Люди не устройства с совместимыми интерфейсами.
Более-менее адекватная оценка для кандидата появляется после пары месяцев совместной работы в обычной обстановке. И ежедневное парное программирование наиболее этому способствует.
95% процентов из них показывают себя на собеседованиях вполне перспективно, а затем проваливаются
Сергей, Вы точно что-то делаете не так на собеседованиях. Возможно, Вам стоит кардинально пересмотреть вопросы, которые Вы задаете. Предположу также, что Вы упускаете ключевые моменты из ответов кандидата.
О! Практикуете парное программирование!? Через TDD? Это замечательная техника! Я как раз считаю что применять это надо постоянно.
Замечательная, согласен :) Но постоянно парное применять не получается, есть категория задач, где надо сосредоточиться и войти в поток, сделать это вдвоем — это очень высокий уровень близости :)
Вы не Гугл и никогда им не будете.
Я не был бы так категоричен. Гугл может позволить себе купить многие компании и покупает их.
Как понять, сможет ли кандидат эффективно у вас работать? — Очень просто, если он предыдущем месте проработал больше года, сможет и у вас.
Ключевое слово — эффективно.
Объективной информации о его работе на предыдущем месте у вас нет и не будет.
Кандидата могли терпеть по каким-то своим причинам больше года.
Теперь терпеть придется вам.
Можно. Но я не уверен что информация будет достоверна.
В случае, если у человека был конфликт (и неважно по какой причине. Может, сотрудник был настолько ценный, что отпускать не хотели, и поэтому поругались) — вы услышите только негатив.
Если конфликтов не было — услышите что-то нейтральное или хорошее. Вменяемый руководитель не станет сор из избы выносить.
Если конфликтов не было — услышите что-то нейтральное или хорошее.
Смотря какой задавать вопрос.
Самый главный вопрос, который надо всегда задать в процессе общения с предыдущим работодателем кандидата:
«Вы бы взяли его себе обратно на работу, при условии, что у вас бы нашлась для него работа?»
Если да — значит эффект в его работе был. Если нет — надо узнавать причину — возможно для вас это не проблема.
Вопрос этот нужно задавать после стандартных вопросов типа, как он работал, все ли было хорошо и т.п. Но ответы на них будут скорее всего социально приемлемыми. Поэтому их и надо сначала задавать, чтобы у предыдущего руководителя создалось ощущение, что он нормальный человек и зря никого не обижает.
А вот на вопрос о приеме обратно, как правило, отвечают более-менее честно. Тем более он явно не характеризует человека, он характеризует только отношение к нему работодателя.
Золотые слова, Юрий Бенедиктович!
Поэтому не стоит давать советы бизнесу. Хотя пытаться влиять на принятие решений, выгодных грамотным специалистам, безусловно стоит. И да, вот такими статьями тоже. То есть неявно идёт банальная война за деньги и минимум напряжения между бизнесом и специалистами. Специалисты, вот как в данной статье, описывают своё видение, свои предпочтения, ну а бизнес почитывает и делает выводы. Или не делает, что случается чаще. Хотя дефицит кадров бизнес очень волнует, но ведь всегда есть очень простой способ — купить проджект манагера (начальника отдела или ещё как-то похоже) и свесить все остальные заботы на него. Особенно в больших конторах. И этот манагер уже будет дрючить испытуемых исходя из личного опыта, который, возможно, включает прочтение подобных статей. Но часто не включает. Просто потому, что реальность требует много дешёвых кодеров, ну а манагер вынужден это чутко улавливать. Вот и методы отбора у него вырабатываются соответствующие. И это уже не выбить из такой головы.
Поэтому я бы рекомендовал специалистам «познать цзен». То есть, имея опыт, вы легко отличите манагера от хорошего специалиста, либо мальчика-джуна, посланного вас собеседовать по техническим вопросам менее грамотными товарищами (включая сеньоров). Просто вспомните, как вы сами участвовали в подобных действах. Там всё тривиально — конторе нужен продукт, продукту нужны кодеры, манагер пинает HR, те присылают толпу, далее нужно отсеивать, но понятно, заниматься этим лень, поэтому и посылают начинающего, но умело отвечавшего на собеседовании на технические вопросы. Ну и начинающий затем выдаёт своё ценное мнение наверх, этому мнению наверху не верят, ибо знают, что начинающий, пишут соседям, мол побеседуйте тоже и т.д. В общем — типичная конторская деятельность по перепихиванию работы с себя на окружающих. И где в такой суете место грамотным вопросам? Правильно — нет его.
Бывают конторы, где специалистам верят, поскольку от них всё зависит, но и там «идеальный отбор» отсутствует. Если всем рулит тим-лид, то вышестоящий начальник свешивает всю процедуру на него, ну а он уже подбирает народ под себя. Не по знаниям, не по «полезности для команды», а именно под себя (можно считать, что по сути он думает «команда — это я»). Да, не все люди идеальны. Хороших спецов я на собеседованиях встречал немного. Бывали интересные люди, но всегда были некие манагеры, либо те же мальчики-джуны, либо ещё какие-то специфические условия.
Какой из этого вывод? Да просто расслабьтесь. Не нервничайте по поводу глупых вопросов и всего того, из-за чего вы привыкли нервничать. Ну да, мальчик-джун очень хочет проявить себя и задаёт вам олимпиадные задачки, про которые он где-то читал. Ну так что в этом плохого? Он и обязан это делать, просто в полном соответствии со своим неокрепшим разумом и недостаточным опытом. На что тут жаловаться? На то, что вы не можете вспомнить, какой метод нужно дёрнуть для решения поставленной джуном задачи? Ну так и скажите — я хочу поглядеть документацию по такому-то классу, и через 5 минут отвечу. Если вы боитесь, что джун потом напишет негативный отзыв — не стоит нервничать! Вышестоящий начальник хорошо понимает, кого и куда он послал, поэтому решать всё равно будет субъективно, лишь частично опираясь на отзыв джуна. То есть просто действуйте спокойно, как вы привыкли, и пусть джун под вас подстраивается и потом покрывается, когда вы ему возражаете. Ну ведь просто же!
Так что — расслабьтесь и не нервничайте. Но к собеседованиям, безусловно, готовьтесь. То есть если бы ко мне пришёл якобы сеньор, но поленившийся освежить в голове хотя бы основное по списку указанных в вакансии технологий — ну очевидно же, что он привык к лёгкой жизни на старом месте, не учил новые технологии, не готов банально почитать о том, чем придётся заниматься на новой работе. Именно поэтому возникает вопрос о его проф.пригодности. Не из-за каких-то субъективных факторов, а именно из-за неготовности чуть-чуть напрячься. Потому что новое место работы — это всегда некоторое напряжение, связанное с необходимостью учиться тому, чего на прошлой работе не было.
Но даже моё возражение в куче контор никак бы не повлияло на субъективный выбор кем-то другим, так что опять же — расслабьтесь, не нервничайте, не попали в одну контору — попадёте в другую. А все эти собеседования — субъективная суета. Напрягают лишь если буквально жрать нечего, потому что денег нет. А во всех остальных случаях — не парьтесь. Но только при условии, что вы реально способны учиться и реально обладаете ценными опытом и знаниями.
В связи с отсутствием необходимого количества кандидатур, пункт «Насколько желаемая зп соответствует вышеуказанным пунктам» становится очень критичным.
Конечно же понятно, что бюджет на позицию ограничен, но порой будет больше толка от мидла с зарплатой сениора, чем будешь ждать подходящего сениора на белом коне — это как пример.
Как Вы/вы считаете?
Что говорит практика?
«Рыночная стоимость» определяется весьма просто — можете поинтересоваться у хедхантинговых агентств, за сколько набирали до Вас. Можете посмотреть в HH, сколько примерно предлагают. Также, первые же кандидаты Вам сами подскажут примерный рынок.
Если Вы предлагаете зп по рынку — вероятность взять толкового сеньора весьма невелика, можно ждать месяцами. Если дать +10% к рынку — шансы увеличиваются, но скорей всего Ваш оффер будет использован сеньором на текущем месте работы для повышения зп.
Поэтому надо предлагать что-то большее, возможно, не только материальные блага.
Сейчас весьма распространен подход набора на удаленку, так как это сильно расширяет аудиторию и упрощает найм. Также нередко сотрудничают с бодишопами просто арендуя у них спецов.
правда там и ещё было умных вопросов, но вот этот запомнился…
а года 4 назад поинтересовались как перевозить какое-то зверьё в темноте через мост в лодке с фонариком и батарейки кончаются и река горит и вообще апокалипсис.
зверьё в темноте через мост в лодке с фонариком и батарейки кончаются и река горит и вообще апокалипсис
Я даже боюсь представить, под какими препаратами это придумывалось и зачем им тут разработчик. Тут психиатр нужен.
petruchek.info/problems/night-bridge-flashlight.html
там потом выяснилось что отпуск надо планировать за год, и всё такое, приходить к 9 утра, в общем не сложилось с ними, хотя 150тыр 5 лет назад было неплохо конечно…
возвращаясь к кубику Рубика. у нас с сестрой в детстве был такой способ его сборки: после 1-2 ударов им об стену, у него выпадывал угол, после чего его можно было разобрать и вставить правильно все цвета. данная операция занимала несколько минут. то же самое с пирамидкой, но там выбить компонент было сложнее.
Наиболее вменяемое что попадалось здесь по теме. Но про полдня кодинга в офисе, на мой взгляд тоже мимо. В специфику ваших задать въехать не успеет, а что то другое, тоже тестовое, только в стрессовом состоянии.
На мой взгляд решение — только под ответственность тимлида (они должны быть на одной волне) и чётко оговоренный испытательный срок.
А вот это как раз вкорне неверно и очень даже вредно спрашивать то, в чем Вы сами хорошо разбираетесь и на данный момент в контексте.
Ну вот разобрался я на последней неделе в библиотеке какой-то, держу в голове часть документации и не лезу раз за разом в гугл. С какой стати собеседуемый должен держать в голове то же самое?
Проблема в том, что интересных задач обычно мало, а рутины много. И сложную рутину тоже надо кому-то делать, спихнуть всё на низовой состав нереально. Поэтому senior со временем привыкает к тому, что интересные задачи приходят и уходят, а деньги — штука хорошая и их платят за разную работу, в том числе и не очень то интересную. Другое дело, что если процент неинтересной работы на конкретном месте начинает зашкаливать, senior это терпеть не будет даже ради денег. )
Зачем спрашивать про алгоритмы? Каждое мое собеседование меня спрашивали алгоритмы. Но за 10 лет работы разработчиком я ни разу не применил эти знания.
А я рад был бы увидеть примеры алгоритмических, но не олимпиадных задач, которые могут показать, что разработчик справится с алгоритмами для средних задач в жизни. Есть примеры?
Слияние связных списков: leetcode.com/problems/merge-two-sorted-lists (под вопросом степень олимпиадности)
Можно упростить предыдущую задачу сделав слияние двух сортированных массивов с использованием дополнительной памяти. Обычно таки у нас нет возможности сливать массивы in-place.
Идентичность бинарного дерева: leetcode.com/problems/same-tree
Написать свой Cross/Left/Right Join для двух списков неких объектов по заранее заданному полю.
P.S.: Let's holy war begin!
А примеры то какие? Для чего это постоянно в бизнес задачах?
Слияние связных списков или массивов — вот для него сложнее всего подобрать пример. Надо подумать еще.
Идентичность бинарного дерева — по сути кастомный equals для объектов со сложной структурой.
Join по ID — стандартная задача по построению некой модельки, по которой будет рендерится отображение, на основании данных из двух или более источников. В наш век микросервисной архитектуры вполне себе частая история должна быть.
Тут еще стоит уточнить, что подразумевать под бизнес задачами.
Если это только вызвал API и ответ без преобразования отправил дальше — то никак не соотносится, разумеется.
Так как налить ровно 4 литра при вёдрах 3 и 5 ?
1) Наливаем в в3 и выливаем в в5
2) Наливаем еще в в3 и выливаем в в5 пока не заполнится. В в3 остается 1л.
3) Опустошаем в5 и переливаем туда 1л из в3
4) Наливаем в в3 3л и выливаем это в в5 с 1 л, получаем 4л.
p.s. сори если это был сарказм и я не в тему, просто пролистал комменты до конца и ваш был последний
Пусть, в3 — ведро 3л, в5 — ведро 5л
1) Наливаем в в3 и выливаем в в5
2) Наливаем еще в в3 и выливаем в в5 пока не заполнится. В в3 остается 1л.
Задача получения 1л решена.
Оформляем результат решения задачи в виде функции.
Выливаем отладочный результат 1л из в3.
Для в5, вызываем функцию получения 1л, 4 раза в цикле последовательно или в 4 параллельных потоках.
Задача решается за шесть)
2) переливаем из в5 в в3 сколько влезет(в в5 остаётся 2л)
3) выливаем в3
4) переливаем из в5 в в3 2л
5) наливаем в в5
6) переливаем из в5 в в3 сколько влезет (1л), в в5 осталось 4л.
Можно ли сказать, что последний будет работать эффективней на 25%? Нет.
Можно ли сказать, что последний умней на 25%? Тоже нет.
Таким образом, польза от подобных единичных задач неочевидна. Для каких-то корректных выводов таких задач нужно дать минимум сотню.
Я провел не одну сотню собеседований как с одной стороны, так и с другой.А когда вы работать-то успеваете? «Собеседование» (job interview) со стороны нанимающегося на работу длится от 4 до 8 часов, «не одна сотня» (допустим, две сотни) займет у вас 6 * 200 = 1200 часов, т.е. практически два месяца рабочего времени.
например — полдня кодинга непосредственно в компании, оплаченные по средней ставкеЭто ваша юношеская мечта, что-ли? По какой статье расходов будете проводить оплату в бухгалтерии? ;)
2) Вопрос оплаты в нормальных конторах проблемой не является.
2) Вы как-нибудь все-таки у бухгалтера сначала поинтересуйтесь, прежде, чем чушь писать. И дело вовсе не в наличии или отсутствии у «конторы» денег.
Если автору будет интересно описать метаморфозы сеньора девелопера, происходящие с ним по мере старения, то с удовольствием прочитаю.
Чем старее разработчик — тем более консервативен он становится. Вплоть до полного отрицания новых технологий, особенно, если старый стек до сих пор востребован(например, Java 7-8). Плюсом такой консервативности можно считать то, что в старом стеке он плавает как рыба в воде.
Еще минус возраста то — что тимлиды моложе их встречаются чаще, иногда существенно моложе. Для тимлида 30 лет морально тяжело работать с разработчиком 45 лет, а разработчик с высоты своего опыта и возраста старается давить на него, что вызывает дискомфорт в отношениях. Поэтому старички-разработчики обычно мигрируют в Enterprise и там вполне комфортно себя чувствуют до пенсии.
blog.usejournal.com/rethinking-how-we-interview-in-microsofts-developer-division-8f404cfd075a
tl;dr: вместо шаблонных вопросов решают вместе с кандидатом реальную задачу во всей её полноте, начиная с работы с требованиями и т.п.
Лично мне такой подход крайне импонирует и, думаю, даже провал такого собеседования будет ощущаться лучше т.к. человек сам увидит, что не справился, не разобрался, etc и как минимум получит полезный опыт. Куда полезнее заучивания всех «принципов ООП».
А какие у вас появляются дополнительные требования, если вы ищите Lead developer, а не Senior developer?
Относительно недавно проходил собес как раз на сеньора.
Из краткого: закидали терминологией (solid, dry, kiss, di, инкапсуляция и т.п.) из "умных" слов. Сразу сказал что у меня теория хромает, зато на практике реально много чего могу. Как ещё не спросили "что такое ООП"…
В сумме около трёх часов разговаривали (так получилось).
Дали тестовое. Сделал чтоб не стыдно было. Сказали "офигеть как шикарно", но на работу не позвали.
При этом, с девчонкой HR неплохо поболтали.
Ну, нет так нет.
На другом собесе задачу дали на листочке написать:
Не используя условные операторы при передаче в функцию числа "1" вернуть "2", а при передаче "2" — вернуть "1".
Я с такими задачами не сталкивался и честно пытался решить около пяти минут — не смог. Зато придя домой всего за 15 секунд написал рабочее решение не открывая Гугла:
function get($num)
{
return ($num | 2) — 1;
}
Хотел бы добавить вам в копилку пару идей из своей практики…
Как известно, правильно поставленный вопрос — это половина решения проблемы. Поэтому люди, умеющие задавать правильные вопросы, как правило, и хорошо умеют эти проблемы решать. Если есть желание и возможность — попробуйте «собеседование наоборот»: пусть кандидат экспромтом попробует вас самих взять на работу:) Ну, во всяком случае, это может быть весело. Как минимум, нестандартность приёма иногда позволяет снимать стресс…
И ещё не стоит сбрасывать со счетов «любителей дурацких вопросов»...99% из них и вправду дурацкие, т.к. ответы на них не говорят ровным счётом ничего полезного. Тем не менее, если привлечь на помощь научно обоснованные достижения современной психологии, то кой-какие полезности из их арсенала вполне можно использовать… Например, такие вот простенькие тесты «на когнитивное отражение». Обоснование зачем это и почему может быть полезно популярно рассказано вот тут.
Собеседуем кандидата на должность Senior Software Developer