Комментарии 151
Статья хороша тем, что правильно убирает фокус от не нужных вещей, типа "НЕ спрашивать про частности, про конкретные инструменты, про люки".
И содержит много полезных мелочей во вспомогательных темах (типа раздела "мотивация").
Тем не менее, хотя на собеседовании важно ответить на 4 важных вопроса (типа "может ли кандидат работать на этой должности", "хочет ли работать на этой должности" и т.п.) ключевой раздел — компетенции — освещён недостаточно.
То есть неплохо бы раскрыть более подробно как именно проверить знание алгоритмов, архитектуры… И не "от противного", а без этих "не", которыми полна эта статья.
Так что было бы неплохо увидеть продолжение!
боюсь проверить компетенции в мире ИТ практически невозможно. можно только построить гипотезу тк правильные ответы не дают гарантий, что человек умеет это применить, ровно как и не знание теории не говорит о непригодности. тут все очень сложно и строится на чистой субъективности
Спасибо за предложение, возможно, следующая статья будет именно про оценку компетенций Senior-разработчика.
Я бы чуть-чуть поправил пункт про «кто должен собеседовать». Все таки перекрестный опрос хоть и стресс, но моя практика показывает, что это наиболее эффективный способ задать правильные вопросы и правильно интерпретировать ответы на них. По мимо лида на собеседовании должен присутствовать hr (или грамотный манагер с пониманием психологии) и ещё кто нибудь из команды разработки. Что это даёт в сумме: у компании и команды есть возможность презентовать себя не одним лицом, что позволит собеседоемому чуть лучше понимать во что он хочет ввязаться. У команды же появляется возможность спросить самые многогранные вопросы в контексте и правильно понять ответы, принять коллективное решение. Если идти по пути я начальник — я все знаю (один в поле воин) можно что-то упустить, не так понять и пр человеческие факторы.
Есть только одно требование к подобным собеседованиям: все представители команды должны работать как единый организм, а не тянуть одеяло на себя.
Меня лично собеседовали и 5 технарей (вся дев команда) и солянка из представителей каждого организационного уровня. Что мне, как собеседуемому, позволяло понимать куда я попал и что будет дальше если принять оффер. В роли собеседующего (лида) за последние 2 года мы выработали практику, что в собеседовании участвуют минимум 2 технаря и всегда заранее обсуждаем некую стратегию чтобы не устраивать хаос. Не всегда, но частенько так же участвует hr дабы спрашивать другие правильные вопросы. После чего принимаем коллективное решение.
Есть только одно требование к подобным собеседованиям: все представители команды должны работать как единый организм, а не тянуть одеяло на себя.
Меня лично собеседовали и 5 технарей (вся дев команда) и солянка из представителей каждого организационного уровня. Что мне, как собеседуемому, позволяло понимать куда я попал и что будет дальше если принять оффер. В роли собеседующего (лида) за последние 2 года мы выработали практику, что в собеседовании участвуют минимум 2 технаря и всегда заранее обсуждаем некую стратегию чтобы не устраивать хаос. Не всегда, но частенько так же участвует hr дабы спрашивать другие правильные вопросы. После чего принимаем коллективное решение.
Если Вы Тим Лид, то жизнь Вам дарит одну из интересных возможностей себя проявить — набрать свою команду, под свои нужды, видение, вкусы и личную совместимость. Помимо возможностей, тут есть конечно же и ответственность. Размывая или перекладывая ответственность за решения на других ставит Вашу компетенцию как начальника под сомнение. Возможно, Тимлидство просто не для Вас.
А уж привлекать на техническое собеседование HR — это с какой целью? Разработчики, а тем более высококвалифицированные, мягко говоря, бывают весьма нестандартными людьми. У них могут быть свои нюансы в общении и мышлении, что может показаться HR-специалисту подозрительным, он будет против них и отсеет вполне годных кандидатов.
А уж привлекать на техническое собеседование HR — это с какой целью? Разработчики, а тем более высококвалифицированные, мягко говоря, бывают весьма нестандартными людьми. У них могут быть свои нюансы в общении и мышлении, что может показаться HR-специалисту подозрительным, он будет против них и отсеет вполне годных кандидатов.
Тимлид с презумпцией того, что HR не способен разбираться в рамках своей компетенции, похож на «познавшего дзен».
Зачем накладывать на себя бремя разруливать конфликты нового члена команды из-за несовместимости со старыми, если это можно проверить на берегу?
А уж привлекать на техническое собеседование HR — это с какой целью? Разработчики, а тем более высококвалифицированные, мягко говоря, бывают весьма нестандартными людьми. У них могут быть свои нюансы в общении и мышлении, что может показаться HR-специалисту подозрительным, он будет против них и отсеет вполне годных кандидатов.
Собственно это же и есть прямая обязанность HR: управлять людьми и одна из сторон этого управления — оценивать кто впишется, а кто — нет. Если вы считаете что ваш HR не способен правильно оценить разработчика, то либо вы неправы, либо у вас некомпетентный в своей области HR.
Тестовые даете?
Нет, тестовые не даем.
Я стараюсь больше уделять внимание тому, КАК кандидат мыслит, а не ЧТО он знает.
Конкретные знания конечно же важны, но в каком-то пределе, а вот умение мыслить — бесценно.
А тестовые не даем по нескольким причинам одна из которых — хорошие спецы в них не нуждаются и более того с высокой вероятностью сразу Вас пошлют при первом же намеке на тестовое (я и сам не люблю тестовые)
Я стараюсь больше уделять внимание тому, КАК кандидат мыслит, а не ЧТО он знает.
Конкретные знания конечно же важны, но в каком-то пределе, а вот умение мыслить — бесценно.
А тестовые не даем по нескольким причинам одна из которых — хорошие спецы в них не нуждаются и более того с высокой вероятностью сразу Вас пошлют при первом же намеке на тестовое (я и сам не люблю тестовые)
А Мне вот дали тестовое и я не послал. Может я не senior? И тестовое было интересным и я понимал почему оно именно такое.
у вас просто много времени или желания
Есть еще такой момент — если ты, Google, то можешь давать тестовое.
Если обычная средняя компания, то давая тестовое, ты отсекаешь часть годных кандидатов.
Если обычная средняя компания, то давая тестовое, ты отсекаешь часть годных кандидатов.
Не факт. Есть и вторая сторона. На работу искал себе в команду мидла-сеньора — все как на подбор джуны оказываются. Ни знаний, ни умений, ни опыта.
Тестовое даём реально на 1-2 часа делать дома без ограничения по времени — оно отсекает около 90% джунов, желающих получать сеньорскую зп.
100% джунов можно отсечь по CV и 5-минутному разговору по телефону.
Всякое бывает. Может условия такие были, что мидлы, сеньоры мимо проходили.
При одинаковых условиях, для экономии своего времени, я сначала выбирал вакансии без тестовых задач. А то 10 конторам сделать тестовые на 1-2 часа уйдет часов 50, пока будешь стараться сделать как можно лучше и перепроверять.
При одинаковых условиях, для экономии своего времени, я сначала выбирал вакансии без тестовых задач. А то 10 конторам сделать тестовые на 1-2 часа уйдет часов 50, пока будешь стараться сделать как можно лучше и перепроверять.
Вы знаете, это очень отличается от того что я знаю из своего опыта или опыта близких знакомых. Я согласен с JordanoBruno в том, что резюме и 5-10 минут погооврить достаточно, чтобы отсечь явно не подходящих кадров.
Как я понял, вы судите исключительно по тестовому заданию — и тут либо вы его даете просто всем (естественно, что 90% людей оказываются неподходящими) либо ваше мерило уровня не совпадает с общепринятым.
Когда мы практиковали тестовое задание — до половины кандидатов его проходило… чтобы потом неприятно удивить на собеседовании. Поэтому сейчас я предпочитаю сессию парного программирования тестовому. Очень сложно правильно судить о специалисте только по его «искуственному» коду.
Как я понял, вы судите исключительно по тестовому заданию — и тут либо вы его даете просто всем (естественно, что 90% людей оказываются неподходящими) либо ваше мерило уровня не совпадает с общепринятым.
Когда мы практиковали тестовое задание — до половины кандидатов его проходило… чтобы потом неприятно удивить на собеседовании. Поэтому сейчас я предпочитаю сессию парного программирования тестовому. Очень сложно правильно судить о специалисте только по его «искуственному» коду.
(очень давно) Как-то сделал тестовое(большое, и гарантированно ему нет применения на практике) оно вроде как о очень понравилось (и отняло у меня прилично времени, т.к. я от этой темы уже отошёл к тому моменту), в итоге мы не сошлись чем-то(на мой взгляд оценкой важности тех или иных вещей хотя кто знает) с непосредственным "будущим начальником", вот и зачем я его заранее делал...
Т. е. можно дать тестовое, и если кандидат пошлёт откажется, значит хороший спец
НЛО прилетело и опубликовало эту надпись здесь
Мне както предложили поработать недельку а потом они мне скажут подхожу я или нет. Причем это стандартная практика у них.
Компания довольно интересная, гео расчеты, свой супер компьютер (в 5ке самых мощных в южном полушарии), но как то нереалистично для не студентов.
Вот они отсекают очень немало хороших кандидатов.
Имхо, одно дело тестовое для реально крутой компании а-ля Гугла, Яндекса, Амазона, Мейл.ру и совсем другое для Васи Пушкина.
У меня есть три вопроса, и не только к автору, буду рад если увижу много ответов: сколько разработчиков в вашей практике покидали команду из-за некомпетентности (недостаточных знаний, медленной работы, большого количества ошибок)? Сколько из-за денег? Сколько по другим причинам?
В хорошей комфортной команде, при адекватном отборе на собеседовании, при оплате как минимум по рынку и не на говнопроектах или стартапах текучка будет небольшая(5-10% в год). Многое зависит от возраста — молодые(до 30 лет) намного проще уходят. Причины ухода бывают разные, но весьма стандартные — деньги, хочется других и интересных задач, хочется карьеры, с кем-то не сработался и это критично, предложили более интересное/выгодное место. Нужных специалистов держат, тех кого несложно заменить — нет.
Я так понимаю, что DrFdooch хотел услышать вашу статистику.
Спасибо, я так понял что из-за недостаточной квалификации практически ни с кем не приходится расставаться.
А как вы определяете, держать спеца или нет?
Квалификация проверяется на собеседовании, если кандидат ее прошел — значит с ней проблем нет.
Держат тех, кого заменить тяжело. Например Вася знает хорошо проект, успешно развивает значительную его часть и у него нет серьезных конфликтов.
Держат тех, кого заменить тяжело. Например Вася знает хорошо проект, успешно развивает значительную его часть и у него нет серьезных конфликтов.
а как держат, и на сколько велик шанс, что удержат?
Т.к. думаю, что очень сложно, уловить «уплывающего» тёпленьким, прежде чем он объявит об уходе…
Или у Вас это проходит стабильно, раз, два, н раз в году собеседование и премия или повышение?
Т.к. думаю, что очень сложно, уловить «уплывающего» тёпленьким, прежде чем он объявит об уходе…
Или у Вас это проходит стабильно, раз, два, н раз в году собеседование и премия или повышение?
Квалификация проверяется на собеседовании
А как вы отбираете людей на собеседование?
Устроился 3 года назад в контору на ЗП мидла в нижней планке по городу, т.к. только переехал в крупный город и деньги физически заканчивались, а других офферов не было.
Сейчас я тут тимлид, фулстек, девопс, 3 человека в подчинении (сам набирал)… Сам с нуля поднимал и настраивал прод, жиру, гитлаб. Скрипты, вебхуки и прочее. Задачи раскидываю по команде, скрипты автоматизации писал…
… спросил за повышение хотя бы до уровня сеньора — сказали "у нас нет таких зарплат" и подняли на 10%. Обидно.
Так как уволить они меня не могут (понимают что контора раком станет моментально), постепенно ищу другое подходящее место с комфортными условиями и, желательно, сложными задачами, т.к. от админок для лендинга уже блевать хочется.
Я бы спросил «Когда и как вы поняли, что стали Senior разработчиком?»
Лично я себя почувствовал сиром, когда я перестал искать задачи, задачи стали искать меня.
Когда тебя взяли на эту роль другие люди.
Между тем, как меня первый раз взяли на роль Senior, и моим полноценным осознанием своей «сеньорности»(и того, что её не было до этого), прошло порядка двух лет. До того я был достаточно сильным миддлом, который весьма неплохо справлялся с любыми задачами.
тогда я стал сеньором в 22 года (10 лет назад). Как угодно хотели продать заказчику, лишь бы подороже. Мне смешно было слушать также какой я хороший сеньор когда я увольнялся в 24. А начал чувствовать после двух кейсов:
— решения нескольких нестандартных сложнейших задач (архитектурно-производительных)
— когда остался одним опытным разработчиком на проекте и все лежало на мне продолжительное время, соответственно научился ответственности
— решения нескольких нестандартных сложнейших задач (архитектурно-производительных)
— когда остался одним опытным разработчиком на проекте и все лежало на мне продолжительное время, соответственно научился ответственности
Я бы перефразировал «Когда и как Вы поняли, что считая себя Senior Вы на самом деле не Senior?»
НЛО прилетело и опубликовало эту надпись здесь
Я вот до сих пор не знаю, кто я.
Вроде 5+ лет опыта есть — значит, сеньор.
С другой стороны, чем я занимался-то? Круды писал первое время, во фронт лазил, разве ж это опыт… Наверное миддл…
Хотя — последние несколько лет тяну проект, поднимал его вообще в одиночку, и вроде неплохо спроектировал — значит, всё же сеньор?
С другой стороны, проект-то так себе, внутри костыли, особо интересных задач нет, вокруг много таких же — кто угодно бы справился. Миддл?
Но опять же — уже на 7к рпс вышли, миллионы крутятся, куча технологий использована, наверное сеньор.
Но… Я же алгоритмов не знаю почти, паттерны программирования так и не изучил, какой я сеньор, так, миддл.
Но, мне же платят зарплату вполне себе сеньорскую по рынку, и повышают регулярно, со мной советуются другие разработчики, значит — сеньор?
Да блин, я за технологиями не слежу, более менее знаю только php, всё остальное по верхам нахватал, регулярно гуглю варианты — миддл?
И вот на таких качелях постоянно качаюсь. Кто я — хз, то ли я сеньор с синдромом самозванца, то ли миддл которому повезло получить хорошее место с высокой зарплатой.
Вроде 5+ лет опыта есть — значит, сеньор.
С другой стороны, чем я занимался-то? Круды писал первое время, во фронт лазил, разве ж это опыт… Наверное миддл…
Хотя — последние несколько лет тяну проект, поднимал его вообще в одиночку, и вроде неплохо спроектировал — значит, всё же сеньор?
С другой стороны, проект-то так себе, внутри костыли, особо интересных задач нет, вокруг много таких же — кто угодно бы справился. Миддл?
Но опять же — уже на 7к рпс вышли, миллионы крутятся, куча технологий использована, наверное сеньор.
Но… Я же алгоритмов не знаю почти, паттерны программирования так и не изучил, какой я сеньор, так, миддл.
Но, мне же платят зарплату вполне себе сеньорскую по рынку, и повышают регулярно, со мной советуются другие разработчики, значит — сеньор?
Да блин, я за технологиями не слежу, более менее знаю только php, всё остальное по верхам нахватал, регулярно гуглю варианты — миддл?
И вот на таких качелях постоянно качаюсь. Кто я — хз, то ли я сеньор с синдромом самозванца, то ли миддл которому повезло получить хорошее место с высокой зарплатой.
Наверное, всё зависит от компании и того, какую роль Вы выполняете в команде. У одних ты можешь быть сеньором, а у других — средним мидлом.
Опять же, есть люди кто и 5, и 10, и 15 лет работает в какой-нибудь веб-студии или что-то сам пытается не совершенствуясь и оставаясь максимум на переходном состоянии из джуна в мидлы.
Так что время я бы лично вообще не учитывал в определении сеньорства да и любого другого статуса.
Эта градация относительная, кто вы, зависит от вашего окружения.
Когда осознал что мой практический опыт значительно выше многих мидлов, с которыми работал. Также коллеги постоянно спрашивают как лучше организовать ту или иную архитектуру приложения и какие подводные камни я вижу.
НЛО прилетело и опубликовало эту надпись здесь
Может в начале каждого резюме писать) Как еще собеседующие это увидят?
НЛО прилетело и опубликовало эту надпись здесь
Это да.
У меня случай был, спрашивали вопросы только по шейдерам.
Только после собеседования я понял, что им шейдерщик был нужен. Я бы и сам на эту позицию не пошел, т.к. игровую логику хотел писать, а не шейдеры.
То что HR глянул резюме и увидел слово «шейдер», я не сомневаюсь. То, что его не читал собеседующий, я тоже не сомневаюсь.
У меня случай был, спрашивали вопросы только по шейдерам.
Только после собеседования я понял, что им шейдерщик был нужен. Я бы и сам на эту позицию не пошел, т.к. игровую логику хотел писать, а не шейдеры.
То что HR глянул резюме и увидел слово «шейдер», я не сомневаюсь. То, что его не читал собеседующий, я тоже не сомневаюсь.
Только это цель одной стороны, а не общая
может тимлид и хочет так вести собес, а ПМ ему говорит — подготовь список вопросов, на которые никто не ответит, и задавай побольше конкретики чтобы соискатель не сильно зарплату хотел и я мог бы этим надавить при разговоре, ссылаясь на то что «я не технический специалист, но вижу ваши пробелы»
Вы уж простите, что я спрашиваю. Но напомните, пожалуйста, а в каких компаниях вы работали и какие сильные продуктовые команды вы собрали и успешно ими руководите (руководили). Просто не нашел такой информации, может я плохо искал, тыкните, пожалуйста.
Хотелось бы ознакомиться и так сказать выслушать ваши учения и тезисы, которые вы бы подкрепили реальными результатами, а не голословными утверждениями.
Хотелось бы ознакомиться и так сказать выслушать ваши учения и тезисы, которые вы бы подкрепили реальными результатами, а не голословными утверждениями.
Ни разу еще мне не удавалось с помощью собеседований и тестовых заданий определить станет ли кандидат хорошим коллегой впоследствии…
Понял лишь что если сразу что-то явно не нравится, то надо извиняться и вежливо расставаться.
Можете рассказать об успешном собеседовании, в результате которого кандидат не стал хорошим коллегой? Мне кажется, такие ситуации происходят очень часто, но многие не обращают на них достаточно внимания.
У меня есть один хороший пример: канидат на собеседовании показал себя понимающим и опытным разработчиком, но по факту оказался неспособен работать в условиях малейшей неопределенности (а это в нашей сфере, к сожалению, норма). В итоге любая задача без исчерпывающей спецификации, с которой Senior должен как раз справляться без проблем, растягивается в три-четыре раза — и 10% лишнего времени уходит на собственно уточнения требований, а 90% — на фрустрацию и прокрастинацию от безысходности. В итоге разработчик чувствует себя, извините, говном (а это плохо не только для него); менеджмент периодически полыхает; перестроить процесс, работающий для остальных — невозможно. Спасает только парное программирование, но применять его постоянно тоже не выход.
У меня есть один хороший пример: канидат на собеседовании показал себя понимающим и опытным разработчиком, но по факту оказался неспособен работать в условиях малейшей неопределенности (а это в нашей сфере, к сожалению, норма). В итоге любая задача без исчерпывающей спецификации, с которой Senior должен как раз справляться без проблем, растягивается в три-четыре раза — и 10% лишнего времени уходит на собственно уточнения требований, а 90% — на фрустрацию и прокрастинацию от безысходности. В итоге разработчик чувствует себя, извините, говном (а это плохо не только для него); менеджмент периодически полыхает; перестроить процесс, работающий для остальных — невозможно. Спасает только парное программирование, но применять его постоянно тоже не выход.
О! Практикуете парное программирование!? Через TDD? Это замечательная техника! Я как раз считаю что применять это надо постоянно.
Если говорить про кандидатов, то 95% процентов из них показывают себя на собеседованиях вполне перспективно, а затем проваливаются в повседневной производственной коммуникации. Люди не устройства с совместимыми интерфейсами.
Более-менее адекватная оценка для кандидата появляется после пары месяцев совместной работы в обычной обстановке. И ежедневное парное программирование наиболее этому способствует.
95% процентов из них показывают себя на собеседованиях вполне перспективно, а затем проваливаются
Сергей, Вы точно что-то делаете не так на собеседованиях. Возможно, Вам стоит кардинально пересмотреть вопросы, которые Вы задаете. Предположу также, что Вы упускаете ключевые моменты из ответов кандидата.
О! Практикуете парное программирование!? Через TDD? Это замечательная техника! Я как раз считаю что применять это надо постоянно.
Замечательная, согласен :) Но постоянно парное применять не получается, есть категория задач, где надо сосредоточиться и войти в поток, сделать это вдвоем — это очень высокий уровень близости :)
НЛО прилетело и опубликовало эту надпись здесь
Для меня любой вопрос, не касающийся профессии, навыков, опыта работы или каких-то нужных кадровикам формальностей — это однозначно повод серьезно задуматься, нужно ли мне идти в эту компанию? Ну равзве что иногда интересуются твоим хобби или что-то такое — бывает, для поддержания как бы неформального общения. Остальное в топку. Это признак непрофессионализма а иногда откровенного дебилизма эйчара. И если руководство до сих пор не выгнало такого «специалиста» — значит само недалеко от него ушло.
Мой начальник так развлекался на собеседованиях, когда уже знал, что кандидат не подходит ему: просил спланировать воображаемую свадьбу или поиграть в «Крокодила». Эйчарам объяснял, мол, это для проверки действий в нестандартной ситуации.
Сразу видно уровень профессионализма вашего начальника. Интересно какой процент людей пришли бы на собеседование если бы знали про такие развлечения.
А прекратить тратить время он не пробовал?
Есть собеседования, где цель — не нанять человека, даже если это Джеймс Гослинг, Гвидо ван Россум и Сергей Брин в одном лице за скромную зарплату.
Вашему начальнику, видимо, совершенно все равно, какой имидж будет у вашей компании на рынке (а рынок ИТ, обычно, очень тесный даже в больших городах и информация расходится быстро). Это не делает ему чести, а лишь показывает его непрофессионализм.
К сожалению замечаю, что за частую упор на то что кандидат не знает. Объем знаний не оценивается.
НЛО прилетело и опубликовало эту надпись здесь
А что делать если вы гугл/нетфликс/etc?
Очень интересный и дельный, на мой взгляд, подход! Некая имитация совместной работы как раз даст возможность собеседуемому «выдохнуть» и поработать.
Вы не Гугл и никогда им не будете.
Я не был бы так категоричен. Гугл может позволить себе купить многие компании и покупает их.
Как понять, сможет ли кандидат эффективно у вас работать? — Очень просто, если он предыдущем месте проработал больше года, сможет и у вас.
Ключевое слово — эффективно.
Объективной информации о его работе на предыдущем месте у вас нет и не будет.
Кандидата могли терпеть по каким-то своим причинам больше года.
Теперь терпеть придется вам.
НЛО прилетело и опубликовало эту надпись здесь
Можно. Но я не уверен что информация будет достоверна.
В случае, если у человека был конфликт (и неважно по какой причине. Может, сотрудник был настолько ценный, что отпускать не хотели, и поэтому поругались) — вы услышите только негатив.
Если конфликтов не было — услышите что-то нейтральное или хорошее. Вменяемый руководитель не станет сор из избы выносить.
НЛО прилетело и опубликовало эту надпись здесь
Если конфликтов не было — услышите что-то нейтральное или хорошее.
Смотря какой задавать вопрос.
Самый главный вопрос, который надо всегда задать в процессе общения с предыдущим работодателем кандидата:
«Вы бы взяли его себе обратно на работу, при условии, что у вас бы нашлась для него работа?»
Если да — значит эффект в его работе был. Если нет — надо узнавать причину — возможно для вас это не проблема.
Вопрос этот нужно задавать после стандартных вопросов типа, как он работал, все ли было хорошо и т.п. Но ответы на них будут скорее всего социально приемлемыми. Поэтому их и надо сначала задавать, чтобы у предыдущего руководителя создалось ощущение, что он нормальный человек и зря никого не обижает.
А вот на вопрос о приеме обратно, как правило, отвечают более-менее честно. Тем более он явно не характеризует человека, он характеризует только отношение к нему работодателя.
Золотые слова, Юрий Бенедиктович!
Похоже, что автор рассматривает собеседование именно с точки зрения подбора «своих людей» в «свою команду». Но бизнес — это не ваше, и это даже не моё, это чужое. Просто совсем левое.
Поэтому не стоит давать советы бизнесу. Хотя пытаться влиять на принятие решений, выгодных грамотным специалистам, безусловно стоит. И да, вот такими статьями тоже. То есть неявно идёт банальная война за деньги и минимум напряжения между бизнесом и специалистами. Специалисты, вот как в данной статье, описывают своё видение, свои предпочтения, ну а бизнес почитывает и делает выводы. Или не делает, что случается чаще. Хотя дефицит кадров бизнес очень волнует, но ведь всегда есть очень простой способ — купить проджект манагера (начальника отдела или ещё как-то похоже) и свесить все остальные заботы на него. Особенно в больших конторах. И этот манагер уже будет дрючить испытуемых исходя из личного опыта, который, возможно, включает прочтение подобных статей. Но часто не включает. Просто потому, что реальность требует много дешёвых кодеров, ну а манагер вынужден это чутко улавливать. Вот и методы отбора у него вырабатываются соответствующие. И это уже не выбить из такой головы.
Поэтому я бы рекомендовал специалистам «познать цзен». То есть, имея опыт, вы легко отличите манагера от хорошего специалиста, либо мальчика-джуна, посланного вас собеседовать по техническим вопросам менее грамотными товарищами (включая сеньоров). Просто вспомните, как вы сами участвовали в подобных действах. Там всё тривиально — конторе нужен продукт, продукту нужны кодеры, манагер пинает HR, те присылают толпу, далее нужно отсеивать, но понятно, заниматься этим лень, поэтому и посылают начинающего, но умело отвечавшего на собеседовании на технические вопросы. Ну и начинающий затем выдаёт своё ценное мнение наверх, этому мнению наверху не верят, ибо знают, что начинающий, пишут соседям, мол побеседуйте тоже и т.д. В общем — типичная конторская деятельность по перепихиванию работы с себя на окружающих. И где в такой суете место грамотным вопросам? Правильно — нет его.
Бывают конторы, где специалистам верят, поскольку от них всё зависит, но и там «идеальный отбор» отсутствует. Если всем рулит тим-лид, то вышестоящий начальник свешивает всю процедуру на него, ну а он уже подбирает народ под себя. Не по знаниям, не по «полезности для команды», а именно под себя (можно считать, что по сути он думает «команда — это я»). Да, не все люди идеальны. Хороших спецов я на собеседованиях встречал немного. Бывали интересные люди, но всегда были некие манагеры, либо те же мальчики-джуны, либо ещё какие-то специфические условия.
Какой из этого вывод? Да просто расслабьтесь. Не нервничайте по поводу глупых вопросов и всего того, из-за чего вы привыкли нервничать. Ну да, мальчик-джун очень хочет проявить себя и задаёт вам олимпиадные задачки, про которые он где-то читал. Ну так что в этом плохого? Он и обязан это делать, просто в полном соответствии со своим неокрепшим разумом и недостаточным опытом. На что тут жаловаться? На то, что вы не можете вспомнить, какой метод нужно дёрнуть для решения поставленной джуном задачи? Ну так и скажите — я хочу поглядеть документацию по такому-то классу, и через 5 минут отвечу. Если вы боитесь, что джун потом напишет негативный отзыв — не стоит нервничать! Вышестоящий начальник хорошо понимает, кого и куда он послал, поэтому решать всё равно будет субъективно, лишь частично опираясь на отзыв джуна. То есть просто действуйте спокойно, как вы привыкли, и пусть джун под вас подстраивается и потом покрывается, когда вы ему возражаете. Ну ведь просто же!
Так что — расслабьтесь и не нервничайте. Но к собеседованиям, безусловно, готовьтесь. То есть если бы ко мне пришёл якобы сеньор, но поленившийся освежить в голове хотя бы основное по списку указанных в вакансии технологий — ну очевидно же, что он привык к лёгкой жизни на старом месте, не учил новые технологии, не готов банально почитать о том, чем придётся заниматься на новой работе. Именно поэтому возникает вопрос о его проф.пригодности. Не из-за каких-то субъективных факторов, а именно из-за неготовности чуть-чуть напрячься. Потому что новое место работы — это всегда некоторое напряжение, связанное с необходимостью учиться тому, чего на прошлой работе не было.
Но даже моё возражение в куче контор никак бы не повлияло на субъективный выбор кем-то другим, так что опять же — расслабьтесь, не нервничайте, не попали в одну контору — попадёте в другую. А все эти собеседования — субъективная суета. Напрягают лишь если буквально жрать нечего, потому что денег нет. А во всех остальных случаях — не парьтесь. Но только при условии, что вы реально способны учиться и реально обладаете ценными опытом и знаниями.
Поэтому не стоит давать советы бизнесу. Хотя пытаться влиять на принятие решений, выгодных грамотным специалистам, безусловно стоит. И да, вот такими статьями тоже. То есть неявно идёт банальная война за деньги и минимум напряжения между бизнесом и специалистами. Специалисты, вот как в данной статье, описывают своё видение, свои предпочтения, ну а бизнес почитывает и делает выводы. Или не делает, что случается чаще. Хотя дефицит кадров бизнес очень волнует, но ведь всегда есть очень простой способ — купить проджект манагера (начальника отдела или ещё как-то похоже) и свесить все остальные заботы на него. Особенно в больших конторах. И этот манагер уже будет дрючить испытуемых исходя из личного опыта, который, возможно, включает прочтение подобных статей. Но часто не включает. Просто потому, что реальность требует много дешёвых кодеров, ну а манагер вынужден это чутко улавливать. Вот и методы отбора у него вырабатываются соответствующие. И это уже не выбить из такой головы.
Поэтому я бы рекомендовал специалистам «познать цзен». То есть, имея опыт, вы легко отличите манагера от хорошего специалиста, либо мальчика-джуна, посланного вас собеседовать по техническим вопросам менее грамотными товарищами (включая сеньоров). Просто вспомните, как вы сами участвовали в подобных действах. Там всё тривиально — конторе нужен продукт, продукту нужны кодеры, манагер пинает HR, те присылают толпу, далее нужно отсеивать, но понятно, заниматься этим лень, поэтому и посылают начинающего, но умело отвечавшего на собеседовании на технические вопросы. Ну и начинающий затем выдаёт своё ценное мнение наверх, этому мнению наверху не верят, ибо знают, что начинающий, пишут соседям, мол побеседуйте тоже и т.д. В общем — типичная конторская деятельность по перепихиванию работы с себя на окружающих. И где в такой суете место грамотным вопросам? Правильно — нет его.
Бывают конторы, где специалистам верят, поскольку от них всё зависит, но и там «идеальный отбор» отсутствует. Если всем рулит тим-лид, то вышестоящий начальник свешивает всю процедуру на него, ну а он уже подбирает народ под себя. Не по знаниям, не по «полезности для команды», а именно под себя (можно считать, что по сути он думает «команда — это я»). Да, не все люди идеальны. Хороших спецов я на собеседованиях встречал немного. Бывали интересные люди, но всегда были некие манагеры, либо те же мальчики-джуны, либо ещё какие-то специфические условия.
Какой из этого вывод? Да просто расслабьтесь. Не нервничайте по поводу глупых вопросов и всего того, из-за чего вы привыкли нервничать. Ну да, мальчик-джун очень хочет проявить себя и задаёт вам олимпиадные задачки, про которые он где-то читал. Ну так что в этом плохого? Он и обязан это делать, просто в полном соответствии со своим неокрепшим разумом и недостаточным опытом. На что тут жаловаться? На то, что вы не можете вспомнить, какой метод нужно дёрнуть для решения поставленной джуном задачи? Ну так и скажите — я хочу поглядеть документацию по такому-то классу, и через 5 минут отвечу. Если вы боитесь, что джун потом напишет негативный отзыв — не стоит нервничать! Вышестоящий начальник хорошо понимает, кого и куда он послал, поэтому решать всё равно будет субъективно, лишь частично опираясь на отзыв джуна. То есть просто действуйте спокойно, как вы привыкли, и пусть джун под вас подстраивается и потом покрывается, когда вы ему возражаете. Ну ведь просто же!
Так что — расслабьтесь и не нервничайте. Но к собеседованиям, безусловно, готовьтесь. То есть если бы ко мне пришёл якобы сеньор, но поленившийся освежить в голове хотя бы основное по списку указанных в вакансии технологий — ну очевидно же, что он привык к лёгкой жизни на старом месте, не учил новые технологии, не готов банально почитать о том, чем придётся заниматься на новой работе. Именно поэтому возникает вопрос о его проф.пригодности. Не из-за каких-то субъективных факторов, а именно из-за неготовности чуть-чуть напрячься. Потому что новое место работы — это всегда некоторое напряжение, связанное с необходимостью учиться тому, чего на прошлой работе не было.
Но даже моё возражение в куче контор никак бы не повлияло на субъективный выбор кем-то другим, так что опять же — расслабьтесь, не нервничайте, не попали в одну контору — попадёте в другую. А все эти собеседования — субъективная суета. Напрягают лишь если буквально жрать нечего, потому что денег нет. А во всех остальных случаях — не парьтесь. Но только при условии, что вы реально способны учиться и реально обладаете ценными опытом и знаниями.
В кои то веки отличная статья про хайринг. Согласен почти со всем изложеным. Единственное замечание — кто-то из технарей в собеседовании все-таки должен учавствовать.
На сегодняшний день, понятие «рыночная стоимость» очень размыто, точнее не катируется среди многих разработчиков, т.к. в одном месте дают 2 яблока, а в другом 5… и это колличество часто никак не сходится с рыночными показателями.
В связи с отсутствием необходимого количества кандидатур, пункт «Насколько желаемая зп соответствует вышеуказанным пунктам» становится очень критичным.
Конечно же понятно, что бюджет на позицию ограничен, но порой будет больше толка от мидла с зарплатой сениора, чем будешь ждать подходящего сениора на белом коне — это как пример.
Как Вы/вы считаете?
Что говорит практика?
В связи с отсутствием необходимого количества кандидатур, пункт «Насколько желаемая зп соответствует вышеуказанным пунктам» становится очень критичным.
Конечно же понятно, что бюджет на позицию ограничен, но порой будет больше толка от мидла с зарплатой сениора, чем будешь ждать подходящего сениора на белом коне — это как пример.
Как Вы/вы считаете?
Что говорит практика?
Это отдельная история — как нанять толкового сеньора, если бюджет ограничен.
«Рыночная стоимость» определяется весьма просто — можете поинтересоваться у хедхантинговых агентств, за сколько набирали до Вас. Можете посмотреть в HH, сколько примерно предлагают. Также, первые же кандидаты Вам сами подскажут примерный рынок.
Если Вы предлагаете зп по рынку — вероятность взять толкового сеньора весьма невелика, можно ждать месяцами. Если дать +10% к рынку — шансы увеличиваются, но скорей всего Ваш оффер будет использован сеньором на текущем месте работы для повышения зп.
Поэтому надо предлагать что-то большее, возможно, не только материальные блага.
Сейчас весьма распространен подход набора на удаленку, так как это сильно расширяет аудиторию и упрощает найм. Также нередко сотрудничают с бодишопами просто арендуя у них спецов.
«Рыночная стоимость» определяется весьма просто — можете поинтересоваться у хедхантинговых агентств, за сколько набирали до Вас. Можете посмотреть в HH, сколько примерно предлагают. Также, первые же кандидаты Вам сами подскажут примерный рынок.
Если Вы предлагаете зп по рынку — вероятность взять толкового сеньора весьма невелика, можно ждать месяцами. Если дать +10% к рынку — шансы увеличиваются, но скорей всего Ваш оффер будет использован сеньором на текущем месте работы для повышения зп.
Поэтому надо предлагать что-то большее, возможно, не только материальные блага.
Сейчас весьма распространен подход набора на удаленку, так как это сильно расширяет аудиторию и упрощает найм. Также нередко сотрудничают с бодишопами просто арендуя у них спецов.
а вот меня прям недавно спросили про методы у Object
правда там и ещё было умных вопросов, но вот этот запомнился…
а года 4 назад поинтересовались как перевозить какое-то зверьё в темноте через мост в лодке с фонариком и батарейки кончаются и река горит и вообще апокалипсис.
правда там и ещё было умных вопросов, но вот этот запомнился…
а года 4 назад поинтересовались как перевозить какое-то зверьё в темноте через мост в лодке с фонариком и батарейки кончаются и река горит и вообще апокалипсис.
зверьё в темноте через мост в лодке с фонариком и батарейки кончаются и река горит и вообще апокалипсис
Я даже боюсь представить, под какими препаратами это придумывалось и зачем им тут разработчик. Тут психиатр нужен.
думаю это была такая задача:
petruchek.info/problems/night-bridge-flashlight.html
там потом выяснилось что отпуск надо планировать за год, и всё такое, приходить к 9 утра, в общем не сложилось с ними, хотя 150тыр 5 лет назад было неплохо конечно…
petruchek.info/problems/night-bridge-flashlight.html
там потом выяснилось что отпуск надо планировать за год, и всё такое, приходить к 9 утра, в общем не сложилось с ними, хотя 150тыр 5 лет назад было неплохо конечно…
Меня как-то раз один умник спросил про теорему Чёрча-Росса про ламбда исчисление. После этого забил на всякие интервью и начал делать свой проект, чтобы никому ничего не доказывать.
про кубик-рубик зачет! никогда не понимал такого. я будут тестером головоломок или сениор девелопером? как это умение поможет мне как-то в работе?
возвращаясь к кубику Рубика. у нас с сестрой в детстве был такой способ его сборки: после 1-2 ударов им об стену, у него выпадывал угол, после чего его можно было разобрать и вставить правильно все цвета. данная операция занимала несколько минут. то же самое с пирамидкой, но там выбить компонент было сложнее.
возвращаясь к кубику Рубика. у нас с сестрой в детстве был такой способ его сборки: после 1-2 ударов им об стену, у него выпадывал угол, после чего его можно было разобрать и вставить правильно все цвета. данная операция занимала несколько минут. то же самое с пирамидкой, но там выбить компонент было сложнее.
Наиболее вменяемое что попадалось здесь по теме. Но про полдня кодинга в офисе, на мой взгляд тоже мимо. В специфику ваших задать въехать не успеет, а что то другое, тоже тестовое, только в стрессовом состоянии.
На мой взгляд решение — только под ответственность тимлида (они должны быть на одной волне) и чётко оговоренный испытательный срок.
Полдня кодинга в офисе вполне могут включать в себя вариант парного программирования, чтобы понять, как человек ведет разработку. Здесь смысл — не закодить что-то, а продемонстрировать владение навыками разработки на уровне Senior, чтобы потом тимлиду не было мучительно больно за принятое решение. Можно даже без непосредственного кодирования, а просто взять какой-нибудь код и послушать кандидата, что в нем плохо, что хорошо, что стоит переделать и как.
Ну не знаю, я вот сам никогда не применял нигде парного программирования. Если я приду на собеседование и ко мне подсядет чувак, который будет меня палить, то мне будет как-то не по себе… почему так — часто, когда решаешь задачу, то сначала пишешь код который минут через 30 возможно придётся переписать. Но со смотрящим рядом ведь хочется не ударить в грязь лицом и из-за этого будет сильный дискомфорт. Разве нет?
>> Тут могут быть другие варианты в других языках — то, что хорошо знает собеседующий.
А вот это как раз вкорне неверно и очень даже вредно спрашивать то, в чем Вы сами хорошо разбираетесь и на данный момент в контексте.
Ну вот разобрался я на последней неделе в библиотеке какой-то, держу в голове часть документации и не лезу раз за разом в гугл. С какой стати собеседуемый должен держать в голове то же самое?
А вот это как раз вкорне неверно и очень даже вредно спрашивать то, в чем Вы сами хорошо разбираетесь и на данный момент в контексте.
Ну вот разобрался я на последней неделе в библиотеке какой-то, держу в голове часть документации и не лезу раз за разом в гугл. С какой стати собеседуемый должен держать в голове то же самое?
Первый раз вижу настолько хорошую статью о себеседовании.
Senior, которого прет от работы и которому нужны интересные задачи, а не деньги — это, конечно, очень ценный кадр, но, боюсь, в природе он встречается не часто.
Проблема в том, что интересных задач обычно мало, а рутины много. И сложную рутину тоже надо кому-то делать, спихнуть всё на низовой состав нереально. Поэтому senior со временем привыкает к тому, что интересные задачи приходят и уходят, а деньги — штука хорошая и их платят за разную работу, в том числе и не очень то интересную. Другое дело, что если процент неинтересной работы на конкретном месте начинает зашкаливать, senior это терпеть не будет даже ради денег. )
Проблема в том, что интересных задач обычно мало, а рутины много. И сложную рутину тоже надо кому-то делать, спихнуть всё на низовой состав нереально. Поэтому senior со временем привыкает к тому, что интересные задачи приходят и уходят, а деньги — штука хорошая и их платят за разную работу, в том числе и не очень то интересную. Другое дело, что если процент неинтересной работы на конкретном месте начинает зашкаливать, senior это терпеть не будет даже ради денег. )
НЛО прилетело и опубликовало эту надпись здесь
Я таких людей не встречал — с одинаковой производительностью. Возможно Вам повезло больше, не исключаю.
Не, про одинаковую производительность я не говорил. Просто сеньор уже пожил и понимает, что рутиной тоже надо заниматься, даже если очень не хочется. И он занимается. Не так, чтобы прям с песнями, но куда деваться.
Часто за неинтересные задачи платят сильно больше именно поэтому. Например — кто-то видел хоть одну систему без отчетности? Не самая интересная работа, казалось бы, а на рынке-то не протолкнуться от конкурирующих продуктов.
А насчёт быстрого освоения — всё верно. Меня на нынешнюю работу взяли не смотря на то, что я не знал async/await, а он тут был нужен. Освоил это дело за несколько дней и активно стал применять. Никаких проблем. Внутренне был готов к концепции, просто не было надобности ранее. Как столкнулся — легко изучил.
Зачем спрашивать про алгоритмы? Каждое мое собеседование меня спрашивали алгоритмы. Но за 10 лет работы разработчиком я ни разу не применил эти знания.
Если Вы имеете ввиду какую-нибудь классику из кнутовской серии, то это крайне редко нужно на практике. Под алгоритмами на собеседовании подразумевается насколько эффективно разработчик воплощает задачу в коде. Это нужно для того, чтобы понять, являются ли алгоритмы его сильной стороной или нет.
И зачастую на собеседования «сами знаете куда» дают олимпиадные или около задачки. На основании которых определяют человек умеет или не умеет в алгоритмы.
А я рад был бы увидеть примеры алгоритмических, но не олимпиадных задач, которые могут показать, что разработчик справится с алгоритмами для средних задач в жизни. Есть примеры?
А я рад был бы увидеть примеры алгоритмических, но не олимпиадных задач, которые могут показать, что разработчик справится с алгоритмами для средних задач в жизни. Есть примеры?
Проверка строки на палиндром: leetcode.com/problems/valid-palindrome
Слияние связных списков: 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!
Слияние связных списков: 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 и ответ без преобразования отправил дальше — то никак не соотносится, разумеется.
Слияние связных списков или массивов — вот для него сложнее всего подобрать пример. Надо подумать еще.
Идентичность бинарного дерева — по сути кастомный equals для объектов со сложной структурой.
Join по ID — стандартная задача по построению некой модельки, по которой будет рендерится отображение, на основании данных из двух или более источников. В наш век микросервисной архитектуры вполне себе частая история должна быть.
Тут еще стоит уточнить, что подразумевать под бизнес задачами.
Если это только вызвал API и ответ без преобразования отправил дальше — то никак не соотносится, разумеется.
Так как налить ровно 4 литра при вёдрах 3 и 5 ?
Пусть, в3 — ведро 3л, в5 — ведро 5л
1) Наливаем в в3 и выливаем в в5
2) Наливаем еще в в3 и выливаем в в5 пока не заполнится. В в3 остается 1л.
3) Опустошаем в5 и переливаем туда 1л из в3
4) Наливаем в в3 3л и выливаем это в в5 с 1 л, получаем 4л.
p.s. сори если это был сарказм и я не в тему, просто пролистал комменты до конца и ваш был последний
1) Наливаем в в3 и выливаем в в5
2) Наливаем еще в в3 и выливаем в в5 пока не заполнится. В в3 остается 1л.
3) Опустошаем в5 и переливаем туда 1л из в3
4) Наливаем в в3 3л и выливаем это в в5 с 1 л, получаем 4л.
p.s. сори если это был сарказм и я не в тему, просто пролистал комменты до конца и ваш был последний
А не проще ли налить по полведра? 2.5+1.5=4, это если конечно возможно «половину» определить.
Понятно. Не подумал что можно просто вылить из ведра на землю. Думал, что уже налитое можно переливать только между ведрами
вариант
Задача получения 1л решена.
Оформляем результат решения задачи в виде функции.
Выливаем отладочный результат 1л из в3.
Для в5, вызываем функцию получения 1л, 4 раза в цикле последовательно или в 4 параллельных потоках.
Пусть, в3 — ведро 3л, в5 — ведро 5л
1) Наливаем в в3 и выливаем в в5
2) Наливаем еще в в3 и выливаем в в5 пока не заполнится. В в3 остается 1л.
Задача получения 1л решена.
Оформляем результат решения задачи в виде функции.
Выливаем отладочный результат 1л из в3.
Для в5, вызываем функцию получения 1л, 4 раза в цикле последовательно или в 4 параллельных потоках.
У вас получилось восемь этапов, если разделить на отдельные действия.
Задача решается за шесть)
Задача решается за шесть)
решение
1) наливаем в в5
2) переливаем из в5 в в3 сколько влезет(в в5 остаётся 2л)
3) выливаем в3
4) переливаем из в5 в в3 2л
5) наливаем в в5
6) переливаем из в5 в в3 сколько влезет (1л), в в5 осталось 4л.
2) переливаем из в5 в в3 сколько влезет(в в5 остаётся 2л)
3) выливаем в3
4) переливаем из в5 в в3 2л
5) наливаем в в5
6) переливаем из в5 в в3 сколько влезет (1л), в в5 осталось 4л.
Вот к слову, хороший пример. Есть два человека, один решил эту задачу за 8 шагов, другой за 6.
Можно ли сказать, что последний будет работать эффективней на 25%? Нет.
Можно ли сказать, что последний умней на 25%? Тоже нет.
Таким образом, польза от подобных единичных задач неочевидна. Для каких-то корректных выводов таких задач нужно дать минимум сотню.
Можно ли сказать, что последний будет работать эффективней на 25%? Нет.
Можно ли сказать, что последний умней на 25%? Тоже нет.
Таким образом, польза от подобных единичных задач неочевидна. Для каких-то корректных выводов таких задач нужно дать минимум сотню.
Я провел не одну сотню собеседований как с одной стороны, так и с другой.А когда вы работать-то успеваете? «Собеседование» (job interview) со стороны нанимающегося на работу длится от 4 до 8 часов, «не одна сотня» (допустим, две сотни) займет у вас 6 * 200 = 1200 часов, т.е. практически два месяца рабочего времени.
например — полдня кодинга непосредственно в компании, оплаченные по средней ставкеЭто ваша юношеская мечта, что-ли? По какой статье расходов будете проводить оплату в бухгалтерии? ;)
1) Классическое собеседование длится не больше часа. Иногда меньше, иногда больше.
2) Вопрос оплаты в нормальных конторах проблемой не является.
2) Вопрос оплаты в нормальных конторах проблемой не является.
1) Не знаю, что такое «классическое собеседование» (это, что-ли, как Сократ Платона в ученики собеседовал?), но обычно час длится для интервьюера, но отнюдь не для интервьюируемого. Самое короткое собеседование в моей, не выдуманной ради красного словца, а реальной, 30-летней карьере (из них 23 года в Штатах), длилось примерно полтора часа (из них час ушел на совместную отладку с software architect-ом предложенного мною неожиданного решения задачи), а самое длинное, что могу припомнить, 8 часов (с часовым перерывом на ланч) в Amazon-е.
2) Вы как-нибудь все-таки у бухгалтера сначала поинтересуйтесь, прежде, чем чушь писать. И дело вовсе не в наличии или отсутствии у «конторы» денег.
2) Вы как-нибудь все-таки у бухгалтера сначала поинтересуйтесь, прежде, чем чушь писать. И дело вовсе не в наличии или отсутствии у «конторы» денег.
Ххе, по этой статье я типичный креативщик-заложник настроения, видимо из-за этого мне хреново работается по аджайлу, когда до дедлайна много времени и никто у меня над душой не стоит, я хорошо работаю в своем рваном ритме (то много то ничего) и все успеваю, а постоянная рутина со всеми этими спринтами и каждодневными отчетами меня в тоску вгоняет, чувствую себя как заключенный под присмотром.
Статья очень понравилась. Согласен практически со всеми пунктами.
Если автору будет интересно описать метаморфозы сеньора девелопера, происходящие с ним по мере старения, то с удовольствием прочитаю.
Если автору будет интересно описать метаморфозы сеньора девелопера, происходящие с ним по мере старения, то с удовольствием прочитаю.
НЛО прилетело и опубликовало эту надпись здесь
Хороший вопрос.
Чем старее разработчик — тем более консервативен он становится. Вплоть до полного отрицания новых технологий, особенно, если старый стек до сих пор востребован(например, Java 7-8). Плюсом такой консервативности можно считать то, что в старом стеке он плавает как рыба в воде.
Еще минус возраста то — что тимлиды моложе их встречаются чаще, иногда существенно моложе. Для тимлида 30 лет морально тяжело работать с разработчиком 45 лет, а разработчик с высоты своего опыта и возраста старается давить на него, что вызывает дискомфорт в отношениях. Поэтому старички-разработчики обычно мигрируют в Enterprise и там вполне комфортно себя чувствуют до пенсии.
Чем старее разработчик — тем более консервативен он становится. Вплоть до полного отрицания новых технологий, особенно, если старый стек до сих пор востребован(например, Java 7-8). Плюсом такой консервативности можно считать то, что в старом стеке он плавает как рыба в воде.
Еще минус возраста то — что тимлиды моложе их встречаются чаще, иногда существенно моложе. Для тимлида 30 лет морально тяжело работать с разработчиком 45 лет, а разработчик с высоты своего опыта и возраста старается давить на него, что вызывает дискомфорт в отношениях. Поэтому старички-разработчики обычно мигрируют в Enterprise и там вполне комфортно себя чувствуют до пенсии.
Напомнило об очень интересной статье от одного из менеджеров в microsoft о том, как они поменяли процесс собеседования:
blog.usejournal.com/rethinking-how-we-interview-in-microsofts-developer-division-8f404cfd075a
tl;dr: вместо шаблонных вопросов решают вместе с кандидатом реальную задачу во всей её полноте, начиная с работы с требованиями и т.п.
Лично мне такой подход крайне импонирует и, думаю, даже провал такого собеседования будет ощущаться лучше т.к. человек сам увидит, что не справился, не разобрался, etc и как минимум получит полезный опыт. Куда полезнее заучивания всех «принципов ООП».
blog.usejournal.com/rethinking-how-we-interview-in-microsofts-developer-division-8f404cfd075a
tl;dr: вместо шаблонных вопросов решают вместе с кандидатом реальную задачу во всей её полноте, начиная с работы с требованиями и т.п.
Лично мне такой подход крайне импонирует и, думаю, даже провал такого собеседования будет ощущаться лучше т.к. человек сам увидит, что не справился, не разобрался, etc и как минимум получит полезный опыт. Куда полезнее заучивания всех «принципов ООП».
А какие у вас появляются дополнительные требования, если вы ищите Lead developer, а не Senior developer?
Lead — это фактически маленький тимлид, то бишь есть некоторые разработчики(часто — middle или junior), для которых он мининачальник. Если вкратце — то лиду нужны навыки менеджерства, наставничества, педагогики. Соответствующие вопросы и надо задавать для их выявления. Если же в подчинении у него нет разработчиков, то по факту — это продвинутый Senior и требования к нему те же, что и к обычному.
Относительно недавно проходил собес как раз на сеньора.
Из краткого: закидали терминологией (solid, dry, kiss, di, инкапсуляция и т.п.) из "умных" слов. Сразу сказал что у меня теория хромает, зато на практике реально много чего могу. Как ещё не спросили "что такое ООП"…
В сумме около трёх часов разговаривали (так получилось).
Дали тестовое. Сделал чтоб не стыдно было. Сказали "офигеть как шикарно", но на работу не позвали.
При этом, с девчонкой HR неплохо поболтали.
Ну, нет так нет.
На другом собесе задачу дали на листочке написать:
Не используя условные операторы при передаче в функцию числа "1" вернуть "2", а при передаче "2" — вернуть "1".
Я с такими задачами не сталкивался и честно пытался решить около пяти минут — не смог. Зато придя домой всего за 15 секунд написал рабочее решение не открывая Гугла:
function get($num)
{
return ($num | 2) — 1;
}
Спасибо большое за пост. Очень грамотная и систематизация и полезные акценты.
Хотел бы добавить вам в копилку пару идей из своей практики…
Как известно, правильно поставленный вопрос — это половина решения проблемы. Поэтому люди, умеющие задавать правильные вопросы, как правило, и хорошо умеют эти проблемы решать. Если есть желание и возможность — попробуйте «собеседование наоборот»: пусть кандидат экспромтом попробует вас самих взять на работу:) Ну, во всяком случае, это может быть весело. Как минимум, нестандартность приёма иногда позволяет снимать стресс…
И ещё не стоит сбрасывать со счетов «любителей дурацких вопросов»...99% из них и вправду дурацкие, т.к. ответы на них не говорят ровным счётом ничего полезного. Тем не менее, если привлечь на помощь научно обоснованные достижения современной психологии, то кой-какие полезности из их арсенала вполне можно использовать… Например, такие вот простенькие тесты «на когнитивное отражение». Обоснование зачем это и почему может быть полезно популярно рассказано вот тут.
Хотел бы добавить вам в копилку пару идей из своей практики…
Как известно, правильно поставленный вопрос — это половина решения проблемы. Поэтому люди, умеющие задавать правильные вопросы, как правило, и хорошо умеют эти проблемы решать. Если есть желание и возможность — попробуйте «собеседование наоборот»: пусть кандидат экспромтом попробует вас самих взять на работу:) Ну, во всяком случае, это может быть весело. Как минимум, нестандартность приёма иногда позволяет снимать стресс…
И ещё не стоит сбрасывать со счетов «любителей дурацких вопросов»...99% из них и вправду дурацкие, т.к. ответы на них не говорят ровным счётом ничего полезного. Тем не менее, если привлечь на помощь научно обоснованные достижения современной психологии, то кой-какие полезности из их арсенала вполне можно использовать… Например, такие вот простенькие тесты «на когнитивное отражение». Обоснование зачем это и почему может быть полезно популярно рассказано вот тут.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Собеседуем кандидата на должность Senior Software Developer