Comments 105
А что вы думаете о практике задач на написание программ при помощи шариковой ручки и листа бумаги при прохождении технического интервью? Интересно было бы почитать об этом в вашей следующей статье о конкретных методиках.
А что вы думаете о практике задач на написание программ при помощи шариковой ручки и листа бумаги при прохождении технического интервью?
Сам так делал очень много раз! Заставлял людей на собесах писать физзбазз )))
Сейчас я больше за repl.it. Подробнее в следующей статье.
Если мне предложат писать код ручкой на бумажке, то я соглашусь только с условием, что на рабочем месте я также буду писать код ручкой на бумажке после найма. А скорее всего, я пошлю такое предложение далеко.
А скорее всего, я пошлю такое предложение далеко.
У меня за все время только один такой жесткий кандидат попался. Все остальные без проблем решали на бумажке и на доске )))
Но больше я такого практиковать не буду, ведь есть repl.it.
Я может не откажусь, но про себя сочту технического специалиста от компании весьма странным человеком, занимающимся какими-то своими мат. теориями за счет компании. Это одна из родовых болезней IT — ученые (теоретический склад ума) в продакшн. Побочными последствиями идут самописные костыли, экзотические языки и фреймворки, три переезда в год с платформы на платформу, с языка на язык, с базы на базу (найдя гипотетическое преимущество, а проще говоря интересно поиграться). Но в то же время такой подход «гарантирует» успешность, ведь у нас парное программирование и прочие золотые пули, наиболее модные в этом году.
Далее постараюсь понять — он там один такой или другие такие же.
Далее постараюсь понять — он там один такой или другие такие же.
А скорее всего, я пошлю такое предложение далеко.
Вот и прекрасно. Так хорошо отсеиваются неадекватные истерички.
Согласен, что это прекрасно. Я тоже не хочу работать на компанию, где людей ценят не по реальному опыту, а по коду на бумажке. Безусловно, написать обход в глубину какой-нибудь существенно полезнее, чем обсудить подводные камни использования какого-нибудь ORM или архитектуры БД для микросервисов.
Помню у нас в одной компании работал чувак, который писал свой DI, говорил что с нами работать неинтересно ибо уровень слабоват, ушёл в Люксофт и напоследок оставил API, в котором для добавления нового события в календарь нужно было передавать весь массив событий. А если не передать, то все удалялось из базы, включая те события, которые уже состоялись. Очень эффективно было гонять массивы из сотен событий на UI и обратно, пока не переписали. Зато он знал принципы SOLID
Помню у нас в одной компании работал чувак, который писал свой DI, говорил что с нами работать неинтересно ибо уровень слабоват, ушёл в Люксофт и напоследок оставил API, в котором для добавления нового события в календарь нужно было передавать весь массив событий. А если не передать, то все удалялось из базы, включая те события, которые уже состоялись. Очень эффективно было гонять массивы из сотен событий на UI и обратно, пока не переписали. Зато он знал принципы SOLID
Какую-то внутренне-противоречивую фигню вы сказали: «надо на собеседовании узнавать про архитектуру, но знать архитектуру — это плохо»
Я тоже не хочу работать на компанию, где людей ценят не по реальному опыту, а по коду на бумажкеРеальный опыт, написанный в резюме — это обычно просто ложь. Очевидно, вы провели слишком мало собеседований, чтобы понять, что по «реальному опыту» можно нанять только очень клевого вруна.
Безусловно, написать обход в глубину какой-нибудь существенно полезнееФизбаз написать очень полезно. Если у человека такая каша в голове, что он Физбаз написать не может, то пусть он хоть 100 книг про ОРМ напамять заучил. Будет приходить, расставлять пальцы — какой он крутой архитектор, знает как правильно архитектуру БД для микросервисов писать. А потом начнёт писать код, а ты за ним переделывать, потому что багов дикая тьма, а как их исправить — хз. Как-то, к сожалению, купился я на «реальный опыт» и «сладкие речи». Больше такую херню брать не буду.
Помню у нас в одной компании работал чувак, который писал свой DI, говорил что с нами работать неинтересно ибо уровень слабоват, ушёл в Люксофт и напоследок оставил API, в котором для добавления нового события в календарь нужно было передавать весь массив событийДа, очевидно, что он был прав. Его команда была настолько слаба, что какие-то базовые проебы в API заметила только после ухода человека. Очевидно, что он был единственным, кто работал, а остальные ходили, да смузи пили, да архитектуру БД для микросервисов обсуждали.
Вы ведёте себе весьма токсично, при этом мне кажется, что сами плаваете в теме.
Каким боком физзбазз, обходы дерева, бинарные деревья относятся к архитектуре?
И вообще, часто ли вы пишете балансировку деревьев в своей повседневной работе? Знаете ли вы, какой алгоритм сортировки используется в вашем языке/
фреймворке?
Я не говорю, что я сильно верю тому, что написано в резюме. Но поверьте, мне достаточно пяти минут, чтобы определить, насколько плотно человек использовал NHibernate. И если он скажет мне, у меня все было окей и не было проблем, вот тут я пойму, что он не знает о нем ничего, а если расскажет про сложности и проблемы, то будет понятно, что он хотя бы с ним сталкивался.
По поводу горе-разработчика DI, то проблема лишь была в том, что он один писал этот проект и никто его не ревьювил. Но для меня такое апи это все равно что не знать таблицу умножения. Это полное непонимание бизнес процессов, целостности данных и перформанса. Пусть он хоть всего Кнута мне перескажет — я не возьму его на работу. Ибо зазубрить можно все, а научить использовать голову — нет.
Я решал на собеседованиях задачки про фитильки, про монетки, рассказывал про бинарные деревья, отвечал про 15 паттернов проектирования, писал код на бумажке — все это не имеет никакого отношения к реальному найму на реальную работу.
Каким боком физзбазз, обходы дерева, бинарные деревья относятся к архитектуре?
И вообще, часто ли вы пишете балансировку деревьев в своей повседневной работе? Знаете ли вы, какой алгоритм сортировки используется в вашем языке/
фреймворке?
Я не говорю, что я сильно верю тому, что написано в резюме. Но поверьте, мне достаточно пяти минут, чтобы определить, насколько плотно человек использовал NHibernate. И если он скажет мне, у меня все было окей и не было проблем, вот тут я пойму, что он не знает о нем ничего, а если расскажет про сложности и проблемы, то будет понятно, что он хотя бы с ним сталкивался.
По поводу горе-разработчика DI, то проблема лишь была в том, что он один писал этот проект и никто его не ревьювил. Но для меня такое апи это все равно что не знать таблицу умножения. Это полное непонимание бизнес процессов, целостности данных и перформанса. Пусть он хоть всего Кнута мне перескажет — я не возьму его на работу. Ибо зазубрить можно все, а научить использовать голову — нет.
Я решал на собеседованиях задачки про фитильки, про монетки, рассказывал про бинарные деревья, отвечал про 15 паттернов проектирования, писал код на бумажке — все это не имеет никакого отношения к реальному найму на реальную работу.
обходы дерева
Собственно я начал про деревья, так вот, у нас в работе реально было много древовидных (не бинарных и не красно-черных) структур данных и обход (десяток строчек кода) просто показывал может ли кандидат работать с таким и сможет ли моделировать эти самые деревья под разные требования.
Когда я давал задачу то я сразу же говорил кандидату что это не просто тест на знание школьных алгоритмов, а необходимость в работе. Более того, я всегда заворачивал задачу в бизнес контекст, например «сделайте пожалуйста структуру классов которая будет работать как абстракция для категорий продуктов, категории могут быть бесконечной вложенности». И дальше просил, например, «как вы будете отдавать данные о категориях на фронтенд чтобы он мог построить дерево, как в типичном интернет магазине».
Сортировки и балансировки я не спрашивал, это уже к фаангам.
Большинство проверок знания что вы хотите дать на бумаге, легко определить словами. Меня на собесах даже sql спрашивали словами, внезапно, челове слушал как я рассуждаю и им этого хватало. Не нужно бумаги, не нужно тестов, в большинстве случаев хватает внимательности и правильных вопросов.
Довольно странная бизнес-задача хранить категории продуктов в памяти. Я бы решил её использованием графовой субд, одним простым sql запросом и тривиальным маппингом структур. Зачем тут «обход дерева» ума не приложу.
Я бы решил её
Вы бросились решать даже не узнав ограничений и других условий — не буду же я полностью все перечислять.
Довольно странная бизнес-задача хранить категории продуктов в памяти.
Это лишь пример как дать задачу не об абстрактных деревьях, а о конкретной бизнес потребности (где нужны деревья). В реальной работе это были не совсем категории, но объекты имели вложенность, и да, нужно было этим всем оперировать в памяти, и нет, графовую субд использовать было нельзя, и нет, простой sql запрос годится только для доставания скелета, но не для всей обвязки, да и работал бы он очень медленно для наших требований.
Зачем тут «обход дерева» ума не приложу.
Конечно не приложите, я ведь не буду тут весь продукт описывать )))
В итоге кандидаты так или иначе приходили к древовидной структуре. Были конечно весельчаки которые предлагали на каждый уровень вложенности добавлять еще один класс, их мы не нанимали )))
Вы бросились решать даже не узнав ограничений и других условий
Обожаю таких "экзаменаторов", которые сначала не договаривают условия, а потом вменяют в вину, что ты что-то не уточнил.
не буду же я полностью все перечислять.
А стоило бы.
графовую субд использовать было нельзя
Есть хоть одна причина этого не делать?
простой sql запрос годится только для доставания скелета, но не для всей обвязки
Про fetch plan вы не слышали?
работал бы он очень медленно для наших требований
Требования в студию.
я ведь не буду тут весь продукт описывать
То есть вы даёте задания, для понимая которых нужно описывать весь продукт?
Обожаю таких «экзаменаторов», которые сначала не договаривают условия
Ишь какой дерзкий )))
Я вообще-то тут давал не конкретную задачу которую нужно решать а дал пример, как можно из деревьев сделать что-то менее абстрактное и более приземленное чтобы люди не думали что им дают алгоритмические задачи от балды.
Про fetch plan вы не слышали?
конечно не слышал )))
То есть вы даёте задания, для понимая которых нужно описывать весь продукт?
Когда я говорил про невозможность использования графовых баз, я имел ввиду уже требования реального продукта а не ограничения задания. Если бы мне кандидат сказал что для моделирования графов он был взял какой-нибудь neo4j, ну что ж… наверное я бы такому кандидату отказал с занесением в личное дело «любитель ищ пушки по воробьям» )))
Шутка ))) Если бы кандидат сказал про neo4j то я бы спросил у него давно ли он смотрел их багтрекер )))
как можно из деревьев сделать что-то менее абстрактное и более приземленное
А получился ещё более оторванный от реальности каталог товаров, хранящийся в оперативке.
конечно не слышал )))
Тогда почитайте и не говорите глупостей.
невозможность использования графовых баз, я имел ввиду уже требования реального продукта
Это вам бизнес такие требования ставит? Может он от вас ещё и конкретный кодестайл требует?
Если бы кандидат сказал про neo4j
Это единственная графовая субд, что вы знаете?
Может он от вас ещё и конкретный кодестайл требует?
прикинь, в больших компаниях часто есть кодестайл )))
Это вам бизнес такие требования ставит?
Ага, а еще в больших компаниях часто есть фиксированный стек технологий и нельзя просто так начать писать на .NET в конторе где почти все написано на Java )))
UFO just landed and posted this here
Каким боком физзбазз, обходы дерева, бинарные деревья относятся к архитектуре?Никаким. Найдёте, где я утверждал обратное? Или придумываете ошибочные аргументы, а потом сами же с ними спорите?
И если он скажет мне, у меня все было окей и не было проблем, вот тут я пойму, что он не знает о нем ничего, а если расскажет про сложности и проблемы, то будет понятно, что он хотя бы с ним сталкивался.Вы недооцениваете мощь тех, кто умеет врать. Он вполне может пересказывать возмущения своего лида. А сам мог никогда и не задумываться над реальными проблемами.
писал код на бумажке — все это не имеет никакого отношения к реальному найму на реальную работу.
Видите ли, ваша проблема, что вы мыслите очень… сухо. Для вас код на бумажке — это «ну вот пришел человек, написал код на бумажке, я его проверил и нифига полезного с этого кода не получил».
Суть в том, что я не даю написать код на бумажке, а потом проверяю. Представьте, что мы занимаемся с человеком парным программированием на бумажке.
Может, это специфика вашей области такая. Подозреваю, что простые CRUD-задачи и не требуют живого захвата от кодинга. Там может подойти и поверхностный разговор, навык программирования не очень важен, важнее количество крудов, которые ты написал. Я написал очень мало и, увы, больше писать не хочу. Даже несмотря на то, что платят больше.
И, кстати, я не отрицал общение на тему архитектуры. Просто у меня комплексное собеседование. Я общаюсь и о архитектуре, и код на листочке пишу, и спрашиваю о тех хобби, которые человек описал в резюме, спрашиваю, в какие игры он играет.
У нас в геймдеве каждая фича может разительно отличаться друг от друга. Знаете, бывают ситуации когда всё сделал клёво, правильно, но выглядит оно стрёмно. На архитектуру, которую вы придумывали с командой и на которую игра отлично ложилась годами плохо ложится новая фича. Нужен порядок анимаций, который противоречит логике, потому что смотрится он значительно класнее. Ты идешь с командой в планерку, берете маркеры и начинаете рисовать. Вы даже отрываете код и рисуете поверх кода.
Видите ли, те зануды, которые придираются к листочку на собеседовании — никогда не будут это делать. Они будут нудить, что все до них — идиоты, что надо переписать архитектуру, что нужен вообще другой фреймворк. Они будут искать виноватых. Они забывают, что они в команде и думают, что они — главные звёздочки. Им плевать, что игра уже несколько лет как запущена и в неё играют тысячи людей прям сейчас. Что это всё отлично работало. А люди, которые пишут на листочке код — идут и ищут решение вместе.
Я никогда не считал свой код идеальным. И собеседования у меня тоже не идеальны. Я нанимал ужасных людей и, уверен, пропустил хороших. Но я уверен, что если у человека настолько корона упирается в потолок, что он откажется писать со мной код на листочке, то такой человек не нужен ни в одной команде, в которой я бы хотел работать.
Разработчики зачастую пишут похожий код ежедневно.
Сисадмины и девопсы часто решают разовые задачи по настройке чего-либо, и в силах этого не могут помнить наизусть все косвенные вещи, которые им пришлось применить.
Поэтому практические задачи с ручкой сильно ограничены, и придираться или не придираться к мелочам в синтаксисе — вопрос на миллион.
Сисадмины и девопсы часто решают разовые задачи по настройке чего-либо, и в силах этого не могут помнить наизусть все косвенные вещи, которые им пришлось применить.
Поэтому практические задачи с ручкой сильно ограничены, и придираться или не придираться к мелочам в синтаксисе — вопрос на миллион.
Разработчики зачастую пишут похожий код ежедневно.
Таких разработчиков называют кодерами.
Таких разработчиков называют кодерами.
Главное что деньги они получают такие же, как и «разработчики» )))
>> Таких разработчиков называют кодерами.
Месье архитект — пишет код раз в месяц? У нас как-то был такой, архитектор ПО (по институтсткой специальности, сразу из института), заявивший что его дело архитектуру рисовать, а не руки пачкать реальным кодом. Чем весьма позабавил и начальство, и коллектив.
Месье архитект — пишет код раз в месяц? У нас как-то был такой, архитектор ПО (по институтсткой специальности, сразу из института), заявивший что его дело архитектуру рисовать, а не руки пачкать реальным кодом. Чем весьма позабавил и начальство, и коллектив.
Месье каждый день пишет разный код.
А кодер — один и тот же переписывает, раз за разом?
Такое разнообразие возможно только в небольшом проекте. Иначе неизбежно будет специализация.
Кодер/разработчик/инженер вообще натянуто. В проекте в одно лицо будет «инженером», в большом проекте «кодером». В большом проекте и главный архитектор будет рисовать почти одно и тоже каждый день.
Такое разнообразие возможно только в небольшом проекте. Иначе неизбежно будет специализация.
Кодер/разработчик/инженер вообще натянуто. В проекте в одно лицо будет «инженером», в большом проекте «кодером». В большом проекте и главный архитектор будет рисовать почти одно и тоже каждый день.
А кодер — один и тот же переписывает, раз за разом?
https://habr.com/post/434864/#comment_19572650
Такое разнообразие возможно только в небольшом проекте. Иначе неизбежно будет специализация.
Специализация — это свой небольшой проект в общем большом. Так что размер не имеет значения.
В большом проекте и главный архитектор будет рисовать почти одно и тоже каждый день.
Гнать такого архитектора, он впустую ест хлеб.
Если говорить о каких-то мелочах на пару-тройку строк, то нормально, но если надо писать какую-то функцию на чёрт знает сколько строк или полноценное решение тестовой задачи, то абсолютно неадекватно. Это говорит о том, что вместо того, чтобы заниматься процессом приёма человека на решение проблем бизнеса, собеседующий просто играет в «я экзаменатор, а ты сдаёшь экзамен».
Когда я чувствую такой подход «я экзаменатор, а ты сдаёшь экзамен», то я переключаюсь в такой же режим. Я сообщаю «экзаменатору», что хочу работать в сильной команде, поэтому устраиваю ему ответный опрос с требованием решать уже мои задачки. Если отказывается, то я ему говорю, что нам не по пути и мы прощаемся
Я не автор, но у меня встречный вопрос — а что вы хотите проверить этим? У каждого теста должна быть цель и ожидаемые результаты.
В общем случае это похоже на тест либо знаний, если вы просите олимпиадника реализовать известный алгоритм, либо на умение быстро искать решение в сжатые сроки при определённом уровне стресса. Данный тест скорей всего не имеет значение в 95% ситуаций, которые возникнут у кандидата на новом месте работы.
В общем случае это похоже на тест либо знаний, если вы просите олимпиадника реализовать известный алгоритм, либо на умение быстро искать решение в сжатые сроки при определённом уровне стресса. Данный тест скорей всего не имеет значение в 95% ситуаций, которые возникнут у кандидата на новом месте работы.
Базовые знания Computer Science. Может ли человек написать цикл, решить такую задачу как ФизБаз и умеет ли в основы программирования.
Моя практика десятков собеседований на сеньйоров в известную компанию, с людьми, которые имеют хорошее резюме показывает, что больше половины серьезно врут в своих резюме и не умеют программировать даже на уровне миддла.
Они не могут написать ФизБаз, серьезно
что больше половины серьезно врут в своих резюме и не умеют программировать даже на уровне миддла.
Да, есть такое, подтверждаю! Не скажу за половину, но я видел достаточно людей с 10+ годами опыта которые не могут такое написать.
UFO just landed and posted this here
значит вы просто не умеете читать резюме и отсеивать мутных кандидатов
О! Вполне возможно. Рад, что у нас в комментариях есть гуру, который никогда не ошибается и сейчас всех научит, как отделить зёрна от плевел
Содержание 90% от всех резюме (спасибо hh.ru за наше счастливое детство):
Иванов Иван Иваныч, столько-то лет, такой-то город, (не) готов к переезду
20хх-20хх — ООО «Вектор», программист. Обязанности: программы программировал.
<n похожих строчек>
Навыки: git, github, программирование, баззворды.
О себе: трудолюбивый, целеустремленный, нацеленный на результат.
Сопроводительное письмо: хочу у вас работать, потому что вы классные.
20хх-20хх — ООО «Вектор», программист. Обязанности: программы программировал.
<n похожих строчек>
Навыки: git, github, программирование, баззворды.
О себе: трудолюбивый, целеустремленный, нацеленный на результат.
Сопроводительное письмо: хочу у вас работать, потому что вы классные.
Чтоб по такому составить хоть сколько-то правдивое и полное мнение о кандидате — нужно быть Вангой 110lvl.
Не надо быть вангой. Когда я отбирал кандидатов, чтобы пригласить на собеседование (.NET), я обращал внимание на 4 вещи:
1. Предыдущее место работы. Мир .NET довольно узок, я примерно представляю где какой уровень разработки
2. Ключевые слова с упоминанием IoC, DDD, TDD, SOLID. Если они есть, то человек, скорее всего, задумывался над проектированием.
3. Сертификаты MS. Если человек их реально сдавал, то, скорее всего, он был мотивирован упорядочить свои знания.
4. Образование. Если человек закончил топовый технические вуз, то вероятность того, что он что-то умеет программировать весьма высока.
Комбинация из этих фильтров позволяла мне беседовать с кандидатами, у которых не было проблем с физбазом.
Вот вашего Ивана Иваныча я бы позвал только если в ключевых словах были нужные + ( топовый вуз или МСовские серты ). Как-то так.
1. Предыдущее место работы. Мир .NET довольно узок, я примерно представляю где какой уровень разработки
2. Ключевые слова с упоминанием IoC, DDD, TDD, SOLID. Если они есть, то человек, скорее всего, задумывался над проектированием.
3. Сертификаты MS. Если человек их реально сдавал, то, скорее всего, он был мотивирован упорядочить свои знания.
4. Образование. Если человек закончил топовый технические вуз, то вероятность того, что он что-то умеет программировать весьма высока.
Комбинация из этих фильтров позволяла мне беседовать с кандидатами, у которых не было проблем с физбазом.
Вот вашего Ивана Иваныча я бы позвал только если в ключевых словах были нужные + ( топовый вуз или МСовские серты ). Как-то так.
Ключевые слова с упоминанием IoC, DDD, TDD, SOLID. Если они есть, то человек, скорее всего, задумывался над проектированием.
После ваших слов я задумался, а не добавить ли мне это в мой Linkedin профайл. Раньше мне бы и в голову не пришло, что кто-то подобное там выискивает. Т.к. сам я строку с "SOLID, IoC, TDD, BDD" трактовал бы как "на работе я работу работаю". И увидев это в резюме подумал бы, что кандидат любит звучные баззворды и играет в SEO.
А если вам попадается вакансия, где паттерны\подходы\whatever не перечислены, то получается кандидат отфильтровывается "комбинацией фильтров" и его резюме к вам на стол не попадает?
Работу вы работаете с помощью инструментов — IoC, DDD, TDD, SOLID тоже инструменты. В резюме вы перечисляете чем занимались и какие инструменты использовали. На собеседовании вы, в том числе, обсуждаете как выбирали инструменты, как ими реально пользовались, степень владения ими.
Эти признаки для меня имеют разные веса. Известное мне место работы + крутой вуз, вероятно, гарантируют беседу. А только лишь ключевые слова без всего остального — скорее всего нет.
Это вещи которые важны мне. Другим людям, может, алгоритмы важны или доскональное знание языка, например.
Эти признаки для меня имеют разные веса. Известное мне место работы + крутой вуз, вероятно, гарантируют беседу. А только лишь ключевые слова без всего остального — скорее всего нет.
Это вещи которые важны мне. Другим людям, может, алгоритмы важны или доскональное знание языка, например.
Крутой вуз имеет настолько большую вероятность хороших умений?
Диплом крутого вуза говорит мне, что либо у человека хорошо варит голова, либо он умеет крутиться. Выяснить я смогу во время беседы. Хорошие «умения» не столь важны, как хорошо варящая голова
Хоть я с этим тоже не очень согласен, но я хотел указать на другое, что вы отсеете своим фильтром людей, у которых возможно есть «умения» лучше, чем у человека из крутого вуза или с сертификатом.
Совершенно точно. Но у меня нет времени искать иголки в сене и вряд ли у кого-то, кто проводит собеседования, оно есть.
К тому же, у человека без вуза и сертов есть еще опции крутого предыдущего места работы и правильных ключевых слов.
К тому же, у человека без вуза и сертов есть еще опции крутого предыдущего места работы и правильных ключевых слов.
Складывается ощущение, что к вам синьоры-помидоры толпами идут, гроздьями сыпятся, лица друг другу в фойе разбивают, что ты такие фильтры ставите. Правда что-ли?
В том месте, где я проводил собеседования, были конкурентные условия труда, некоторый бренд, белая рыночная зп и почти не было текучки. Могли себе позволить нанимать неспеша по полгода.
В текущем месте требования, думаю, еще жестче. Но теперь это не моя работа :)
В целом, коллективы и там, и тут состояли из выпускников МГУ, МФТИ, МИФИ и Бауманки.
В текущем месте требования, думаю, еще жестче. Но теперь это не моя работа :)
В целом, коллективы и там, и тут состояли из выпускников МГУ, МФТИ, МИФИ и Бауманки.
Когда называют эти 4 названия в одном ряду, у меня закрадывается сомнение, что называет их человек, причастный к ним.
С ужасом представляю холиворы в коридорах между кадрами из разных альма-матер.
Через 5-10 лет после выпуска всем пофиг
Не всем.
Ну мои соболезнования этим не всем :)
Не, ну мне в университете хватило не то что срачей «МГУ против Бауманки», но даже «мехмат против ВМК» и даже «механики против математиков».
Но вообще, если по теме, я никакой особой корреляции между уровнем программиста и высшим образованием не нашел за годы своего опыта, а анекдотических контрпримеров хватает и в одну, и в другую стороны.
Сам из-за своей этой деформации (я мехмат бросил на середине) я никогда в графу образования на собесах не смотрю, ко мне вроде тоже уже не смотрят, благо в резюме есть чего еще почитать, но главный принцип обиженного отечественным высшим — если меня не берут, потому что не подхожу образованием, то и мне вряд ли понравится на таких ребят работать.
Но вообще, если по теме, я никакой особой корреляции между уровнем программиста и высшим образованием не нашел за годы своего опыта, а анекдотических контрпримеров хватает и в одну, и в другую стороны.
Сам из-за своей этой деформации (я мехмат бросил на середине) я никогда в графу образования на собесах не смотрю, ко мне вроде тоже уже не смотрят, благо в резюме есть чего еще почитать, но главный принцип обиженного отечественным высшим — если меня не берут, потому что не подхожу образованием, то и мне вряд ли понравится на таких ребят работать.
2. Ключевые слова с упоминанием IoC, DDD, TDD, SOLID. Если они есть, то человек, скорее всего, задумывался над проектированием.
А потом, на собеседовании:
— Что такое SOLID?
— Я не знаю
— Ну у вас в резюме ведь написано
— Все пишут — вот и я написал.
пс. это реальный диалог с собеседования
UFO just landed and posted this here
Тогда уж твердая фигура…
Ну, так первый барьер HR, а они по ключевым словам ищут, вот и получается так.)Ну да, взять этот барьер ложью, чтобы потом облажаться на собеседовании — это гениальное решение.
Мне откровенно непонятно вот что. Человек пишет у себя в резюме такие вещи как SOLID, Design Patterns, TDD. Неужели так сложно почитать и понять, что это? Неужели так сложно выучить 5 примеров разных паттернов? Если уж написал, что знаешь их.
Насколько наплевательское должно быть отношение, чтобы даже не почитать, что там у тебя написано в резюме?
PS. SOLID — объемная фигура :))
Стиль границы в css =)
спасибо за полезную статью.
Кстати у автора есть телеграмм канал: t.me/full_of_hatred
Кстати у автора есть телеграмм канал: t.me/full_of_hatred
А замечали ли вы корреляцию в зависимости возраста собеседующего?
Спасибо за статью.
хотелось бы узнать мысли по поводу следующих пунктов.
— есть ли в смысл в собеседованиях с алго задачами? в случае, если первые этапы такие, а далее уже обсуждение и решение более реальных задач?
— лучше ли проводить в какой-то онлайн доке (кодерпад тот же), или же вайтборд/бумажка?
— есть ли место для онлайн интервью? все этапы онлайн (если релокейт, к примеру) — нормально?
— нужно ли искать максимум и лимит кандидата на собеседовании, или же смотреть четко в границах проекта (и/или технологий)?
На самом деле интересно обсудить тему тех собеседований, так как в принципе в Европе (и постсовке) спрашивают что попало, и процесс часто отличается. За океаном же наоборот — есть стандартизированный подход к интервью, и даже книжки написаны :)
хотелось бы узнать мысли по поводу следующих пунктов.
— есть ли в смысл в собеседованиях с алго задачами? в случае, если первые этапы такие, а далее уже обсуждение и решение более реальных задач?
— лучше ли проводить в какой-то онлайн доке (кодерпад тот же), или же вайтборд/бумажка?
— есть ли место для онлайн интервью? все этапы онлайн (если релокейт, к примеру) — нормально?
— нужно ли искать максимум и лимит кандидата на собеседовании, или же смотреть четко в границах проекта (и/или технологий)?
На самом деле интересно обсудить тему тех собеседований, так как в принципе в Европе (и постсовке) спрашивают что попало, и процесс часто отличается. За океаном же наоборот — есть стандартизированный подход к интервью, и даже книжки написаны :)
есть ли в смысл в собеседованиях с алго задачами? в случае, если первые этапы такие, а далее уже обсуждение и решение более реальных задач?
да, если эти знания нужны в работе. вот у меня на предыдущей работе была целая куча древовидных структур данных, поэтому я просил кандидатов обойти дерево.
лучше ли проводить в какой-то онлайн доке (кодерпад тот же), или же вайтборд/бумажка?
код однозначно в кодерпаде/repl.it (последний добавил многопользовательский режим недавно, так что в кодерпаде нет смысла больше), архитектуру на бумажке
есть ли место для онлайн интервью? все этапы онлайн (если релокейт, к примеру) — нормально?
я там в статье писал что у меня почти все собесы были онлайн ))) смысла в офис ходить щас нет как мне кажется.
нужно ли искать максимум и лимит кандидата на собеседовании, или же смотреть четко в границах проекта (и/или технологий)?
в зависимости от позиции. я бы смотрел на общий уровень и не обращал внимания на незнание каких-то конкретных вещей.
На самом деле интересно обсудить тему тех собеседований
еще две статьи на очереди )))
Унылый интервьюер — подарок свыше. Частенько, работать будете с тем же руководителем, который его напряг делать то от чего он не в восторге. Остается узнать о проекте и если пребывание на интервью было для него меньшим из зол то в случае успеха просите заградительный миллион (ну вы поняли).
«Ваше резюме никто не читает» — как человек, проведший более 100 собеседований, и подходящий к процессу с большой отдачей, могу вам сказать, что это частично оправдано. Многие толковые люди не умеют их составлять, многие бестолковые спецы в них привирают. Образование не коррелирует с тех. грамотностью. Прошлые работодатели не коррелируют тоже (доводилось вам работать с идиотами? а компания в резюме будет одна и та-же). По итогам, оптимальная стратегия — просто сверка ключевых слов, и то, самого высшего уровня. Более реально что-то понять только в беседе — вот там настоящее собеседование.
По опыту, могу выделить только 3 позитивных маркера в резюме:
— Ссылка на свой блог или Github (Github это вообще джекпот, особенно если кандидат пишет тесты);
— Общая структурированность — визуальная и информационная (единообразный шрифт и отступы в параграфах, форматирование подчёркивает структуру и ключевую информацию);
— Краткость (кем бы вы там ни были, резюме должно влезть в 2 страницы). Идеал не про «Нечего больше добавить», а про «Нечего больше выкинуть».
По опыту, могу выделить только 3 позитивных маркера в резюме:
— Ссылка на свой блог или Github (Github это вообще джекпот, особенно если кандидат пишет тесты);
— Общая структурированность — визуальная и информационная (единообразный шрифт и отступы в параграфах, форматирование подчёркивает структуру и ключевую информацию);
— Краткость (кем бы вы там ни были, резюме должно влезть в 2 страницы). Идеал не про «Нечего больше добавить», а про «Нечего больше выкинуть».
UFO just landed and posted this here
Я провел тоже больше сотни. Иногда было по интервью каждый день, в течение двух недель.
Всегда читаю резюме.
Если файнал интервью (у нас их два), то подготовка к нему не меньше 30 минут, а желательно час.
Ок, я как бы из параллельной реальности (embedded и вообще hardware). Но позволю не согласиться с двумя важными пунктами:
- нам очень важно с кем работать, поэтому большое значение уделяет team fit,
- у нас всегда есть план по поводу того чем будет заниматься человек,
- босс всегда присутствует, и даже босс босса если кандидат хороший.
Большую проблему представляет то что нам нужен типа "exceptional talent". Поэтому если кандидату не повезло ответить на какой-то глупый вопрос, то начинаются трудности, потому что на обсуждении возникают реплики "оу, он не знает X или Y, как же нам его брать"
Ок, я как бы из параллельной реальности (embedded и вообще hardware). Но позволю не согласиться с двумя важными пунктами
Конечно есть софтверные компании, которые тоже это делают, просто они мне не попались — выборка маленькая.
Ну а ваша компания скорее всего тоже исключение, вот походите в десяток других хардверных контор и расскажите нам, там так же как у вас, или «как везде».
А как автор относится к тому, что собеседующий на том конце Скайпа отключил свою камеру и общается только голосом (реальный случай)? Тоже отключитть свою камеру, послать его лесом, етс?
А как автор относится к тому, что собеседующий на том конце Скайпа отключил свою камеру и общается только голосом (реальный случай)?
Нормально, может человеку некомфортно. Странно только что он это сделал без предупреждения и посреди разговора?
Тоже отключитть свою камеру, послать его лесом, етс?
Я обычно перед собеседованием уточнял нужна камера или нет. Так и вам советую поступать.
Я бы просто отключил камеру без всяких уточнений — очевидно он просто находится в месте, где не очень удобно с видео, тч вы вполне вправе сделать то же самое.
Если интернет плохой — то отключение камеры делает хотя бы звук нормальным.
Но лучше объяснить причину, конечно.
Но лучше объяснить причину, конечно.
Я имел ввиду, что с выключенной камерой начал разговор руководитель из компании, т. е. будущий начальник, а не тот, кто устраивается на работу.
Лично я вижу некоторое противоречие в утверждении «вы ни кому не нужны» и рекомендации выполнять тестовое задание. Скорее всего его будут смотреть так же как и резюме. Рекомендую не выполнять тестовые задания в случае позиционирования как сеньера.
С тем, что по описанию вакансии невозможно понять что-то о конторе не соглашусь. На самом деле по тому как составлено описание уже можно рассмотреть уровень конторы и наличие адекватных специалистов в ней. А так же на сколько эти специалисты заинтересованы в вакансии.
С тем, что по описанию вакансии невозможно понять что-то о конторе не соглашусь. На самом деле по тому как составлено описание уже можно рассмотреть уровень конторы и наличие адекватных специалистов в ней. А так же на сколько эти специалисты заинтересованы в вакансии.
«Сделайте проект с нуля (возможно, используя конкретную технологию) и выложите его на GitHub» — как по мне, наихудший вариант.
Как по мне — это оптимальный вариант узнать способности кандидата на позицию разработчика. В нашей компании так и поступаем. Когда решение задании готово, один из senior разработчиков проверяет работу кандидата.
Как по мне — это оптимальный вариант узнать способности кандидата на позицию разработчика.
Оптимальный вариант это взять его на день поработать в паре над какими-то багами. Задание человек может сделать не сам. Кроме того, объемные задания сокращают вам воронку.
Наверное, такое возможно в небольшой компании, но в средних и больших компаниях непросто взять человека и допустить его к закрытым исходникам.
Что плохого в том, что кандидат дома, в спокойной обстановке, потратит пару часов своего времени на программирование задания?
Что плохого в том, что кандидат дома, в спокойной обстановке, потратит пару часов своего времени на программирование задания?
взять человека и допустить его к закрытым исходникам
зачем допускать, парное программирование же
Для парного программирования оба должны быть хорошо знакомы с внутренними механизмами разрабатыемой системы. Иначе один из них будет выглядеть дураком, который на самом деле таким может и не является. А просвещать человека во внутренние процессы той или иной системы, который может оказаться просто проходимцем — не очень разумно.
Для парного программирования оба должны быть хорошо знакомы с внутренними механизмами разрабатыемой системы.
Так в том то и дело что именно в такой задаче очень легко понять человек вообще сможет работать у вас в конторе или нет ) Не обязательно делать большую штуку, достаточно мелкого бага.
Некоторые западные компании такой подход практикуют и проповедуют, например, Basecamp.
--Ваше резюме никто не читает
Категорически несогласен — на всех очных собеседованиях на руках были мои резюме из HR, а в Амазоне тимлид даже спросил почему я не принес полное резюме. Обычно выкладываю за последние 10 лет только (от масшатбов иcполненых проектов в СССР обычно у людей челюсть отвисает) — был неготов к такому повороту.
--Вы не будете разговаривать со своим будущим боссом или тимлидом
Категорически несогласен — И в маленьких и больших компаниях обязательна встреча и с тем и с другим — и это не менялось за последние 20 лет собеседований.
Категорически несогласен — на всех очных собеседованиях на руках были мои резюме из HR, а в Амазоне тимлид даже спросил почему я не принес полное резюме. Обычно выкладываю за последние 10 лет только (от масшатбов иcполненых проектов в СССР обычно у людей челюсть отвисает) — был неготов к такому повороту.
--Вы не будете разговаривать со своим будущим боссом или тимлидом
Категорически несогласен — И в маленьких и больших компаниях обязательна встреча и с тем и с другим — и это не менялось за последние 20 лет собеседований.
Вы не будете разговаривать со своим будущим боссом или тимлидом
Я конечно не знаю, как дела обстоят в России, но за весь мой рекрутерский опыт в Канаде такого не было и быть не могло. Другое дело, что первое интервью может быть с технарями коллегами, если непосредственный начальник не силен в технических вопросах и не может оценить навыки кандидата. Но в конце концов интервью с менеджером будет и он\она будет сам принимать решение.
Бывают еще компании с матричной структурой (чаще всего консалтинговые), это когда всех нанятых гуртом записывают под одного менеджера, который их никогда и не видит, а работают эти сотрудники непосредственно на проектах, для которых их наняли. Ну тогда конечно с формальным менеджером, на которого их записали, они не встречаются, т.к. его мнение никому не нужно. Но с лидом или менеджером проекта, на котором они будут работать, они обязательно интервьюируются.
Важный совет касательно правильного общения в телеконференциях: заведите привычку не говорить и не печатать на клавиатуре, когда говорит другой человек, и разговаривать по гарнитуре, а не, например, через внешний микрофон ноутбука и внешние колонки.
Очень дельный совет. Гарнитура обязательна, ну или по крайней мере говорить в телефон а не на спикере. И ждать окончания фразы, чтобы свою вставить.
Sign up to leave a comment.
Senior Engineer в поисках работы. Как я прошел 15 технических собеседований и что я об этом думаю