Найм программистов. Советы от программиста
Рассекая просторы vc.ru, уже несколько раз натыкался на материалы о найме программистов и не без интереса читал их, ведь я сам программист, и мне любопытно было узнать, как нас оценивают на собеседованиях.
Мои впечатления? Я в печали... Почти все материалы, на мой взгляд, напоминают «вредные советы».
В особенности «порадовала» последняя прочитанная статья: «25 классических вопросов, которые HR-ы задают программистам на собеседованиях» ( ссылка ), после прочтения которой и возникло желание написать данный материал.
Сразу оговорюсь, вся статья — это сугубо личное мнение, однако нашедшее поддержку в лице друзей и коллег программистов.
Итак...
Первая встреча, собеседование без тех специалиста
HR-ы, не обманывайте себя. Вы никогда не поймёте на сколько хорош программист…
Разве что только когда сможете воткнуть электроды ему в ухо и запустить end-to-end теститрование. Но пока таких технологий нет, всё что Вы можете оценить — это адекватность и, хотя бы отчасти, мотивацию человека сидящего перед Вами.
И поверьте, этого достаточно.
Ведь Ваша задача найти человека, который сможет влиться в коллектив, плодотворно в нём работать и чтобы его работа вознаграждалась тем способом, который он ожидает, и который может обеспечить Ваша компания(деньги, признание, интересные проекты и т.д.).
Все попытки спрашивать какие то технические нюансы будут выглядеть неуместно и беспомощно. Лично меня очень сильно раздражает, когда меня спрашиваю о том, в чем сами не разбираются. Хочется просто встать и уйти.
Что ещё можно спросить на первом этапе? Зависит от специфики вакансии.
Если Вам нужен опытный человек — спрашивайте об опыте, узнавайте какие задачи он решал, какие трудности преодолевал.
Если Вам нужен человек, которого можно обучить, дайте ему пару логических задачек, проверьте живость ума.
Собранной на первом этапе информации хватит чтобы отсеять 80% - 90% кандидатов.
Часть вторая. Собеседование с тех специалистом
НЕ НАДО СПРАШИВАТЬ ТЕОРИЮ!
Пожалуйста, великие гуру найма и технари, любящие спрашивать теорию, объясните мне в комментариях в чем смысл Ваших вопросов?
По моему, если ответ на Ваш вопрос лежит по первой ссылке в гугле, то спрашивать его не имеет смысла. Разве что Вы ищите человека на закрытый объект, где нет доступа в интернет. Но в остальных случая — Я считаю теоретические вопросы пустой тратой времени, которая ничем Вам, как работодателю, не поможет.
Я лично знаю несколько человек, которые учились со мной на программистов. У них от зубов отскакивали все теоретические выкладки, но когда дело доходило до реального программирования — ничего путного они сделать не могли.
Также негодование вызывают вопросы, которые возможно и касаются будущей работы, но разобраться в которых не составляет труда. Например «юнит-тесты». Чтобы научиться писать юнит-тесты уйдёт от силы минут 10.
Прошу обратить внимание, более сложные тесты уже относятся к вопросам об опыте, о которых далее.
Что же, по моему, нужно спрашивать у кандидата?
Спрашивайте технические нюансы из их предыдущего опыта, особенно те, которые пересекаются с будущей работой.
По тому, как человек рассказывает, будет понятно:
- Реально ли он разбирается в вопросе или просто придумал эти пункты для набивания себе цены.
- На сколько его опыт и знания подходят для текущей вакансии.
- Сможет ли он справиться с будущей работой.
- Сможет ли он научиться, если не имеет подобного опыта.
И, как мне кажется, этого достаточно, чтобы сделать финальный выбор.
Больше о человеке Вы сможете узнать только на испытательном сроке.
Для дискуссий приглашаю в комментарии.
Надеюсь данный материал будет хоть кому-то полезен, спасибо за внимание.
И ради бога(любого), отъебитесь от вышки, не панацея это, столько хороших самоучек отсеиваете...
Я всегда facepalm от таких пацанов. "Я программист, бог, Вам не дано понять всей глубины моего величия, никто ниже senior developer не имеет права меня о чем-то спрашивать. Можете попросить разрешения мне отсосать. Это смешно." В 90% случаев там нет никаких суперзнаний и супертехнологий. Ничего, что не учится за полгода - год. Полное не понимание что важно, что нет и как все это работает. А еще в 100% случаев там убогие, кривые паттерны и приемы работы, от которых этих самородков не отучить без лоботомии. Неумение заткнуться и слушать, учиться и делать. Самомнение и тупые идеи как у семикласников. Как будто с 15 до 25 лет эти люди в в каком-то подростковом стазисе. Да иногда проще домохозяйку натаскать, чем этакого мамкиного гения.
Дипломы обычно нужны компаниям, которые в тендерах участвуют.
По крайней мере в Казахстане в требованиях к тендеру обычно прописано количество "дипломированных специалистов", требуемое для данного проекта.
Это, по моему, единственное более менее логичное объяснение требованиям о высшем образовании.
что, серьёзно при наличии опыта требуют диплом? huawei research не требовал ))))
Комментарий недоступен
Как показывает практика реального найма со стороны собеседующих: наличие высшего образования хорошо коррелирует с адекватностью кандидата.
Комментарий удален модератором
Т.е. чувак не осилил вышку, но небесно умен и крут?
Вышка - это показатель вообще способности человека к нудной и трудной работе. Не закончить вуз могут позволить себе только люди, которые во время обучения построили свой бизнес. Ну Скаенг, например. Но если ты идешь наемным работником, и при этом ты не справился с вузом, ну еклмн, дефицит кадров, конечно, но скорее нет.
Самоучка самоучке рознь.
С другой стороны высшее образование более консервативно и новые технологии все равно придется осваивать самостоятельно.
Вообще про образование спрашиваю на собеседовании только в контексте учится / не учится - будет ли что-то отвлекать от работы или нет )
Уже выше сказали про тендеры, но это не единственная причина. Еще есть инерция.
Руководству в крупных компаниях (а это в основном "рождённые в СССР" мужики за 40 и такие же дамы) просто ментально трудно понять и принять то что мир изменился, и сегодня чтобы приобрести знания, особенно - в программировании, вовсе не обязательно ходить на пары годами и скрести книжки в библиотеке. В их-то время такой альтернативы не было, т.к .не было интернета.
Комментарий удален модератором
Комментарий недоступен
И? Есть великая разница отсортировать список в 10 элементов пузырьком или быстрой сортировкой?
Без понимания того, сколько у нас данных, дрочить на сложность алгоритмов нет смысла.
Мудаком будет уже априори из-за написания велосипеда.
Теория бывает разная,
Черная и красная,
Ветвистая, дейкстристая
Иль НАХЕР НЕ ОБОСРАВШАЯСЯ.
Думаю имелось ввиду, что уметь в оценку сложности нужно, а вот знать наизусть все алгоритмы сортировки/поиска/впишичтонибудьсюда или нюансы разных методологий или точных определений понятий из CS не имеет смысла, т.к. в реальности дешевле и проще взять либо готовое решение, либо подсмотреть в тот же гугл или справочник.
И вообще всем свойственно ошибаться и выбирать неверное решение, почему это должно делать человека мудаком? Мудаки как раз такие люди как вы, Дмитрий, если не можете объяснить, показать, научить, а автоматом ставите ярлыки.
Такой мудак отсеивается через месяц работы. Зато прогнать после "теоретического" собеседования можно с десяток хороших.
Тут был комментарий, который я заменил на фразу, которая ничего не значит, и за это я получаю минусы, довольно справедливо, спасибо всем
Можете привести конкретный пример задачи? Мне для собственного саморазвития интересно
Ещё тестовые задания! Они еще не решили нужен ли им специалист но дура-HR уже присылает ТЗ в виде скана огрызка набросанного при сидении на унитазе их главным по dev. :)
Комментарий недоступен
Вопрос к создателю ресурса - вас атакуют ботами или вы их для повышения престижа ресурса сами держите? Я прочел больше десяти комментариев и ни один не совпадает с контекстом. Они все очень рядом, но не один не уловил смысл вопроса.На такое только боты способны.
Будьте так добры озвучить сам вопрос.
Слава великому Мао!
Константин, кем вы видите себя через 5 лет?
На собеседовании Я на этот вопрос отвечал вопросом:
- чем Вам эта информация поможет?
Адекватного ответа Я не получал.
Я даже на год вперед четко спланировать не могу, потому что сейчас время такое, неизвестно что с страной станет, не то что с отдельно взятым гражданином.
Кризисы, ху#зисы. Я сосредоточен на текущем моменте и ближайшем будущем.
Комментарий удален модератором
да нормальный вопрос на самом деле.
обычно у людей нет такого плана, но ИНОГДА он есть :) вот тогда его интересно послушать :)
хотя к найму это конечно имеет мало отношения :)
Комментарий удален модератором
Вот такие ребята в школах одни пятерки получали, хотя были не умнее других, просто грамотно продавались.
Уж поверьте, проходить интервью Я умею. Мило улыбаться, отвечать на абсурдные вопросы и казаться "самым лучшим кандидатом".
Статья для работодателей, которые хотят нанять подходящего человека с большей вероятностью, чем при обычном подходе к собеседованию.
Ну-ну. Вставайте и уходите, если эти людишки не удовлетворяют вашим ожиданиям )))Ситуация на рынке такова, что так и происходило. Я вставал и уходил. И ничего, работу нашёл и очень доволен ей.
Если Вы не можете диктовать работодателю свои требования - нарабатывайте опыт, чтобы Вас пытались заманить, чтобы не приходилось играть по чужим правилам.
"Я сам работаю в сауне. Проходил пару десятков интервью, и с уборщицами, и с банщиками и с такими же как я обычными работягами.
Статья смешная Детская и наивная. Она примерно на тему: "Как бы я хотел, чтобы меня оценивали". Ну-ну. Вставайте и уходите, если эти людишки не удовлетворяют вашим ожиданиям )))
А я буду клиентоориентированным. Буду отвечать на все вопросы потенциальных хозяев, чтобы помочь им. Буду рассказывать теорию, всё, что знаю про технику предварительного массажа и чем отличаются ароматные масла от обычных. Вообще, в момент трудоустройства засуну всю свою гордыню в задницу. Потому, что:
1. Я продаюсь! В полном смысле этого слова. В этот момент я играю по ИХ правилам. Свои я буду устанавливать чуть позже, уже после того как клиент закончит.
2. Мир неидеален, и наполнен неидеальными людьми, я им сейчас помогу, они мне потом сигаретку дадут."
Хороший программист full-stack быть не может.
абсолютно верно. хотя самый важный момент - не учи учёного. тебя ведь директор не учит как тебе писать код? вот и ты не учи медежмент как нанимать людей
другое дело что автор сам прогнал через собесы 200 человек и нанял 10. но видно ему везло или тылы ему прикрывали просто )))
Проблема не в том, насколько сложно нагуглить ответ на вопрос. Проблема в том, чтобы разработчик в принципе знал, что ему надо что-то гуглить.
Это принципиальная разница между known unknowns и unknown unknowns, которую никак, кроме реальным знанием теории, не решить.
Приведу цитату известного физика Ричарда Фейнмана из его книги. Он записался на курс для выпускников по биологии и подготовил доклад:
«Когда пришло время делать доклад по этому предмету, я для начала изобразил очертание кошки и принялся называть различные мускулы.
Другие студенты в аудитории перебили меня: "Мы знаем все это!"
- О, вы знаете? Тогда не удивительно, что я могу догнать вас так быстро после четырех лет занятий биологией. - Они тратили все свое время на запоминание ерунды вроде этой, когда это можно было бы посмотреть за 15 минут. »
у меня была история, когда я слышал что коды рида-соломона можно реализовать через FFT, но долго не понимал - как? прорыв случился когда я в кормене прочёл, что fft/ifft позволяют сделать интерполяцию/вычисление многочлена, а уж как это использовать для rs - было очевидно
было бы у меня лучше фундаментальное образование - не тупил бы два года ))
Ну умение пользоваться гуглом это очень важное требование к соискателю программисту =)
Можно пример из жизни по вопросу о теории, который как то поможет понять хороший кодер или нет?
Стандартное собеседование в дебильные конторы:
- Python знаете?
- Нет, первый раз слышу.
- Работали раньше где-нибудь?
- Нет
- Какие задачи решали?
- Не решал. Сидел на пикабу, писал комментарии на vc в рабочее время.
- Сколько денег хотите?
- 380к в день
Собеседование в адекватные места:
- Здарова, по харду не угараем, по ночам и выходным не сидим, пилим на питоне, стек по классике. Пацаны грамотные, можешь зайти пообщаться с ними. По баблу предлагаем (...) Если мало - говори скоко хочешь - подумаем, токо аргументировано давай, без понтов.
- Да, контора норм и специфика работы норм, бабло нормально. Через 14 дней засяду.
В вашей стилистике очень забавное адекватное место получается.
Не хватает "вечер в хату, пацаны", при первом заезде на место работы))
и возьмёте в результате дворника, поскольку вопросов в этом "собеседовании" я как-то не заметил
Автор очень ловко подменяет тезис "бездумно задавать вопросы по теории из топчика поисковой выдачи - отстой" на "теория не нужна".
Не уверен, специально или из-за непонимания разницы.
Можно ли писать код и деливерить в прод без знаний теории CS? Можно. И можно даже при этом выдавать оптимальное решение имеющихся задач в определенном проценте случаев.
Проблема только в том, что без понимания того, как работает используемый тобой код и платформа ты не можешь оценить ни оптимальность этого решения, ни возможные проблемы\последствия его использования.
Суровая правда такова, что понимание принципов работы целевой платформы и используемых инструментов довольно сильно увеличивает понимание того, что будет происходить с твоим кодом после того, как ты нажмешь кнопочку Run в своей модненькой IDE.
Это понимание позволяет избегать в долгосрочной перспективе довольно многих проблем, которые ты, конечно, потом решил бы (с помощью гугла и стэковерфлоу).
Но избежать проблем - значительно лучше, чем их решить.
Понимание структур данных, алгоритмов и всяких там паттернов-хуяттернов очень хорошо помогает декомпозировать задачи на логические компоненты и видеть разные варианты решения оных.
Значит ли это, что на работку надо брать только олимпиадников? Нет, не значит.
Это значит, что люди задумывающиеся о том, как их код будет работать будут писать код более вдумчиво, чем люди, которые "скомпилировалось - значит работает".
Ну и дальше по накатанной, вплоть до "тесты можно научиться писать за 10 минут".
кек.
Понимание структур данных, алгоритмов и всяких там паттернов-хуяттернов очень хорошо помогает декомпозировать задачи на логические компоненты и видеть разные варианты решения оных.
Живой пример, сколько раз на практике у Вас такое происходило?
Абстрактно можно говорить много и долго. Живые примеры показывайте, обосновывайте свою точку зрения.
Я свою могу обосновать и подкрепить примером.
Лучше бы писали статьи, как взять себя в руки ИТ чуваку, который выгорил от работы и больше не хочет работать. Я бы прочитал... даже задонатил бы.
Пока не выгорал, помочь не могу. Но есть на ютубе видос. Там как не выгореть... Интересные вещи говорит, советую.
выход простой на самом деле - займись тем что тебе интересно на данный момент.
при этом, увольняться или нет - дело твоё.
Да уж море на эту тему написано. Почитайте классиков. Владимира Леви, например. Лекарство от лени.
Комментарий недоступен
Я в C# не ногой, но, как мне кажется, если Вы берете кого то выше джуна и у него есть опыт, то он всё это знает, потому что в работе с этим сталкивался. То есть, как Я писал, Вы спрашиваете о технической реализации его опыта и он всё это расскажет...
В целом согласен, но это не та оголтелая теория, о которой речь в статье, а знание ЯП, на котором пишешь.
как раз хороший джун это знать уже должен. теория - это в первую очередь к джунам (хорошим). ну а уж базовые фичи языка типа override - это 100%. это как раз синьору позволительно сказать "это я могу нагуглить" в вопрос на базовые фичи
Я hr, консультант, в том числе занимаюсь подбором IT специалистов. Я не знаю, с какими Hr-ами вам посчастливилось встречаться, конечно, в агентствах бывают плохо обученные или начинающие специалисты, они могут задавать вопросы, ответы на которые не понимают. Опытный hr так, конечно, делать не станет. А вот как станет: сначала уточнит у Заказчика (внутреннего или внешнего), какие именно профессиональные вопросы он может задать на интервью самостоятельно и как примерно можно оценить, насколько содержательный ответ получен. Вы удивитесь, но для понимания опыта специалиста в совершенно новой сфере опытному hr-у достаточно месяц позаниматься вакансией, провести 10-15 собеседований - поверьте, дальше вы имеет достаточно информации, чтобы отсеивать неподходящих кандидатов, в том числе и по опыту работы. Я замечала, что уже через месяц моя оценка профессиональных компетенций кандидата совпадает с оценкой коллег ITшников. Hr как раз и задает вопросы на уточнение подробностей работы на предыдущем месте и, поверьте, не так уж сложно оценить насколько человек глубоко понимает профессиональные вопросы, для этого не обязательно досконально разбираться в деятельности, ведь есть и другие способы оценить как говорит человек и какое содержание стоит за его словами. Вы недооцениваете специалистов hr или вам не повезло. Кстати, на собеседовании сразу видно кандидатов, которые относятся к вам свысока или пренебрежением, даже если они стараются произвести хорошее впечатление. Опытный hr понимает это за 2-3 минуты разговора - это говорит о социальной адекватности человека, его умении работать в команде и возможной реакции на тех коллег в будущей работе, которых он посчитает недостаточно компетентными. По моему опыту, чем профессиональнее и опытнее специалист, тем с большим уважением он воспринимает даже, на первый взгляд, ненужные вопросы на собеседовании. Опытный специалист - это не только квалификация, это и навыки общения с разными людьми, и умение строить коммуникации и управлять ими. Если Вы умеете грамотно вести беседу, вы из любого вопроса не только сможете вывести туда, куда вам нужно, а еще и выспросить информацию, завязать полезные контакты, а не разворачиваться и уходить. Это в любых отношениях крайние меры, люди их применяют только тогда, когда не справляются с ситуацией.
господа корректоры, вы, кажется, забыли вычитать эту статью
поправьте все ошибки, читать невозможно
Какие ошибки? На vc есть корректоры?
Комментарий недоступен
Услуги:
бэкенд, фронтенд, фуллстэк (+1500 сверху), выезд, могу остаться на ночь.
Мой опыт работы в сфере разработки сайтов с 2012 года. Работа с платформой 1С-Битрикс с 2013 года. Цена часа 450р
Я - предприниматель, сам программирую и провожу собеседования.
Во-первых, собеседование длится не так долго и за это время нужно понять что человек умеет, что знает и что может. Это сделать не просто. Теория - не нужна. API - есть документация. "Что делал?" - в большинстве случаев, особенно, когда "теория не нужна" - ничего интересного, зацепиться не за что. Тем более, чтобы говорить об этом час-два. Но, думаю, все разговаривают об опыте, хотя бы, минут 5-10-15. Кандидаты, у которых большой, интересный и релевантный опыт (например, синьор из конкрурирующего продукта), о котором можно говорить все собеседование - это очень редкая история.
Во-вторых, IT бизнес меняется быстро. Сейчас нам нужен сайт-визитка, а завтра - нагруженный развесистый сайт. Кто его будет делать? Кодер, который вчера написал сайт-визитку? А он способен быстро поднять матчасть? Или мы срочно идем снова на сайт работы, а кодера увольняем? Иными словами, команда - это ценность сама по себе. В команде нужны люди с хорошим потенциалом, чтобы они могли дать компании потенциал технического роста. Нужна команда, которая может решать задачи, о которых в данный момент мы даже и не задумываемся.
В-третьих, программисты очень неплохо зарабатывают. Эти деньги платятся не просто так и не за ответы на "дурацкие" вопросы на собеседовании. Если разработчик способен решать нетривиальные задачи (снова, здравствуй, теория!) и он входит в техническое ядро компании, то з/п у него будет высокой, будут опционы. Очень ценятся люди, которым можно отдать нетривиальную задачу, забыть про нее и быть уверенным, что этот человек решит ее максимально качественно и саксимально быстро. А нетривиальные задачи на StackOverflow не бывают - если задача уже там, то она тривиальна.
Если вы хотите среднюю на HH з/п, или, с другой стороны, разработчика со средним по HH опытом, то, да, согласен с автором. Если хочется з/п выше среднего, а, может, и еще выше, плюс рост обязанностей и карьеры, то нужено знать и уметь больше того, что вы делали для предыдущих компаний. Если в моей компании люди будут делать то же, что они и делали 5 лет назад в других компаниях, то где мое преимущество? Нет, нужно, чтобы человек уже сейчас, выйдя на работу, мог делать что-то более сложное, чем для текущего работодателя.
"Нужно все время бежать, чтобы оставаться на месте".
Перечитал Ваше "Во первых" несколько раз, но суть так мне и не понятна...
Во-вторых, IT бизнес меняется быстро. Сейчас нам нужен сайт-визитка, а завтра - нагруженный развесистый сайт...Если у человека нет опыта, а Вы ищите с опытом, то и собеседовать дальше не имеет смысла.
Если же Вы ищите без опыта на вырост, проверяйте эрудицию, логику.
Прошу заметить что это Я повторяю слова из самой статьи.
Не хочу показаться грубым, но если компания делает и то и это, а Вы руководитель-бизнесмен-программист-hr в одном лице, то сомневаюсь, что ваша компания реализовывала что то крупнее интернет магазина с более чем 500-1000 посещениями в день.
У меня самого студия которая лепит сайтики, но Я в ней только руковожу, а сам работаю в другой гораздо более крупной компании, которая пилит высоконагруженные сервисы для внутреннего использования.
Кто его будет делать? Кодер, который вчера написал сайт-визитку? А он способен быстро поднять матчасть? Или мы срочно идем снова на сайт работы, а кодера увольняем?Странный у Вас ход мыслей. Вы не знаете квалификации своих сотрудников? Как Вы вообще тогда работаете и раздаете задачи?
В команде нужны люди с хорошим потенциаломМожно узнать Ваш способ определения потенциала?
Если разработчик способен решать нетривиальные задачи (снова, здравствуй, теория!)Для решения нетривиальной задачи нужен живой ум. А как раз таки теории описывают заезженные до дыр решения тривиальных задач.
А нетривиальные задачи на StackOverflow не бывают - если задача уже там, то она тривиальна.Пример из жизни?
Если в моей компании люди будут делать то же, что они и делали 5 лет назад в других компаниях...Просто из любопытства - а Вы способны им дать задачи, которые отличаются от тех что были 5 лет назад?
У вас какая позиция? Синьор, лид? Сколько человек в подчинении?
Что то вроде senior, явного разделения нет. Я решаю задачи по сложнее и составляю архитектуру, можно так сказать.
Сейчас 3 в подчинении. Отдел разработки не очень крупный =)
Плюсую)
После прочтения заметки захотел задать тот же вопрос
В принципе, автор в одной статье и комментах, описал портрет типичного российского «программиста». Теперь я понимаю почему все пишется так плохо и так медленно, а чтобы найти толкового программиста, приходится собеседовать по сто-двести человек. Много гонора, базы нет, глубины нет. Тотальная избалованность рынком. Но радует, что в последние годы тенденция начала меняться в обратную сторону.
По теме: людей в компанию подбирают по опыту и по ценностям. Если, например, компании важен чистый код или pixel perfect, а вы не разделяете эти взгляды, то ничем хорошим это не закончится. Если компании важна высокая скорость работы, а вы полируете свой код неделями и делаете все с ленцой — тоже самое.
Например, автор, я бы с вами не стал работать, потому что вы допускаете тривиальные ошибки в русском языке. То есть, вы не бережно относитесь к языку. Или даже хуже — вы вообще не видите ошибки. Примерно понятно, что нас будет ожидать в коде или архитектуре проекта.
Уважаемый, конкретный пример, что медленно? Как у нас любят абстракции, ВСЁ ПЛОХО, ВСЕ ТУПЫЕ, а как просят назвать конкретные вещи, ответить ничего не могут.
Немного мыслей:
1. Теория. Нужна, так или иначе.
- Ну очень глупо доверять веб-разработку человеку, не понимающему HTTP
- Как брать человека в команду на проект без понимания SOLID?
- Как брать специалиста, который не умеет думать? Спрашивать "Справитесь ли вы?" Серьезно?!
Но справедливости ради расскажу такой случай. Я относительно молодой спец-т, всего полтора года. Собеседовался в Рамблер и мне в реалтайме дали задание по 5 пыхе на англ языке -- это все ладно, но задания были чисто по синтаксису, точнее его потаенным местам. Так как я развивался и работал только в 2017-18 годах (эпоха 7 пыхи), то конечно я больше заморочен на ООП, СОЛИДЕ и архитектуре, нежели на синтаксисе языка... крч не очень удачно прошел его :(
2. Тестовые задания
Ну я отказываюсь уже... Но опять же -- дело каждого, тут разные мнения.
3. Ну и удачи вам с инженерами, которые за 10 минут научатся писать юнит-тесты :) Посмотрел бы я, как на его кривой код пишется кривой тест :)
...
А вообще почему это у вас вызывает боль?
Я почти без глубокого опыта после собеседований получаю много предложений. Потому что многим, как вы подметили, важен не уровень, а как человек вольется и на собеседовании часто такое и происходит -- молодые специалисты и кадровики видят хорошего парня и берут его, или у вас не так? Завязывайте со своей оценкой "эти HR -- сплошные ТП".
Сейчас с работой (в Москве) точно нет проблем прогером, а вот найти крутой проект и крутую команду -- есть (это прямо боль :)
...
К проблеме бы я отнес вот какой момент -- не очень тщательно прорабатывают кандидатов и приходится по телефону выяснять все ли так, как в вакансии, кого ищут и как все работает,
а то зовут на бекенд, а на собесе JS фреймворки всплывает на 70% работы
- Ну очень глупо доверять веб-разработку человеку, не понимающему HTTP
- Как брать человека в команду на проект без понимания SOLID?
- Как брать специалиста, который не умеет думать? Спрашивать "Справитесь ли вы?" Серьезно?!
Ну например фронтэндеру не обязательно понимать HTTP.
У него есть готовые либы, которые делают запросы на сервер и получают оттуда данные в заранее определённом виде. Поверх этих данных он пишешь фронтэнд.
А принципы и понимание работы самого фронтэнда уже больше относятся к опыту.
По поводу SOLID и ООП в целом - функциональщики негодуют... А если серьезно, в реальных проектах все эти принципы и модели далеко не всегда применимы. К тому же в каждой компании есть свои правила написания кода, некоторые по моделям, некоторые нет.
Про спрашивать у соискателя там вроде не было, но даже вопрос в лоб чем плох? Может он сам поймет что не потянет и откажется...
2. Тестовые заданияНи разу не делал. Жалко время терять. Хотите посмотреть мой код, вот вам гитхаб.
3. Ну и удачи вам с инженерами, которые за 10 минут научатся писать юнит-тесты :) Посмотрел бы я, как на его кривой код пишется кривой тест :)Красота кода делается с помощью линтеров. А по второму - методология TDD - сначала тест, к нему код. Ну и тимлид или старший программист или кто там ещё должны ввести новых разрабов в курс дела, как и что пишется. Везде свои нюансы.
Работы то хватает, просто не нравится когда людей сбивают с толку. Люди доверчивые и прочитав статьи типа "25 классических вопросов, которые HR-ы задают программистам на собеседованиях" начнут думать что все нормальные программисты априори должны такие вещи знать... Не должны.
я программирую с 80х, когда SOLID ещё не придумали даже. интеерсно, когда меня перестало возможно брать в команду? :)))
Так как я развивался и работал только в 2017-18 годах (эпоха 7 пыхи), то конечно я больше заморочен на ООП, СОЛИДЕ и архитектуре, нежели на синтаксисе языка... крч не очень удачно прошел его :(у вас нормальное направление знаний для джуна - теория CS и SE. те, кто вместо этого порверяют синтаксис PHP и на этом только основании режут - сами себе редиски. не удвилюсь, если и работать там потом будет не очень, во всяком случае вашими коллегами будут те кто сумел зазубрить синтаксис? так что я тут не очень сожалел бы
а вообще с нарктоты надо слезать :D java, go, C# - в общем осваивайте любой static typing, советую
Сам провожу тех часть собеседования по skype + google docs. Предлагаю задачи разного плана и прошу рассуждать вслух при решении и сразу вижу КАК человек пишет и ЧТО он пишет. В результате понимаю, как мыслит человек. Большая часть отсеивается, ибо либо начинает придумывать ответы (почему собеседуемые боятся сказать "Я не знаю"? Ведь это нормально!), либо гуглят и копипастят ответы, без каких либо комментариев. Вопросы на знание теории (без практики) - вообще бесполезно, тот +1 к посту автора. Важно как мыслит человек, а пробелы восполняются очень быстро. А ходячие энциклопедии - они бесполезны на реальных задачах
умение мыслить - это только базовый навык. а обрастает он со временем как раз конкретными знаниями
Нужно было начинать так "Найм макаки-формошлепера... но не программиста
Обоснуете?
Самый адок, который у меня был, как у проходящего собеседование, это когда какая-то никому неизвестная конторка-"интегратор" с пафосом предложила мне пописать код и sql-запросы на листочке бумаги. Я сначала подумал что они техлид шутит, но потом оказалось что нет.
что в этом сложного? Тут даже думать не надо
сюрприз - гуглы и янлексы делают точно так же
"По тому" "На сколько"
Ну как так?
Комментарий недоступен
Привет, DEVVEB Constantine!
Расскажи, что думаешь про тестовое? Стоит давать в кач-ве домашнего задания, что-то, что кандидат на веб-программиста сможет сделать за 2-4 часа?
Нас HR-ы отговаривают, говорят теряем кандидатов из-за этого, мы стоим на своём, не хотим брать без проверки того, может ли вообще человек код писать.
Спасибо за статью!
Спасибо что прочитали.
Расскажи, что думаешь про тестовое?Я думаю зависит от вакансии и количества кандидатов.
Если много кандидатов, тогда чтобы ограничить их количество до разумных пределов, можно тестовые использовать.
Если бэкэндер - попросите простенький микросервис написать, без тестов и проверки типов, который делает что то, что относится к будущей работе, если фронтэндер, попросите простой небольшой интерфейс по некой API-шке накидать.
Правда Я сам тестовые не делал ни разу, но и вакансии были такие, что очереди там не было...
"На сколько" может и не поймут, но, по крайней мере, будут писать орфографически правильно
Советы от GeekBrains вполне дельные на позицию стажёра или junior. Что вполне логично, учитывая направление их деятельности.
Также понятно, что чем ближе к senior, тем больше стоит узнавать про опыт и оценивать эмоциональный интеллект, а не напирать на теоретические вопросы.
Комментарий недоступен
т.е. вы потом стали экспертом в этой обаслти и все ваши знания тем не менее можно получить за пару дней?
Согласен с автором только в том, что эйчары не нужны
а ты готов сам фильтровать сотни претендентов пришедших на одну позицию?
Провёл несколько сотен собеседований.
Теория теории рознь. Реализация сборщика мусора, возможные утечки памяти, оценка сложности алгоритмов - нужны любому разработчику (ну кроме «сайт за 5 минут»). Да, это можно найти в первой ссылке в гугле, но меня пугают люди, которые этого ещё не посмотрели. Всегда задаю эти вопросы. Хранение графов в БД - это теория? Ну если это будет графами называться, то да, а если бесконечно вложенными комментариями на сайте?
«Что выведется на экран после выполнения кода» - не люблю такие вопросы, но 1-2 всегда будет, но от реальности оторваны не будут.
Вышка - очень спорный момент. С одной стороны знание того, что человек 4-6 лет херачил ради диплома согревать не будет, когда надо проект сдавать, с другой - первые пару лет самая нужна база даётся и не факт, что человек без вышки вообще ее знает.
если человек без вышки И сам не учился - будет code monkey. если не пошёл в вуз потому, что проще это самому освоить - то наоборот будет супер-программист
Дебильные вопросы и ответы хрюшкам на собеседовниях -- проверка на лояльность, готов ли человек прогибаться под стандартные правила. Как я понимаю, на западе 1) хрюшки нужны для того чтобы оформлять разнообразные договора 2) мониторить настроения сотрудников и стучать начальству, если что-то отклоняется от нормы 3) составляют не самые опытные люди, серьезная подготовка не нужна.
Про теорию. Если кандидат не знает что такое map и чем тот отличается от list-а, то о чем с кандидатом говорить? А надо не просто знать, а ещё и уметь применять..
Уметь применять как раз таки про практику... И из разговора про опыт будет ясно что он умеет, а чего не умеет. Будет понятно, он просто не сталкивался с чем то, или сталкивался, но пришёл к не верным выводам и решениям. Если у него спросить почему он решил так, а не по другому, то будет понятен ход мыслей. И это, на мой взгляд, гораздо более эффективно, чем спрашивать в лоб какие то вопросы, без контекста практического опыта.
Неистово плюсую.
Проверка на знание плохо связанных между собой теоретических выкладок в режиме онлайн не преследует никакой цели, кроме морального давления.
Обычно "знанием всех паттернов программирования" страдают джуниоры-теоретики, которые вам не задачи будут решать, а "строить идеальную систему", особенно в отсутствии надлежащего надзора (а вопросы из разряда "какие паттерны программирования вы знаете" как раз говорят о том, что нормального тимлида в команде и нет). Как бы дико не звучало, но я знаю компании, в которых таким теоретикам годами удавалось водить за нос далекое от разработки руководство - делаем, переписываем, внедряем суперкрутую фичу, и все в строгом соответствии с паттернами.
А потом проект только в мусорку можно выбросить.
Разработчика знающего все паттерны программирования и теоретизирующего о правильных конструкциях надо гнать с собеседования взашей. Хороший программист должен делать работу, а не пустозвонить-философствовать. Хороший программист виден по его предыдущим работам и по аналитическим способностям.
Комментировать статью не буду, а только спрошу — сколько человек за свою профессиональную жизнь нанял автор? Или хотя бы отсобеседовал?
Около 200 отсобеседовал, принял 10.
А Вы?
"Пожалуйста, великие гуру найма и технари, любящие спрашивать теорию, объясните мне в комментариях в чем смысл Ваших вопросов?"
смотря что вы понимаете под "теорией"? самая главная проблема это иллюзия наличия знаний, не полезет например такой человек в гугл посмотреть чем гет от поста отличается и сделает вам всё на гетах)
"Чтобы научиться писать юнит-тесты уйдёт от силы минут 10."
так сложилось, что писал их мало, но дело тоже имеет свои хитрости, правда если человек это не вдупляет, то остальное тем более
Что такое высокоуровневый и низкоуровневый язык программирования?
так сложилось, что писал их малоЧто такое полнота языка по Тьюрингу?
Какие есть операторы цикла в вашем языке и методы организации цикла без операторов?
Что такое компилятор и интерпретатор?
Какие бывают типы констант?
Дайте определение императивным, функциональным и процедурным языкам программирования. Приведите по 2-3 примера каждого.
Что такое методология программирования? Что представляет из себя Agile.
Жизненный цикл программы – опишите или изобразите его.
...
(Из статьи по ссылке в начале материала)
Ага! Вы нам не подходите! - скажут вам, если будут собеседовать так как это делают обычно. Вопрос в лоб, неудовлетворительный ответ, мимо.
Я же предлагаю узнавать технические моменты в разрезе опыта, что позволит понять, почему например вы писали мало юнит тестов и т.д.